この話はかなりコンテキスト依存なので、自分メモです。
この辺、体系的に教えてもらったこと無いので、ツッコミどころは満載です。
そのサーバの役割は何か
普通だったらサーバ管理表やサーバ管理アプリに当該サーバの役割とプロジェクトが記載されているはずです。
そもそもpingが通るか
pingが通らなければ、どうしようもないです。
サーバが死んだか、gatewayが死んだか、アクセスネットワークが死んだかが考えられます。tracerouteしてみてどこが死んでいるのかしらべてみるといいでしょう。
sshで繋げるか
pingが通るけど当該サーバにssh接続できない場合は、単純に重いかOOM Killerが走っている場合があります。
どうしようもなければ、IPMIもしくは管理コンソール経由でサーバを再起動する必要があるでしょう。
ロードアベレージ(LA)は高くないか
何は無くともLAの状態を見ます。
お手軽に見るならuptime使うと良いです。左から1分毎、5分毎、15分毎のLAを表します。
% uptime 15:27:22 up 43 days, 20:52, 10 users, load average: 0.14, 0.14, 0.16
I/Oバウンドか、CPUバウンドか
アプリケーションサーバならいつもより多く接続が来てないか、DBサーバならいつもよりクエリの量が多かったりIO負荷が高くないか見ます。
過去の統計を見るためにsar (CPU)、sar -u(メモリ)などを叩きます。
また、現在のスナップショットを知るためにvmstat 5やdstat -tam 5を叩いてみます。
何がリソースを使っているのか
topを使って、リソースを食いつぶしているプロセスを確認します。
ソートするカラムを変更するには'<'か'>'キーを使用します。
直前に変な変更入れてないか
私の場合は、会社でも家でもgitを使用しているのでgit log -pもしくはtigで変更履歴を確認します。
普段と違うことしてないか
たとえば、アプリの場合だったらイベントをやっていたり、サービスの場合だと何か祭りになっていてアクセスが集中していたり、原因となるようなものを特定します。
殺せるスクリプトないか
負荷を下げるために実行を中止しても良いようなcronやジョブを殺してして少しでも負荷を軽減します。
実際にボトルネックになっているのはなにか
アプリケーションサーバに問題がないのであればだいたいは、DBの方に問題があることが多いので、見てみます。
SHOW FULL PROCESSLISTを叩いてみて、いつもよりプロセスが多くないか確認します。いつもより多ければ詰まっています。
次にクエリを解析してみます。(ちなみに今回はMySQL限定の話)
まず、mysqlのslowlogを見て目立つクエリが無いかを確認します。目で集計してもよいのですが、percona-toolkitのpt-query-digestが便利なので、こいつで解析します。
入力はslowlogからでも大丈夫なのですが、slowlogに記録されないクエリが問題になることも万が一あるので、tcpdumpの結果を入力とします。
※tcpdumpのファイルはかなりでかくなるのと、pt-query-digestはかなりcpuを使うので注意
tcpdump -i eth0 port 3306 -s 65535 -x -nn -tttt -l > /tmp/mysql.txt pt-query-digest --type tcpdump /tmp/mysql.txt | lv
お馬鹿なクエリがあれば、INDEXを張るなり、一時的にキャッシュしてやるなり、そもそも使わなくするなりしてあげます。
サーバを増やす
すぐには解決できないような問題であれば、短期的にはサーバを増やすのが現実解だと思います。
