のメモ

   1  git reset --hard <commit>
   2  git merge -s ours origin master
   3  git push -f origin master

さくらクラウドを使い始めて１週間程度、気づいたことをメモしておきます。

良い所

• 安い（EC2に比べると半額以下のイメージ）
• トラフィックに課金されない
• GUIが使いやすい

悪いところ

• 2〜3日経つと突然SSDにアクセスできなくなり、再起動を余儀なくされた（この一週間の間に２度）
• diskの追加にrebootが必要

障害レポートを見ると、SSD関連の緊急メンテナンスがちょこちょこ入っているので、まだ熟れていない感じなのかも。 SSDが悪いなら標準ディスクに切り替えて検証してみようと思ったのですが、 再起動しないとdiskをアタッチできずに残念な感じ。 別サーバを立ててそっちに乗り換えるにしても、累積課金じゃなくて別課金になるので割高になる。

ともあれ、ec2の１強時代にあって、適正な競争が行われるためにもうちょっと応援していきたい。

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 はおこのみで。

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

にしたら直った。

   1  # aptitude update
   2  # apt-get source <pkgname>
   3  # apt-get build-dep <pkgname>
   4  # cd /usr/local/src/<pkgname-version>

パッチを当てる

   1  # debuild -us -uc

昔何かをしようとしてforkしたリポジトリの内容を、 現在の upstream の内容でリセットしたい場合、以下のようにすると良いようです。

   1  git remote update
   2  git reset --hard upstream/master
   3  git push origin +master