阿里雲サーバCPUはトラブルシューティング解決チュートリアルを満載している
運送と開発にとって、最も夜中に目を覚ますアラームは「あなたのクラウドサーバECSインスタンスシステムのCPU使用率は100% に達しました」ではありません。
CPU満載とは、サーバのすべての計算力が瞬時に搾られ、続いてwebサイトが詰まったり、API応答がタイムアウトしたり、データベース接続がいっぱいになったりして、業務全体が麻痺していることを意味する。このような状況に直面して、初心者はしばしば慌ててコンソールに行ってサーバーを再起動する。再起動は一時的に救急できるが、根本的な原因が見つからなければ、5分後もCPUは再び100% になる。
今日のこのチュートリアルでは、経験豊富なベテランのように、冷静で規範的に阿里雲サーバのCPUが満載の問題を調査して解決します。
第一段階: 誤区調査と「診察」前の準備
命令を叩く前に、先に行ってください
Alibaba cloudコンソール
監視盤を見て、重要な指標を確認します
基本型(Tシリーズ) のCPU積分
。
もしあなたが阿里雲の「突発的な性能型インスタンス」 (例えばt5、t6) を買ったなら、このようなサーバは普段、基礎CPUの計算力を制限している (例えば、わずか20%)。業務が基準を超えた場合、「CPUポイント」を消費して全額の計算力を得る。ポイントがなくなると、サーバは強制的に「制限速度」され、CPUがある低レベルでロックされ、システムカードが動けなくなることを示している。
解決策: 突発的なパフォーマンス型インスタンスのポイントが不足している場合は、コンソールで「パフォーマンス制約なしモード」をオンにするか、「汎用型」または「コンピューティング型」インスタンスに直接アップグレードします。
ハードウェアモデルの制限を排除した場合、サーバ内部には確かにプロセスが狂っていることを示し、システムにログインして「泥棒を捕まえる」ことを始めなければならない。
第2段階: LinuxサーバCPUフル・トラブルシューティングの全ステップ
LinuxサーバはCPUの爆発的な高発区で、大部分は悪いコード、高合併、あるいは鉱山のトロイの木馬を掘るためである。
第一歩: 「食べる」計算力の首謀者を探し出す (
トップ
コマンド)
SSHを使ってサーバーに接続し、端末に直接全宇宙共通のコマンドを入力します。
バッシュ
トップ
インタラクティブ画面に入ったら、キーボードの大文字を押します
P
(Shift + p) は、プロセスをCPU使用率の高い順にソートします。
最初の行を見つめて、次の3つのコアフィールドを観察します
PID: プロセスの身分証明書番号、後の殺人プロセスはすべてそれに頼っている。
USER: どのユーザーがこのプロセスを起動しましたか。Wwwやnginxであれば、大きな確率はコードの問題であるrootであれば、名前がおかしいので、トロイの木馬に気をつけてください。
COMMAND: プロセスの名前。
よくあるCOMMAND容疑者の分析:
Php-fpm、java、node、python: ビジネスコードがデッドサイクルを走っているか、高同時でデータベースにインデックスが付けられていないため、無理に担いでいる。
Mysql: データベースは複雑な関連クエリ、全テーブルスキャンを実行しています。
Kswapdo: システムメモリが足りなくなりました。メモリデータをハードディスクのSwapパーティションに移動しています。
Kinsing、sysrv、一連のランダム文字化け: おめでとう、サーバーがハッキングされた、これは古典的な採掘トロイの木馬である。
第二ステップ: 深さ剥離、プロセス内部が何をしているかを見る
自分のコード (JavaやPHPプロセスなど) がCPUをいっぱい食べていることを発見すると、PIDだけでは足りないので、どのコードが悪魔になっているのかを知る必要がある。
シーンA:Javaプロセス満載の調査 (古典面接と実戦問題)
満載のJavaプロセスPIDが
1234
。
このプロセスで最もCPUを消費するスレッド・スレッド番号 (TID) を見つける: Bashtop -Hp 1234は、スレッド1256がCPUの90% を占めていると仮定している。
このスレッド番号を16進に変換します (Javaスタックには16進が使われているため): bashつくっ "% x \ n" 1256 # 出力結果は4e 8と仮定します
Jstackツールを使ってJavaのスレッドスタックを印刷し、正規表現でその16進数のスレッド番号をつかむbashjstack 1234 | grep -A 20 "4e 8" 画面には、どのクラス、どの行のコード (com.xx.service.impl.OrderServiceImpl.lambda $0(OrderServiceImpl) が直接表示されます.java:88)) が実行されており、死のサイクルが一目瞭然です。
シーンB:MySQLがCPUをフルにした
もしそうなら
Mysql
プロセスが1位です。すぐにデータベースにログインして実行します
SQL
全プロセスリストを表示する；
現在実行中のSQL文を表示します。重点的に見る
時間
(実行時間) が最も長い文は、大量の文を見ると
Select ing
状態でインデックスをつけていない腐ったSQLは、インデックスをつけて開発したことを直接通知したり、DBAに一時的にこの腐ったSQLを殺させたりする。
第三ステップ: 思い切った処置 (優雅に終わる方法)
ケース1: 通常のコードのデッドサイクル
生存に影響が出たら、まずPIDでプロセスを殺して息を吐く時間と交換することができる
バッシュ
Kill-9プロセスPID
すぐにコードバグを変更します。
状況2: 鉱山を掘るトロイの木馬に当たった
ハッカーは通常定時任務を掛けます。
Kill-9
それは死なず、一秒で復活する。
定時タスクをチェックする: crontab -l、奇妙なダウンロードスクリプトがあることを発見し、すぐにcronを使う
Tab-e削除。
残留プロセスをチェックして殺す。
究極の武器: トロイの木馬が大面積で感染した場合、最も速くて清潔な解決策は「スナップショットを利用してシステムを回復する」か、前文を参考にシステムを直接再インストールする。
第3段階: WindowsサーバCPUは全手順を完全にチェックします。
Windowsサーバは比較的直感的で、グラフィカルなインタフェースで直接解決します。
ステップ1: タスクマネージャを開く
リモートデスクトップはサーバーに接続します。
下部のタスクバーを右クリックし、タスクマネージャを選択します。
CPU列のヘッダーをクリックして、使用率が高い順にソートします。
ステップ2: リソースモニターの詳細
タスクマネージャは時々しか見えない
W3wp.exe
(IISプロセス) または
Sqlservr.exe
高くて、細かいところが見えません。
タスクマネージャの下部で、をクリックしてリソースモニタを開きます。
CPUタブに切り替えます。
ここでは、各プロセスの具体的なサービスを見ることができます。W3wp.exeが急増している場合、IIS上のあるサイトコードに問題があることを説明し、IISの「作業プロセス」で具体的にどのサイトのどのURLが狂ってリソースを消費しているかを調べることができる。
第四段階: 予防は治療より優れています。CPUが再び満杯になるのを防ぐにはどうすればいいですか?
今回の火を消した後、夜中に目を覚ますためには、3つの防御線をつけなければならない
阿里雲コンソールで「CPUアラームルール」を構成する: クラウド監視-> アプリケーショングループまたはホスト監視に入る。サーバにアラームを追加します。CPU使用率 >= 85% が5分続くと、すぐに携帯電話にメール/ホッチキスのアラームを送信します。100% になる前に介入してください。
データベースに「スロークエリログ」を追加する: MySQLのslow _ query _ logを開いて、実行時間が1秒を超えるSQLをすべて記録します。毎日、開発の最適化に配布し、潜在的な危険を萌芽状態に撲滅する。
コード層設定タイムアウトメカニズム: 外部API呼び出し、複雑なループ、マルチスレッドにかかわらず、最大タイムアウト時間を設定します。デッドサイクルを無期限に一時停止させて計算力を消耗させないでください。
まとめ
CPU満載をチェックするのは泥棒を捕まえるようなものです
まずtop/タスクマネージャで容疑者 (PID) をロックし、jstack/PROCESSLISTで犯罪証拠 (どの行のコード/どのSQL) を入手し、最後に思い切って処理し、監視警報を追加する
。
問題に遭遇したら決して慌てないで、標準的なプロセスに従って何度も剥離して、システムを死なせる腐ったコードやトロイの木馬は何も見えない。