序文
木曜日に、サーバが突然ハングアップ。SSHはおそらく3Kアプレットの毎日の訪問については、直接ダウン背景オフ、日々のアプレットを接続されていません。それは調査の後、開かれて以来。
調査段階
最初のサービス回復を言う、ともかく。再起動アリクラウドサーバ、SSH接続。オープンnginxの、Redisのは、MySQL、Javaサービス。一連の操作は、まず最初にサービスを開始しました。
ServerがインストールさCloudMonitor（クラウドモニタリング）、 CPU、メモリ、非常に参考に閲覧、非常に問題のトラブルシューティングに、インストールすることをお勧めします。
ビューCPU、メモリは、次の通り：
私たちは、ネットワークの流入と流出率はすぐに高騰したときにはっきりと周り9.30見ることができ、最後のフィギュアルックスで始まります。したがって、ネットワークに関連付けることができる、最初に、CPU、メモリが舞い上がる結論付けることができます。
9.30分について、サーバーはおそらく、ネットワークに関連するいくつかのアプリケーションを実行しています：
- mysqlの
- 繰り返します
- ngxin
- Javaサービス（OSC、記号など）
- ドッキングウィンドウ
明らかに最初の3人の日常のアプリケーションでは、基本的にはない問題は、まずすべての除外します。残りはJava関連のサービスとドッカーです。
最初のアイデアは、死者へのトラフィックにおけるJavaの急激な増加、そして十分なサーバリソース、およびサービスではありません。その後、関連するログJavaサービスを見に行ってきましたあまり変化せずに通常のトラフィックと、例外ではありません9.30ポイントを見つけました。それは除外されます。
だから、サービスがドッキングウィンドウです。
私は彼らの問題を磨くために、定期的な一日の仕事を持っていますドッカー。基本的にはより多くの日が始まります9よりも、その後、11：00をオフに停止します。ログイン後、ドッカ見ます：
我々は明らかに、チャンスの際に9.23ポイントを見ることができます。オープンドッカー、質問を磨くようになりました。これは、ドッキングウィンドウポットと結論付けることができます。この時点で、ドッキングウィンドウは、これまでのところ全く問題がなかった中で、定期的なタスクをオフにし、殺します。
現在の問題で
問題がドッキングウィンドウであるかどうかを判断するには、その後、数日後、私は、ドッキングウィンドウの定期的なタスクを開きました。次のようにサーバリソースを確認します。
再発行に再現し、ドッキングウィンドウの鍋であることは明らかです。このサービスは、ドッキングウィンドウになっている理由については、メモリを急増し、CPUは、サーバーに直接リードすることはダウンして、急騰しました。このような理由から、我々は、画像の作者に尋ねなければなりません。
个人初步猜想，内存泄露了。
我们可以仔细观察下内存的图片。约9.30的时候docker服务启动，内存上升至70%左右，这都是非常的合理的。
在大概10点左右的时候，任务跑完了(通过查看日志）。但服务并没有stop。
从10点开始，内存一路飙升，飙升至95%，最终我kill掉了docker，内存回归正常。
这是很明显的内存泄露，因为此镜像为私人镜像，并且不开源，具体代码无从查起，也是没有办法的了。
不过已向改仓库提了issue。https://github.com/fuck-xuexiqiangguo/docker/issues/20
总结
从这次服务器挂掉，有以下几点感想。
- 日志很重要，无论是什么服务，一定要记得把日志排在首位
- 服务器一定要有监控，并且要有监控预警，超过多少，发短信，电话通知。
- 问题思路排查要有理有据，一步一步来，不能瞎子抓阄似的。
- 服务挂掉，首先要恢复服务，比如重启等操作
这次服务器宕机并没有任何影响，毕竟没啥用户，不过感觉对问题的排查更加深刻了。业务推动技术，这点是毋庸置疑的了。
而且业务上线后，慢慢也会出现很多问题，一个一个解决，也能学习到很多东西。