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.
参考
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
実行
localのlasticsearchからリモートのelasticsearchへ
- elasticdump –input=http://localhost:9200/index –output=http://remotehost:9200/index
ローカルにダウンロードする
- elasticdump –input=http://localhost:9200/index –output=$ > localfile
OS稼働中のカーネルパラメータ変更
一時的
- echoで設定
- echo > /proc/sys/
- sysctl -w パラメータ=値
- wはあってもなくても良いらしい。
- /proc/sysの値を変更する
再起動で設定を失う。
恒久的
- /etc/syscto.confを直接編集
- その後sysctl -p コマンド実行で反映。ファイル指定しなくてもデフォルトで/etc/sysctl.conf
ログ
rsyslog
syslogd はログ情報の紛失や暗号化ができない。
次世代のやつ出てきた syslog-ngとrsyslog
CentOS6ではrsyslogを採用。Debianも。
アプリケーション – rsyslog– logファイル
loggerコマンド
logger -p mail.info mail-log
ファシリティ.プライオリティ ログメッセージ
各ログの出力先
/etc/rsyslog.conf
ファシリティとプライオリティを指定して、各ログの出力先を設定している
ログローテーション
指定したタイミングで現在のログとはまた別の新しいファイルにログを記録するようにし、その古いログを指定された期間まで保存して削除すること。
logrotate
設定ファイル
基本設定ファイル
/etc/logrotate.conf
個別設定ファイル
/etc/logrotate.d/各アプリ対応の設定ファイル
デフォルト
weekly
rotate 4
一週間ごとにログを切り替えて、それが4回経過したときに削除される。
ld-linux-x86-64.so.2
実は実行できる。
$ ll /lib64/ld-linux-x86-64.so.2 lrwxrwxrwx. 1 root root 10 Sep 16 20:57 /lib64/ld-linux-x86-64.so.2 -> ld-2.12.so
ldd と同じ
仮想コンソール
仮想コンソール
直接筐体にログインする時などは便利なのか。 vmsareでは[Ctrl]+[Alt]+[space]を押した後[space]のみ離し、そのまま[Ctrl]+[Alt]+[F1~F5]で切り替わった。
ssh使うときは使っていない。
$ ps auxf | grep tty xxxx 18404 0.0 0.0 103312 864 pts/3 S+ 14:28 0:00 \_ grep tty root 2712 0.0 0.0 4064 584 tty1 Ss+ 09:43 0:00 /sbin/mingetty /dev/tty1 root 2714 0.0 0.0 4064 592 tty2 Ss+ 09:43 0:00 /sbin/mingetty /dev/tty2 root 2717 0.0 0.0 4064 592 tty3 Ss+ 09:43 0:00 /sbin/mingetty /dev/tty3 root 2719 0.0 0.0 4064 592 tty4 Ss+ 09:43 0:00 /sbin/mingetty /dev/tty4 root 2721 0.0 0.0 4064 588 tty5 Ss+ 09:43 0:00 /sbin/mingetty /dev/tty5 root 2723 0.0 0.0 4064 588 tty6 Ss+ 09:43 0:00 /sbin/mingetty /dev/tty6
TTY
- ttyは実端末という意味。筐体にディスプレイつなげて直接ログインした時。
- vmwareなどでは、黒い画面を実端末として理解している。
$ tty /dev/tty1
- ps のttyの項目にはtty(実端末)とかpts(仮想端末)とか表示される。
- psでtty項目が?なのは、標準入出力先の端末デバイスが指定されてないから。
PTS
ptsはsshなどの仮想端末。MACでの表示もこれだったような。
$ tty
/dev/pts/3
rloginなどを使ってsshでつなげて表示される黒い画面は、ディスプレイの中に仮想的にソフトウェアで作り上げているので仮想端末と呼ばれている。ttyは実端末という意味。