• 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
 
posted by Png genki on Sat 5 Apr 2014 at 23:38

以下のようにすればok。

   1  ffmpeg -i infile -t duration -ss from outfile

  • infile 入力ファイル名
  • duration 秒数
  • from 開始時刻(秒)
  • outfile 出力ファイル名
posted by Png genki on Wed 26 Feb 2014 at 12:40

   1  use local
   2  db.dropDatabase()

して

   1  # service mongodb restart

posted by Png genki on Fri 24 Jan 2014 at 17:28

今まで自作ツールを使っていましたが、そろそろchefを使ってみようかといろいろ試しています。 knife.rbの探索順序の問題でハマったのでメモ。

knife-ec2を使ってインスタンス一覧を見ようと思ったのですが、

   1  % knife ec2 server list
   2  ERROR: You did not provide a valid 'AWS Access Key Id' value.
   3  ERROR: You did not provide a valid 'AWS Secret Access Key' value.

あれれ? 確かに ~/.chef/knife.rb に設定してあるはずなのだけれど... 悩むこと数十分。

knifeコマンドはデフォルトで ~/.chef/knife.rb を探しに行くと思っていたのですが、カレントディレクトリ直下に .chef/knife.rb というファイルがある場合はそちらを優先するようです。

posted by Png genki on Sun 24 Nov 2013 at 19:43

何らかの原因でgemのファイルが壊れたことが想定される場合、 以下のようにすると全てのインストール済みgemを初期状態に戻すことができます。

   1  gem pristine --all

posted by Png genki on Fri 22 Nov 2013 at 14:58

一行ですが

   1  curl -L http://toolbelt.treasure-data.com/sh/install-ubuntu-lucid.sh | sh

簡単になったなー

posted by Png genki on Sun 17 Nov 2013 at 23:34

/etc/sysctl.d/以下の設定を反映させるには、

   1  # sysctl -p

で良いみたいですが、ubuntu (13.04) 環境ではうまく反映されなかったので、

   1  # sysctl -p /etc/sysctl.d/60-foobar

のように直接 path を指定する必用があるようです。

posted by Png genki on Thu 7 Nov 2013 at 20:44

のメモ

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

posted by Png genki on Wed 16 Oct 2013 at 18:20

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

良い所

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

悪いところ

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

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

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

posted by Png genki on Mon 16 Sep 2013 at 09:48

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

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

posted by Png genki on Sun 25 Aug 2013 at 00:38