kazu634
/
blog
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
blog/content/post/2014-03-02-00001587.md

9.0 KiB
Raw Blame History

title author date url geo_latitude geo_longitude geo_public wordtwit_posted_tweets wordtwit_post_info categories
DevOps Troubleshooting: Linux Server Best Practiceはすごい本 kazu634 2014-03-02 /2014/03/02/_1802/
38.306185
141.022634
1
a:1:{i:0;i:1835;}
O:8:"stdClass":13:{s:6:"manual";b:0;s:11:"tweet_times";i:1;s:5:"delay";i:0;s:7:"enabled";i:1;s:10:"separation";s:2:"60";s:7:"version";s:3:"3.7";s:14:"tweet_template";b:0;s:6:"status";i:2;s:6:"result";a:0:{}s:13:"tweet_counter";i:2;s:13:"tweet_log_ids";a:1:{i:0;i:1835;}s:9:"hash_tags";a:0:{}s:8:"accounts";a:1:{i:0;s:7:"kazu634";}}
インフラ

DevOps Troubleshooting: Linux Server Best Practiceを読んでいました。この本、Linuxでトラブルシューティングする人にはとてもお勧めです。他のOSに普段触る人でも、ここで基本的な部分を押さえれば、応用が効かせられるようになるはず！！！とてもお勧め！

この本の立ち位置

冒頭部分で次のように書かれています:

What makes this book more than just a sysadmin troubleshooting guide is the audience and focus. This book assumes the reader may not be a Linux sysadmin, but instead is a talented developer or QA engineer in a DevOps organization who may not have much system-level Linux experience.

要するにシステム管理者を読者としては想定せず、開発者・QAの人間を読者として位置付けている。この特殊な立ち位置がこの本をとても興味深くしていると思う。

問題の切り分け方について

こんなことが書いてあった:

  1. Divide the problem space
  2. Practice good communication when collaborating
  3. Favor quick simple tests, over slow, complex tests
  4. Favor past solutions
  5. Document your problems and solutions
  6. Know what changed
  7. Understand how system works
  8. Use the internet, but carefully
  9. Resist rebooting

Why is server slow?

Load Averageが高い場合には要因が三つ考えられる:

  1. CPU-bound
  2. RAM-bound (high RAM usage)
  3. I/O-bound (Disk or Network)

通常、CPUバウンドの時の方がI/Oバウンドの時よりもレスポンスが良い傾向にある。

topコマンドについて

負荷が高い場合にまずはtopコマンドで解析を行う。topコマンドの出力例はこちら:

top_output

まずはロードアベレージを確認する。ロードアベレージが適切かどうかは、CPUのコア数などによって異なる。コア数はcat /proc/cpuinfo | grep processor | wc -lで調べる。ロードアベレージがコア数の範囲であれば適切と判断できる。

CPU(s)の部分の読み方は以下の通り:

us: user CPU time

Nice値を変更していないユーザプロセスに対して割り当てられているCPU時間の割合。

sy: system CPU time

カーネルとカーネルプロセスを実行するために割り当てられているCPU時間の割合。

ni: nice CPU time

Nice値を変更したプロセスに対して割り当てられているCPU時間の割合。

id: CPU idle time

この値が高い場合CPUバウンドではない。

wa: I/O wait

I/O待ちをするために割り当てられているCPU時間の割合。この値が低い場合には、ディスク・ネットワークI/Oに起因して負荷が高まっているわけではないと言える。

hi: hardware interrupts

ハードウェアの割り込みに割り当てられているCPU時間の割合。

si: software interrupts

ソフトウェアの割り込みに割り当てられているCPU時間の割合。

st: steal time

ゲストOS内でtopコマンドを実行している場合、この数値から他のタスクに割り当てられたために利用できなくなったCPU時間の割合がわかる。

Why can't I Write to the Disk

ディスク使用量の調査には、du -ckxを使う。

df -hでディスク使用量を確認して異常が見当たらない場合は、inodeの枯渇を疑う。inodeが枯渇しているかどうかは、df -iコマンドで確認できる。

read-onlyになる原因は以下のものがかんがえられる:

  1. 容量の枯渇
  2. inodeの枯渇
  3. マウントオプションなどで read-only を指定している
  4. Linux Software RAIDを使用している場合、RAID障害の可能性を考慮する

Is the server down?

サーバがダウンしているように見える場合の対応方法について:

  1. ケーブルが刺さっているか
  2. インターフェースの設定は正しいか？
  3. Default Gatewayの設定は適切か？
  4. DNSは動いているか？
  5. 対象サーバに到達できるか？
  6. リモートポートが開放されているか？
  7. リモート側で netstat -lnpやiptables -Lしてみる

ethtool デバイス名でケーブルにつながっていることを確認できる。ifconfig デバイス名でインターフェースの設定を確認できる。route -nでDefault Gatewayを確認できる。DNSの動作はnslookupで確認する。resolv.confのsearchの設定値に注意する。対象サーバに到達できるかかどうかはtracerouteで確かめる。

DevOps Troubleshooting: Linux Server Best Practices
Addison-Wesley Professional (2012-11-09)