突然アクセスできないのか?阿里雲ECS CPUがいっぱい (100%) のトラブルシューティングと最適化チュートリアル
サイトは昼間はまだ元気で、夕方に突然カードが死んで、ブラウザがぐるぐる回って、最後に「504 Gateway Timeout」または「接続できない」と報告した。
驚いたことに、すぐに阿里雲コンソールに接続して、ECSインスタンスの監視を見た
CPUが満載で、100% の赤い線を引いた。
このような場面は、ほとんどの個人駅長と運送次元開発が出会ったことがある。このような状況に遭遇したら、まず慌てないでください。急いでサーバーを再起動しないでください。今日は虚しい理論を話さないで、直接セットを渡します
オンライン生産環境のトラブルシューティングと軍規の最適化
、手順に従って歩いて、5分で舞台裏のマフィアを捕まえます。
コア調査構想: 三歩定位法
CPUがいっぱいになったとき、私たちのトラブルシューティングロジックは次のようになります
全体を見る: どのプロセス (Nginx、PHP、Java、トロイの木馬) がリソースを飲み込んだのか?
ローカル: このプロセスのどのコード、どのスレッド (Thread) 、またはどのSQLが狂っているのか?
次の手: 位置決め後、コードを最適化したり、キャッシュしたり、プロセスを直接殺したりしますか?
最初のステップ: サーバにログインし、問題のプロセスを特定する (1分)
サイトカードがどのようになっても、SSHが接続できる限り、すぐに接続します。ローカルSSHがすでに詰まっていて接続できない場合は、直接阿里雲コンソールを通過します
$ \ Right arrow $
ECSインスタンス
$ \ Right arrow $
リモート接続 (ワークベンチ) が強制的にログインします。
次のコマンドを入力します。これはLinuxがパフォーマンスをトラブルシューティングするための究極のツールです
バッシュ
トップ
に入る
トップ
インタフェースの後、大文字の
P
(CPU使用率でソート)。次のような動的リストが表示されます
プレーンテキスト
PID USER PR NI VIRT RES SHR S % CPU % MEM TIME + COMMAND
12345 nginx 20 354m 45m 12m R 98.5 2.3 12:34.56 php-fpm
6789 mysql 20 2.5g 1.2g 24m S 1.5 60.2 45:12.89 mysqld
結果分析:
1行目の
COMMAND
何ですか
Php-fpmまたはnodeまたはjavaの場合: あなたのサイトのビジネスコードが死んだサイクルに遭遇したか、突然のトラフィックでパフォーマンスが担げないことを示しています。
Mysqldの場合: データベースが遅いクエリ、インデックスがない、または高同時ロックされていることを示します。
Nginxまたはhttpdの場合: 大きい
確率は悪意のあるブラシ量、CC攻撃や爬虫類の狂気に遭遇した。
アルファベットの数字が文字化けしている場合 (kdevtmp fsi、minerなど): 考えないでください。サーバーは暗くなって、鉱山労働者として採掘されました。
ステップ2: シーンを深く細分化し、正確に解体する (3分)
あなたがいることによると
トップ
で見た結果は、指定席で次の解決ルートを選択します。
シーンA:Commandは
Mysqld
(データベースカード死)
これは高周波発生のシーンです。通常、ある業務コードがあまりにもゴミで書かれているため、数十万行のデータを調べてインデックスをつけていない。
1.データベースにログインして、現在実行されているSQLを表示します
端末でMySQLにログインします
SQL
Mysql-u root -p
-- ログインして実行します
SHOW PROCESSLIST;
ヒントリストが長すぎて表示が不完全な場合は、次のように使用できます
SQL
SHOW FULL PROCESSLIST;
2.内鬼を捕まえる
出力されたリストで観察します
Time
(実行時間) が長く、かつ
State
明示的には
Sending data
、
Sorting for group
または
Creating tmp table
の一行。見てみましょう
Info
欄に書かれているSQL文。
緊急避難: 吐血させるスローSQLを見て、そのIdを覚えて、KILL Idを直接実行する (例: KILL 142;) まずデータベースを解放しますサイトはすぐにアクセスを再開できます。
根治案: このSQLを持ってコードの中で原因を探して、すぐにWHEREまたはJOINの後ろのフィールドにインデックスを付けます大きなテーブルに関連付けられている場合は、Redisキャッシュを追加することを検討してください。
シーンB:Commandは
Java
(プログラム内部デッドループ/OOM)
JavaアプリケーションのCPUが急増しているのは、通常、あるスレッドが陥っているからです
While (true)
のデッドサイクル、または頻繁にガベージコレクション (Full GC) が行われています。
1.最もCPUを消費するスレッドをつかむ
JavaのプロセスPIDが
12345
。コマンドを入力して、プロセスの下にあるどのスレッドが最もリソースを消費しているかを確認します
バッシュ
Top-Hp 12345
按る
P
ソート、もし最もCPUを消費するスレッドPIDをつかんだとしたら
12366
。
2.進変換
スレッドPIDを
12366
16進数に変換:
バッシュ
Printf "% x \ n" 12366
# 出力結果: 304e
3.スタック情報の印刷
JDKに付属しているものを利用する
Jstack
ツールは、問題のあるコード行に直接配置されます
バッシュ
Jstack 12345 | grep "304e"-a20
端末は、このスレッドが実行しているJavaコードクラス名と行番号を直接印刷します。過去に見ると、絶対に死の循環であるか、境界を設けていない再帰である。コードを変更して、再配置すればいいです。
シーンC:Commandは
Nginx
/
Php-fpm
(悪意のあるブラシ量/CC攻撃に遭遇)
普段のトラフィックが少ないと、突然CPUが爆発し、Nginxのアクセスログを見た。
1.最近最もアクセスしたIPを集計する
バッシュ
Nginxログが/var/log/nginx/access.logにあるとします
Awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 20
見知らぬIPが数分で何万回も印刷されていることを発見すると、あなたが狙われていることは間違いない。
2.緊急ブロックIP
Linuxに付属しているファイアウォールまたは阿里雲セキュリティグループを直接利用して、このIPをブラックリストに蹴り込む
バッシュ
# Iptablesを使用して禁止する
Iptables-I INPUT -s悪意のあるipアドレス-j DROP
阿里雲を使うと、ECSの「セキュリティグループルール」に、方向性の拒否ルールを追加する。
シーンD:意外な見知らぬプロセス (サーバーが肉鶏/採掘になった)
奇妙なプロセスを見ると、99% のCPUを占有し、経路に沿って正規のソフトウェアが見つからない。
順藤触瓜: ls -l /proc/プロセスPID/exeを使って、この悪意のあるプログラムの隠れ場所を見る。
草の根を断ち切る: Bashkill -9プロセスPID # 強制的にプロセスrm -rf悪意のあるプログラムパス # ウイルスファイルを削除する
裏口をチェックする: ハッカーは通常、定時タスクを書きます。Crontab-lと入力して、ウイルスを自動的にダウンロードするタイミングスクリプトがあるかどうかを確認します。
究極の防犯: 次の赤い線を避けるにはどうすればいいですか?
冷や汗が出た後、私たちはいくつかの基礎的な防御と制限措置をしなければならない。CPUに満点選手になる機会を与えないでください。
阿里雲「クラウド監視」を利用して警報を配置し、ユーザーからのフィードバックが開かなくなってから調査しないでください。阿里雲雲雲監視では、「ECS CPUの使用率が85% を超えて5分間持続すると、すぐにメール/ホッチキスのアラームを送信する」というルールを設定した。兆しが見えたところで介入する。
PHP-FPM/Nginxの最大作業プロセスを設定します
サーバが2コア4gなら、php-fpm.confのmax_childrenを30-40程度に制限します。このようにトラフィックが爆発しても、一部のユーザーは502を提示しているだけで、サーバの基盤はメモリとCPUが完全に搾られてSSHが接続できないことはない。
「柔軟な伸縮」を合理的に利用することは、あなたのサイトやアプリケーションが確かに活動している場合や、上熱捜索で本当の「毎日の流量」を迎えた場合、単体でどのように最適化しても無駄です。急いで阿里雲に行って柔軟な伸縮 (ESS) を開通し、CPUが80% を超えると、自動的にクローンして、2台目、3台目のECSがトラフィックを分担してイベント終了後に自動的にリリースされます。技術の複利で流量の無常に対抗します。