複数のローカルユーザー（または数千人のウェブユーザー）が使用するネットワーク上のビジーなシステムでは、ライフサイクル中にパフォーマンスの問題が発生します。忙しくないシステムだけが、私たち全員を悩ませているパフォーマンスの問題の影響を受けません。この記事では、パフォーマンスの問題を見つけて修正するための通常の容疑者について説明します。
以下は、「開始する場所」の基本的な概要である一般的なガイドラインです。問題はそれぞれ異なりますが、経験を積むにつれて、特定の問題をどこでどのように探し始めるかについて、より良いアイデアが得られます。トラブルシューティングの基本を教えることはできますが、経験や直感を教えることはできないと思います。それらは両方とも時間とともに来ます。また、いくつかの問題は、ある道を歩み始め、しばしば別の道に導かれるような形で現れることに注意してください。この要因は苛立たしいですが、正常です。たとえば、特定のディスクの問題によりCPUの使用量が急増したり、メモリの問題がディスクのパフォーマンスの問題として自分自身を覆い隠したりする可能性があります。最初に簡単なものから始めて、次にもっと複雑なものに進んでください。必要以上にあなたの人生を複雑にしないでください。ネットワークケーブルを交換するか、システムを再起動する必要がある場合があります。シンプルですが効果的です。
最近の変更を元に戻す
本番環境で変更を加える必要があります。これらの変更を文書化することは必須です。何かがうまくいかないとき、あなたはあなたがしたことをうれしく思うでしょう、そしてそれはそうなるでしょう。 Linux（またはその他のシステム）で変更を加えることの奇妙な点は、変更自体が完全に機能する可能性があることですが、1〜2日でシステムのパフォーマンスが低下します。他の作業を行う前に、変更ドキュメントをチェックして、システムに最近変更が加えられたかどうかを確認してください。変更には、ソフトウェアパッチ、あらゆる種類の更新、ハードウェアの交換またはアップグレード、ドライバーの更新、ファームウェアの更新、コードプッシュ、新しいソフトウェアのインストール、および構成の変更が含まれます。
変更のドキュメントを確認するときは、最近の変更と発生している問題を比較してください。通常のシステムチェックを行った後、一度に1つずつ変更を元に戻して、パフォーマンスの根本原因に追跡できる変更を確認する必要があります。特定のアップデート「クラスター」に互換性がない場合や、特定の順序でインストールまたは適用する必要がある場合があります。これが当てはまるかどうかを確認するには、常にベンダーのドキュメントを確認してください。
更新、更新、更新
特にサーバー側のソフトウェア（Webブラウザーのようにクライアント側ではなく）に関しては、すべてを最新の状態に保つことで、ソフトウェアとハードウェアのバグに関連するパフォーマンスの問題を回避できます。もちろん、クライアント側も更新する必要がありますが、それは別の議論です。
はい、すべてのシステムを最新の状態に保つのはフルタイムの仕事です。 BIOS、ファームウェア、ドライバー、オペレーティングシステム、アプリケーション、エージェント、セキュリティソフトウェア、データベース、バックアップソフトウェアなど、システムで更新する必要のあるものは常にあります。このタスクは決して終了しません。これらの更新を計画、スケジュール、および適用するために、更新する必要がある頻度を決定するか、組織のパッチ適用ポリシーに準拠します。私の仕事の1つでは、週に1回パッチを適用しました。そうすることは苦痛でした。週に1回、一晩中引っ張る必要がありましたが、これは早く古くなります。ただし、定期的にそうすることは避けられません。システムが安全であり、最新の安定性パッチが適用されていることを確認するために更新する必要があります。
システムが最新であり、利用可能な新しいアップデートがない場合は、通常、パフォーマンスの問題の根本原因としてアップデートとパッチを除外できます。
ハードウェアの制限と障害
私の経験では、すべての人（プログラマー、ネットワーク管理者、管理者、ベンダー）が、すべてのパフォーマンスの問題についてインフラストラクチャを非難したいと考えています。彼らは皆、インフラストラクチャが最も弱いリンクであり、そこでブレークが発生する可能性が最も高いと信じているため、誰かが行動を起こす前に、ハードウェアが問題を引き起こしていないことを証明する必要があります。私はある点に同意しますが、それが最初の仮定である場合、他の潜在的な原因と同時に調査されるものではなく、少し厄介です。
通常、障害が発生するか、問題を引き起こす可能性のある制限に達する可能性のあるハードウェアコンポーネントは、CPU、ネットワーク、メモリ、ディスクの4つです。電源など、故障する可能性のあるコンポーネントは他にもありますが、これらの「ビッグ4」が最も一般的な原因であり、問題が発生したときに最初に確認する必要があります。
CPU
最近のほとんどのサーバーシステムには、マルチコア、マルチプロセッサのCPUバンクがあります。 CPUに問題がある場合は、CPU自体の欠陥が原因である可能性があります。問題を引き起こしている特定のCPUを見つけることは、この記事の範囲を超えています。実際のCPU障害または異常が疑われる場合は、システムベンダーに連絡してアドバイスを求めてください。問題のあるCPUを特定するために実行できる診断ルーチンがある可能性があります。それを超えると、1つのCPUまたはすべてのCPUを交換するために技術者を派遣します。
では、CPUの完全な障害以外に、CPUの問題が疑われる場合は何を探しますか？ topを確認してください プロセスがCPUに過負荷をかけていないかどうかを確認します。 topを並べ替える CPUの場合は、topを実行します 次に、Pと入力します （Shift + P）。 CPUサイクルを焼き尽くすプロセスを見てください。リストの一番上にあるのは、システム関連またはアプリケーションですか？システムプロセスの場合は、稼働時間を確認してください。定期的に再起動するため、稼働時間は極端に長くなることはありません。
異常な量のCPUサイクルを使用している特定のアプリケーションを見つけた場合は、アプリケーションを再起動して、問題が解決するかどうかを確認します。プロセスがシステムに関連している場合は、可能であればプロセスを再開してみてください。そうでない場合は、システムを再起動します。はい、システムを再起動します。
トラブルシューティングボーナス（再起動）
はい、少なくとも月に1回は再起動する必要があります。この慣行については多くの議論があることは知っていますが、多くの問題を除外するために、適切な再起動は多くの問題を解決し、最小限の労力でハードウェアの問題を診断するのに役立ちます。コールドブートからシステムを起動すると、実行中のシステムに隠れている可能性のある多くのハードウェアの問題を特定できるため、システムの電源をオフにすることも良い習慣です。再起動後もパフォーマンスの問題が続く場合は、問題を絞り込むこともできます。
メモリ
パフォーマンスのトラブルシューティングを行うときに次に注目すべき最も明白な場所は、メモリの使用です。記憶の問題は、記憶が実際に問題であるという事実を曖昧にするさまざまな方法で現れる可能性があります。 1日の間にシステムのメモリが消耗していることに気付いた場合、最初に確認するのはログです。クレイジーに聞こえるかもしれませんが、ログをキャプチャするには、私が数百万ドルで働いていた会社の費用がほとんどかかります。パフォーマンスレポートで、クラスターシステムのメモリが日中に使い果たされていることに気づきました。使用可能なメモリはギガバイト単位であったため、この問題は発生していないはずです。さらに、日が経つにつれてパフォーマンスが悪化しました。毎晩真夜中に、すべてが戻ってきます。真夜中に何が起こったのですか？ログローテーション。どうやら、誰かがログのデバッグをオンにしていたようです。つまり、1日あたり数十ギガバイトが収集され、バックアップされ、不必要に保存されていました。そして、それは私たちの記憶を消耗させていました。発見されて修正されると、パフォーマンスは完全に回復し、この巨大なクラスターの追加システムに数百万ドルを費やす必要性が軽減されました。
メモリの問題が疑われる場合は、スワップスペースも確認する必要があります。この出力では、システムがアイドル状態であるため、結果は劇的ではありません。 free -mを使用します 物理および仮想（スワップ）メモリ使用量を確認するコマンド：
$ free -m
total used free shared buff/cache available
Mem: 821 200 288 10 333 484
Swap: 0 0 0
多くのスワップを使用している場合、システムは*nix管理者が「スラッシング」と呼ぶことを実行している可能性があります。スケートボーダーがすることとは反対に、スラッシングは私たちにとって悪いことです。あなたはあなたのシステムがスラッシュすることを望まない。スラッシングは、それが十分に深刻な場合、ディスクの問題として現れることもあります。システムがページングインとページアウトでビジー状態になり、ディスクパフォーマンスに影響を与える場合は、問題のあるプロセスを再開してすぐに対処する必要があります。さて、誤解しないでください。スワップは、ディスクにページングするように設定および構成されていますが、パフォーマンスの問題が発生する場合は、この問題を修正する必要があります。
最近のシステムの多くはメモリが多すぎるため、ディスクベースのスワップはまったく使用されていません。一部の管理者は、それがディスクスペースの無駄だと感じています。私の場合、スワップを構成するかどうかは、システムの目的とRAMの容量によって異なります。スワップに関する考慮事項は実際には別の記事ですが、スワップの処理方法はあなた次第です。 1.5xRAMの古いルールはもはや良い公式ではないと思います。考えてみてください。システムに128GBのRAMがある場合は、スワップスペース用に192GBのRAMを構成することを意味します。ばかげている。スワップを構成した場合、そのシステムに最大16GBを設定する可能性があります。
まれに、RAMが故障したり、故障したりすることがあります。私はそれを起こさせました。アップグレードする場合は、システム用に購入するRAMのタイプにも注意する必要があります。あなたが持っているものと一致するか、一致しない場合はすべてを置き換えます。速度、キャッシュ、またはブランドを混在させないでください。また、システムに推奨されるRAMタイプを使用してください。ブランド外または不一致のRAMを使用することは、起こるのを待っている災害です。
最後に、誤ったプログラムはメモリの問題を引き起こす可能性があります。 Javaベースのプログラムは、歴史的に私に最も悲しみをもたらしてきました。一部のJavaプログラマーは、ガベージクリーンアップまたはメモリ解放を正しくプログラムせず、負荷が高い場合や特定の呼び出しが行われた場合に問題が発生します。私はいつもプロセスを再開することから始めます。次のオプションは、topを確認することです。 プログラムによって消費されるメモリの量。すべてのチェックとプロセスの再起動が機能しない場合は、システムを再起動します。問題が再び発生した場合は、プログラマーのところに行き、文句を言ってレポートを提供します。
ディスク
ディスクに障害が発生します。それは強力ですが本当の主張です。 SSDでさえある時点で故障するので、ディスクの故障に備えてください。 RAIDはバックアップと同じではなく、ディスクとパーティションがいっぱいになるため、最適なパフォーマンスでは動作しないことに注意してください。ディスクがパフォーマンスキラーであると思われる場合、最初に確認するのは、クイックdfを備えた使用可能なスペースです。 コマンド：
$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 397M 0 397M 0% /dev
tmpfs 411M 0 411M 0% /dev/shm
tmpfs 411M 11M 400M 3% /run
tmpfs 411M 0 411M 0% /sys/fs/cgroup
/dev/sda2 16G 1.8G 14G 12% /
/dev/sda1 495M 152M 344M 31% /boot
tmpfs 83M 0 83M 0% /run/user/1000 上記のように、私のサーバーには完全またはほぼ完全なファイルシステムがありません。
次に確認する項目は、ファイルシステムがいっぱいかほぼいっぱいかです。ない場合は、ディスクに障害が発生しています。ディスク障害をシミュレートすることはできませんが、一部のサーバーシステムは、ディスクに障害が発生したときに通知します。たとえば、古いサーバーの中には、何か問題が発生したときに緑色のライトではなく黄色のライトを表示するものがありました。ハードウェアインジケータに注意してください。また、障害やエラーを通知する小さなLCD画面を備えたサーバーもありました。これらのツールは、オペレーティングシステムが問題があることを通知しなかった場合に役立ちました。
障害のあるディスクは、構成に関係なく、パフォーマンスに影響を与えます。 RAID構成は、メンバーディスクに障害が発生した場合のパフォーマンスを保証するものではありません。代わりに、冗長性があるため安全性が保証されます。つまり、データはそのままですが、パフォーマンスが低下するため、ユーザーと顧客は不満を抱きます。メンバーディスクに障害が発生すると、パフォーマンスの問題が発生する可能性があります。
システムの動作が遅い場合は、物理サーバーとそのすべてのコンポーネント、アラート、およびメッセージを確認してください。この手順は、物理サーバーにアクセスできるユーザーを対象としています。非常に多くのシステム管理者は、リモートシステムまたはホストシステムを処理する必要があるため、この種のアクセス権はありません。
ネットワーク
ハードウェアによるネットワークの問題はややまれですが、実際に発生します。 NICのジャバリング、ケーブルの不良、またはスイッチやスイッチポートの障害は、システム管理者にとって大きな不満の原因となる可能性があります。また、ホスト自体にスイッチポートまたはネットワークの設定ミスを追加すると、多くの髪を引っ張るレシピが得られます。問題はローカル、スイッチ、またはスイッチ以外の場所にある可能性があるため、ネットワークの問題の原因を見つけるのが難しい場合があります。問題を見つけるには、各レベルを個別に調べる必要があります。
比較のために他のホストを確認してください。問題は単一のホストに限定されていますか、それとも単一のグループに限定されていますか、それともシステム全体に問題がありますか？このチェックは、問題がローカルであるかどうか、単一のスイッチに限定されているかどうか、ラックまたは列全体に影響するかどうか、または問題がより広範囲に及ぶかどうかを識別するのに役立ちます。
ローカルネットワーク構成を確認してください。変更ログをチェックして、最近何かが変更されたかどうかを確認します。次に、NICの物理チェックを行います。ライトはあなたに正しく見えますか？ケーブルは見栄えがよく、プラグは損傷していないように見えますか？ワイヤー構成は正しいように見えますか？可能であれば、ケーブルの全長に物理的な損傷がないか確認してください。物理スイッチとスイッチのケーブルターミネータに物理的な欠陥がないか確認してください。
自分でスイッチの構成を確認するか、ネットワーク管理者に確認を依頼してください。スイッチの場所を物理的に確認するか、ドキュメントを参照して、ネットワーク管理者に報告する正しいポートを見つけてください。構成に問題がない場合は、ネットワーク管理者にポートのクイックリセットを実行してもらいます。また、最後のスイッチの更新と最後の再起動日について管理者に問い合わせてください。
仕事や職場によっては、スイッチ以外の制御や可視性がない場合があります。ネットワーク管理者、ISP、またはホスティングプロバイダーと協力して、ネットワークパフォーマンスの問題をさらに特定します。個人的な経験によると、ネットワークの問題が広まっていない限り、ネットワーク管理者は、ネットワークのせいにしたチェック内容の証拠を求めています。このため、ネットワークのトラブルシューティングをリストの最後に配置しました。 「ネットワークではありません。インフラストラクチャである必要があります」という苛立たしい言葉を聞いた回数は数えられません。そして、ダイヤルトーン。
まとめ
トラブルシューティングの知識を得るための近道はありません。学習して準備することはできますが、残念ながら、塹壕でのトラブルシューティングを実際に感じる前に失敗を経験する必要があるため、経験が最高の教師です。シミュレートされた障害でさえ、実際の障害と同じエクスペリエンスを提供するわけではありません。実際のユーザーは問題がいつ修正されるかを尋ね、実際のマネージャーは会社がお金を失っているのはあなたのせいであると見なし、キーボードがそうではないことを怒らせます。音を立てる。
問題のトラブルシューティングは、システム管理者になることの楽しい部分ではありませんが、必要な部分です。実際、楽しい部分があるかどうかはわかりませんが、それらはすべて必要です。システム管理者になることはストレスが多く、問題のトラブルシューティングはそのストレスの大部分を占めます。そのストレスを軽減するための指針を示しましたが、それでも、それらを使用するための経験と自信を得るのはあなた次第です。