Subscribed unsubscribe Subscribe Subscribe

目の前に僕らの道がある

勉強会とか、技術的にはまったことのメモ

サーバが重いときの対策メモ

この話はかなりコンテキスト依存なので、自分メモです。
この辺、体系的に教えてもらったこと無いので、ツッコミどころは満載です。

そのサーバの役割は何か

普通だったらサーバ管理表やサーバ管理アプリに当該サーバの役割とプロジェクトが記載されているはずです。

そもそも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を張るなり、一時的にキャッシュしてやるなり、そもそも使わなくするなりしてあげます。

サーバを増やす

すぐには解決できないような問題であれば、短期的にはサーバを増やすのが現実解だと思います。