sed

eオプション

e、fやらがないと最初のオプション以外をsedスクリプトとする。

sage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...

If no -e, --expression, -f, or --file option is given, then the first
non-option argument is taken as the sed script to interpret.  All
remaining arguments are names of input files; if no input files are
specified, then the standard input is read.

iostat

iostatが見ているレイヤー

ブロックレイヤーのIOキュー

まとめ

  • iostatで例えばutil(ディスク使用率)が99%近くでもそのデバイスファイルに紐づく物理デバイスがraid0などで複数ある場合はIOは分散されているので各ディスクに実際の使用率は低いということが起こりえる。
  • iostatではシンプルな構成、デバイスファイルと実デバイスが一つに結びつけることができる時(pvdisplay の結果一つしかない場合など)は下記コマンド結果の指標が有効に働く。

下の場合、/dev/vdaがディスク一つに対応している場合、問題無いが、/dev/vdaが実際には複数の物理ディスクに対応しているような場合、iostatから見たレベルの/dev/vdaの使用率が100%でも、裏では各ディスクにそれぞれアクセスしているので、各ディスクの使用率は全然低いということが起こりうる。

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.99    0.00    1.00    4.98    0.00   90.03

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    51.16    0.00   21.93     0.00   534.22    24.36     0.07    3.27    0.00    3.27   2.82   6.18
dm-0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
dm-1              0.00     0.00    0.00    1.33     0.00    10.63     8.00     0.00    2.25    0.00    2.25   1.25   0.17
dm-2              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
dm-3              0.00     0.00    0.00   68.44     0.00   523.59     7.65     0.39    5.77    0.00    5.77   0.88   6.05

参考

www.amazon.co.jp

device-mapper

  • “dm”, “DM” と略される
$ ll /dev/dm*
brw-rw----. 1 root disk 253, 0 Mar 30 15:35 /dev/dm-0
brw-rw----. 1 root disk 253, 1 Mar 30 15:35 /dev/dm-1
brw-rw----. 1 root disk 253, 2 Mar 30 15:35 /dev/dm-2

上にリンクが張ってある

$ ll /dev/mapper/vg*
lrwxrwxrwx. 1 root root 7 Mar 30 15:35 /dev/mapper/vg_testhost1-lv_home -> ../dm-2
lrwxrwxrwx. 1 root root 7 Mar 30 15:35 /dev/mapper/vg_testhost1-lv_root -> ../dm-0
lrwxrwxrwx. 1 root root 7 Mar 30 15:35 /dev/mapper/vg_testhost1-lv_swap -> ../dm-1

dm名

  • VG名-LV名からリンクはってある。カーネル内部ではdm-番号でLVMを判別している様子

機能

参考

http://lc.linux.or.jp/lc2009/slide/T-02-slide.pdf

LINUX の時間

UTC

  • コンピュータ界の標準時となっているUTC
  • タイム ゾーン(時間帯)と呼ぶ区域に分け、UTCからの時差で補正した時刻をタイム ゾーンの標準時として適用
  • タイム ゾーンの標準時をローカル タイム(地方時)
  • UTC ± 時差
  • UTCより9時間進んでいる日本のローカル タイム(JST)は、UTC+09:00

システムクロック

パソコンで使用される唯一の時計(時刻情報源)はシステム クロック その実態はメモリ上で管理 OSは起動されるとハードウェア クロックの時刻情報を読み出し、基準時刻からの経過秒数の形式に編集

ハードウェア クロック

  • 製造時に正しい現在の値が入る?
  • パソコンの電源を切っても時刻情報を維持
  • マザーボード上に実装され、バックアップ電池等により途切れることなく稼働
  • 電池切れになると時刻情報がリセットされ、パソコンが正常に起動ができなくなります。

参考

パソコンの時計 ハードウェアクロックとシステムクロック

eng-entrance.com

システムクロックはハードウェアクロックの情報を元に設定される。しかしハードウェアクロックは「精度が高いか?」というとそうでもないので気をつけていただきたい。定期的にシステムクロックをNTPで正確に同期したあと、ハードウェアクロックも定期的に同期したほうがいいだろう。

sarコマンドでのLA

sarコマンドでのLA

       -q     Report queue length and load averages. The following values are displayed:

              runq-sz
                     Run queue length (number of tasks waiting for run time).

              plist-sz
                     Number of tasks in the task list.

              ldavg-1
                     System  load  average  for  the  last  minute.   The load average is calculated as the average number of runnable or running tasks (Rstate), and the number of tasks in uninterruptible sleep (D state) over the specified interval.

              ldavg-5
                     System load average for the past 5 minutes.

              ldavg-15
                     System load average for the past 15 minutes.

参考

d.hatena.ne.jp

sar もcat /proc/loadavg 1.72 1.99 3.68 3/372 18943 とLAが同じになるので /proc/loadavg から取得しているようだ。

/proc/loadavgは

つまり、CPU の数が増えてもロードアベレージは CPU の数でタスク数を平均したりはせず、純粋に「待ち行列にたまって待たされたタスクの数」を示しているのがここではっきりします。

待ち行列にたまって待たされたタスクの数」== number of runnable or running tasks (Rstate), and the number of tasks in uninterruptible sleep (D state)

ここで簡単にまとめておきます。 top や sar がデフォルトで示すCPU使用率はCPU数(コア数)で割り算をしている ロードアベレージは割り算をしていない

なるほど!

ここに一つ罠があるような気がします。カーネルは本当にすべての CPU に均等にタスクを割り当てているかどうか、という点です。先のデュアルコア x 2 = 4CPU の sar をもっと見てみましょう。

自分の環境ではsar -P ALL で見たCPUの使用率具合はほぼ均一だった。状況によってCPUへの割当が偏るとのこと。負荷をみるときは

sar -P ALL|CPU番号

したほうがよさそう。

top や sar がデフォルトで示すCPU使用率はCPU数(コア数)で割り算をしている。各CPUごとに値を保持している。 ロードアベレージは割り算をしていない。各CPU(ランキュー)ごとに値を保持するのではなく、システム全体で一つ。 4CPU ならロードアベレージ 4.00 まで OK、は鵜呑みにしないほうがよさそう。状況によって異なるのでその他の指標も使って細かく統計を分析>したほうがよい。 nr_running > 1 のときはロードバランスが適切に働く。そのため 4CPU なら 4.00 で割れ、というのは負荷があるときはそれなりに正しい。 ランキューに溜まってるタスク数が CPU 毎に見れたらいいのだけど、現時点のカーネルの実装では難しい。(全体のは sar -q で見れます。)

ルーティングテーブル

route -n

  • Flags
    • U(up):経路は有効
    • H:宛先はホスト
    • G:GateWayを通る
    • !:経路を拒否

ルーティングテーブルでは、デフォルトルートを「0.0.0.0/0」と表記

ルーティングテーブルのデフォルトGW
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0

elasticdump

準備

npm install -g elasticdump

実行