top コマンドでいうところの %sy、つまりカーネルプロセスによる CPU使用率が高まってきた場合、以下の様な方法で原因を調査することができます。

   1  # strace -c -p <PID>

CPU使用率が高くなっているプロセスのPIDを指定します。 これにより、指定のプロセスから呼び出される system call の回数や消費CPU時間の集計が始まります。 10〜30秒程度たったら、Ctrl+Cで集計を終了します。 そうすると、以下の様な集計結果が得られます。

   1  % time     seconds  usecs/call     calls    errors syscall
   2  ------ ----------- ----------- --------- --------- ----------------
   3  100.00    1.470463       63933        23           munmap
   4    0.00    0.000000           0        12           read
   5    0.00    0.000000           0        24           write
   6    0.00    0.000000           0        23           mmap
   7    0.00    0.000000           0        24           rt_sigprocmask
   8    0.00    0.000000           0         6           writev
   9    0.00    0.000000           0        36           gettimeofday
  10    0.00    0.000000           0         6           getppid
  11    0.00    0.000000           0        18           clock_gettime
  12    0.00    0.000000           0        12           epoll_wait
  13    0.00    0.000000           0        12           epoll_ctl
  14    0.00    0.000000           0        12           ppoll
  15  ------ ----------- ----------- --------- --------- ----------------
  16  100.00    1.470463                   208           total

munmap 遅いですね。

それから、munmap の内部のどこが遅いのか、更に細かい粒度で原因をしらべるには、ftrace が使えます。

ftrace が利用可能かどうかは以下のようにして調べられます。

   1  cat /proc/sys/kernel/ftrace_enabled
   2  1

ftraceはソースコードで配布されているので、以下から git clone してきます。

   1  cd /usr/local/src
   2  git clone git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
   3  cd trace-cmd
   4  make
   5  make install

例えば、以下のようにls コマンドを実行してkernel関数がどのように呼ばれているかを調べられます。

   1  # trace-cmd record -p function_graph ls

実行が終了するとカレントディレクトリに trace.dat が作成されます。 これを

   1  trace-cmd report | less

のようにして確認します。

Are there the servers at home, or the on-premise servers at office? If no, the mosh is your best friend and this article is just a waste of time.

But if yes, the Rosh might help your life. Rosh is the roaming shell like the mosh. But it can track the server even if its IP address change. It reconnects to the server by resolving the hostname each time.

You can use the local DNS such as the dnsmasq for your on-premise servers so that you can resolve the server by same name no matter where you are.

The usage of Rosh is simple, like this

   1  gem install rosh
   2  rosh yourserver.com session-name

It installs the nested GNU screen session remotely at the given server. You can omit the session-name, "default" is used as the name. Then, Rosh connects to the session via the SSH.

If you want to detach the session, type Ctrl+t d. On the second time you connect, Rosh reuses the remote session.

• Rosh (Rubygems.org)
• Rosh (github)

Requirements

• SSH
• Ruby at your machine (2.0.0 or later. Sorry, I don't have 1.9.x or older)
• GNU screen at remote servers

普通にscreenを使っていると、detachしてからattach した場合に、 split状態を忘却してしまうのがやや煩わしいです。

以下のようにして２重にscreenを起動し、

   1  screen -c /dev/null -e "^t^t" -S name
   2  STY=
   3  screen

外側のscreen を ^td で detach してから screen -r name で attachすると、split状態を擬似的に保持できます。

^t や name はおこのみで。

   1  -	(void)
   2  viewWillAppear:(BOOL)p
   3  {	[	NSNotificationCenter.defaultCenter
   4  		addObserverForName:UIKeyboardWillShowNotification
   5  		object:self.view.window
   6  		queue:nil
   7  		usingBlock:^( NSNotification* p )
   8  		{	[	UIView
   9  				animateWithDuration:[ [ p.userInfo objectForKey:UIKeyboardAnimationDurationUserInfoKey ] doubleValue ]
  10  				animations:
  11  				^{	self.view.frame = CGRectMake
  12  					(	self.view.frame.origin.x
  13  					,	self.view.frame.origin.y
  14  					,	self.view.frame.size.width
  15  					,	self.view.frame.size.height - [ [ p.userInfo objectForKey:UIKeyboardFrameEndUserInfoKey ] CGRectValue ].size.height
  16  					);
  17  
  18  				}
  19  			];
  20  		}
  21  	];
  22  	[	NSNotificationCenter.defaultCenter
  23  		addObserverForName:UIKeyboardWillHideNotification
  24  		object:self.view.window
  25  		queue:nil
  26  		usingBlock:^( NSNotification* p )
  27  		{	[	UIView
  28  				animateWithDuration:[ [ p.userInfo objectForKey:UIKeyboardAnimationDurationUserInfoKey ] doubleValue ]
  29  				animations:
  30  				^{	self.view.frame = CGRectMake
  31  					(	self.view.frame.origin.x
  32  					,	self.view.frame.origin.y
  33  					,	self.view.frame.size.width
  34  					,	self.view.frame.size.height + [ [ p.userInfo objectForKey:UIKeyboardFrameEndUserInfoKey ] CGRectValue ].size.height
  35  					);
  36  
  37  				}
  38  			];
  39  		}
  40  	];
  41   }
  42  
  43  -	(void)
  44  viewDidDisappear:(BOOL)p
  45  {	[ NSNotificationCenter.defaultCenter removeObserver:self ];
  46  }
  47  
  48  

Ruby には empty? や nil? など、接尾辞"?"がつくメソッドを使えるので直感的にわかりやすい場合が多いのですが、三項演算子 ?: の条件に使う時だけは

   1  foo.empty? ? bar : baz

のように ? ? が連続してなんだか気に入りません。 なので、こういう場合には三項演算子の代わりに

   1  foo.empty? and bar or baz

と書くことが多いかも。これだとスッキリします

git でリモートに push したコミットが間違いだったと気づいた場合、

   1  git reset --hard <戻したいコミット>

で一旦手元の環境を正しい状態に戻し、あとは

   1  git push -f origin HEAD:master

でリモートに反映さればok

特に環境の変化は無かったのですが、突然 gem search が応答しなくなったので原因を調べてみたところ、gem sources を

• https://rubygems.org
• http://gems.github.com

にしたら直った。