kitak

コマンドによる「負荷」の原因切り分け

この文章では、Linuxコマンド、sar, top, psを使って、一般的に負荷といわれるものの原因を切り分けることを目的とする。

そもそも負荷とは

「複数のタスクによるサーバリソースの奪い合いの結果に生じる待ち時間」を一言で表した言葉。OSのチューニングとは負荷の原因を知り、それを取り除くことにほかならない。

ボトルネックの見極め作業の大まかな流れ

• ロードアベレージ（処理を実行したくても、実行できなくて待たされているプロセス（CPUの実行権限が与えられるのを待っている、またはディスクI/Oが完了するのを待っている）の数）を見る

kitak

function getRelativeTime(baseDateStr, targetDateStr){

    var baseDate = new Date(baseDateStr);
    var targetDate = new Date(targetDateStr);

    var elapsedTime = Math.ceil((baseDate.getTime() - targetDate.getTime())/1000);

    var message = null;

    // これ以下で一定時間未満のごとのメッセージの表示方法を条件分岐

kitak

# lb001.kitak.pbでの操作
sudo yum install ipvsadm
sudo chkconfig --add ipvsadm
sudo chkconfig ipvsadm on
sudo su - -c 'echo "1" > /proc/sys/net/ipv4/ip_forward'
sudo ifconfig eth0:0 192.168.46.30 netmask 255.255.255.0
sudo vi /etc/sysconfig/network-scripts/ifconfig-eth0 #次回起動時も有効にする
sudo ipvsadm -A -t 192.168.46.30:80 -s rr　# 転送元のIPアドレス、ポート
sudo ipvsadm -a -t 192.168.46.30:80 -r 192.168.46.83:80 -g # 転送先のIPアドレス、ポート
sudo ipvsadm -Ln # 確認

kitak

# -*- mode: ruby -*-
# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure("2") do |config|
  # The most common configuration options are documented and commented below.
  # For a complete reference, please see the online documentation at

kitak

Testing front-end for a Sinatra app with RSpec and Capybara

I've used Cucumber quite a bit on my last job. It's an excellent tool, and I believe readable tests are the way to the future. But I could never get around to write effective scenarios, or maintain the boatload of text that the suite becomes once you get to a point where you have decent coverage. On top of that, it didn't seem to take much for the suite to become really slow as tests were added.

A while ago I've seen a gist by Lachie Cox where he shows how to use RSpec and Capybara to do front-end tests. That sounded perfect for me. I love RSpec, I can write my own matchers when I need them with little code, and it reads damn nicely.

So for my Rails Rumble 2010 project, as usual, I rolled a Sinatra app and figured I should give the idea a shot. Below are my findings.

Gemfile

kitak

/*
export interface GridArray<T> extends Array<T> {
  first?(): T;
}

export interface Table<T> {
  select(filter: object): GridArray<T>;
}
*/

kitak

/*
export interface GridArray<T> extends Array<T> {
  first?(): T;
}

export interface Table<T> {
  select(filter: object): GridArray<T>;
}
*/

kitak

const readline = require('readline')
const util = require('util')
const rl = readline.createInterface({input: process.stdin, output: process.stdout})
rl.question[util.promisify.custom] = (arg) => {
  return new Promise((resolve) => {
    rl.question(arg, resolve);
  });
};
const questionPromise = util.promisify(rl.question);
questionPromise('What do you think of Node.js? ').then((answer) => {

kitak

MySQLのreconnectとは

mysqlクライントでのreconnect

mysqlクライアントがステートメントの送信中にサーバとの接続が遮断された場合、 直ちに自動的に再接続し、ステートメントの送信を試みる(reconnect)。

注意:
再試行時には全セッションオブジェクトと設定(具体的にはテンポラリテーブル、オートコミットモード、ユーザー定義変数、 セッション変数、トランザクションロールバックなど)が失われているので、ステートメントによってはreconnectすることが危険なものもある。

reconnectしないようにmysqlクライアントを利用する場合には、--skip-reconnectオプションをつけてクライアントを立ち上げる。

kitak

local function keyCode(key, modifiers)
   modifiers = modifiers or {}
   return function()
      hs.eventtap.event.newKeyEvent(modifiers, string.lower(key), true):post()
      hs.timer.usleep(1000)
      hs.eventtap.event.newKeyEvent(modifiers, string.lower(key), false):post()      
   end
end

local function keyCodeSet(keys)