Linuxにおける競合問題とその対応

Linuxシステムの安定性記録は、競合するWindowsシステムに対する多くの批評家にとって良い武器になりました。しかし、Linuxシステムの競合は比較的少ないですが、いったん予期せぬ状況が発生した後は、人々を困惑させるのは簡単です。これらの衝突が発生しないようにするための一般的な方法をいくつか習得することが重要です。

このサイトへのインタビューの中で、Mark WildingとDan Behmanが、Linuxシステムの競合を防止し修正するための比較的単純で直接的な方法を提供しました。 2人は共同で新しい本を発表しました - 「セルフサービスLinux：問題解決の芸術をマスターする」。

Linuxサーバシステムでは競合はないと一般的に考えられていますが、システムにはいくつかの競合と停滞の問題があります。アプリケーションレベルでの競合や停滞は、カーネルレベルとどう違うのですか？

Mark Wilding：アプリケーションレベルの競合や停滞問題は、特定のスレッドやプロセスに限られています。このタイプの競合または停滞は、同じシステム上で実行されている他のスレッドまたはプロセスの競合または停滞を引き起こすことはありません。ただし、カーネルレベルで発生した場合は、システム内で実行されているすべてのプロセスに影響します。

システムの衝突と停滞、それらの違いは何ですか？

Dan Behman：どのレベルでも、衝突と停滞の属性は基本的に同じです。プロセスやスレッドがブロックされたときに停滞が発生します。この時点では、何らかの種類のロックやハードウェアリソースがビジー状態であるため、プロセスやスレッドは待機する必要があります。特定のロックまたはリソースを待つことはよくあることですが、そのようなロックまたはリソースを最終的に実現できない場合に限り、システムが停止することがあります。

停滞の問題は早期に診断できる場合があることに注意することも非常に重要な点です。たとえば、リソース内の特定の瞬間が非常にビジーであり、そのようなリソースを必要とするプロセスまたはスレッドは、リソースがアイドル状態になるまで非常に長時間待機する必要があります。ユーザーはリソースのビジー状態を理解していないことが多く、プロセスが待機していることを確認するだけなので、システムは停止していると思いますが、実際にはシステムは確立されたワークフローに従っていますが、速度は比較的遅いです。

そして、システムの競合の問題は、主に不明なハードウェアまたはソフトウェアのエラーによって引き起こされる上記の停滞とは異なります。このようなエラーが発生した場合、異常なエラーハンドラがそれらの診断およびレポートを呼び出す可能性が最も高いので、エラーの原因を特定できることが期待されます。

競合は、分析する前に分析する必要がある致命的な問題と見なすことができます。停滞問題はリアルタイム問題と見なすことができ、これはリアルタイムで分析および解決することができる。

Linuxの最大の利点の1つは、そのソースコードが公開されていることですが、Linuxが他のオペレーティングシステムとの競合を簡単に解決できる理由は他にもありますか。

Behman：このソースコードが公開されているため、Linuxシステムの各レベルにかなりの数の参照ファイルがあります。同時に、ソースコードが公開されているので、その開発チームも同様に公開されています。このようにして、あなたは彼らが遭遇する問題についてのLinuxカーネル開発者に頼ることができます。そして元の開発者、さらにLinus Torvalds自身も含めて、そしてすべての助けを求めるプログラムはただ電子メールを送っています。 。私の知る限りでは、このLinuxの機能はオープンソースではないオペレーティングシステムには欠けています。

停滞に対処する上での困難と課題は何ですか？

Wilding：アプリケーションの停滞は、カーネルスペースの問題によって引き起こされる可能性があるものも含め、さまざまな理由によるものです。 。つまり、これらの問題は開発者によって管理されていないことがあります。しかしこれがLinuxの利点です。すべてのソースコードは開いているので、プロセス内でカーネルブロックに遭遇した場合は、ソースコードに連絡してそのプロセスがカーネル内でどのように機能するかを確認できます。しかし、ほとんどの場合、そのような綿密な調査を実施する必要はありません。プロセスの停滞の理由を探るために、アプリケーションソフトウェアの開発者は慎重にこれらのソフトウェアレベルの状態と証拠を研究する必要があります。

ユーザーやメンテナンス担当者にとっては、一般的にアプリケーションソフトウェアの特定の作業手順を理解しておらず、テストのためにソースコードレベルを入力することもできません。処理しています。たとえば、場合によっては、プロセスAはプロセスBの終了後に解放されたリソースを待機し、プロセスBはプロセスAが所有するリソースを待機します。これはいわゆる「デッドロック」です。これは複雑なアプリケーションでよく発生する問題で、停滞問題の診断ソリューションとして使用できます。

プロセスAとプロセスBの具体的な待機理由がわからない場合は、これが "デッドロック"の場合であるかどうかを理解する必要はなく、両方のプロセスをオフにするしかありません。それからそれを元に戻します。これも同様の状況であるため、アプリケーションソフトウェアにとっては、完全なリソースの追跡とロック状況を実行することが非常に重要です。これは、このより困難な問題を解決するのに役立ちます。

Behman：停滞の問題に関するもう1つの課題は、停滞の問題が発生したときに、プロセスまたはスレッドがそれが停滞しているのかどうか、またはいつ停滞するのかわからないことです。競合の問題が発生すると、プロセスがほとんどのシグナルを傍受し、シグナルハンドラをプラットフォームシステムに追加して、メモリのクリーンアップ、スタックトレースなどの異常な状況を処理することができます。しかし、停滞問題が発生したとき、この並外れたプロセスは完全に不可能というわけではありませんが、多くの場合柔軟性があり、あまり修正されていません。

停滞問題が発生した場合、多くの場合、システムまたはアプリケーションソフトウェアを再起動する必要があります。留意すべき1つのことは、停滞問題が発生すると、問題を診断するための情報と証拠の一部がアクティブなカーネルとアプリケーションソフトウェアによって捕捉されることが多いということです。あなたがこれらの重要なものを集めていないとすぐに再起動した場合、あなたは問題を診断する方法がわからないので、今後それが再び起こることを防ぐことは不可能です。

特別な環境では、システムの安定性と信頼性が問題の診断と解決のスピードに密接に関係しています。したがって、「最初にエラーを収集してから再起動する」という合理的な考えに従うことが必要です。

衝突と比較して、停滞に関して最初にすべきことは何ですか？

Behman：カーネルレベルでの停滞への対処とアプリケーションレベルでの停滞への対処非常に違います。

アプリケーションレベルについて質問している場合競合の問題が発生した場合、インメモリ、スタックトレースのフィードバックなど、さまざまなことを処理するために呼び出す "シグナル処理"と呼ばれる特別な機能があります。したがって、一般に、競合に直面したときの主な問題は、データの収集、編成、および分析です。

滞留問題が発生したときにデータが自動的に収集されることはありませんが、これは多くの場合手動のプロセスです。停滞状態データを収集するための2つの重要なポイントは、出力の追跡とスタックのフィードバックの追跡です。このように出力を追跡することで、プロセスが常に動作しているかどうかなど、プロセスを常に監視し続けるため、プロセスが何をしているのかを把握できます。スタックのトレースフィードバックは、現在のプロセスの一部をソースコードに渡すことができます。これは開発者にとって非常に重要であるため、開発者はプロセスの停滞の原因を調べることができます。

競合と停滞の主な理由は何ですか？

Wilding：競合の場合、主な理由を2つに分けることができます。予防的、他はエラー処理です。予防的衝突は、深刻な状況のためにカーネルまたはアプリケーションソフトウェアが衝突を起こしている状況です。ソフトウェアはこの問題を認識しており、それ以上のエラーが発生しないようにするための「自殺的」なアプローチをとっているため、より深刻な問題を回避できます。エラー処理の競合については、違法なコンテンツがメモリに入力され、ほとんどすべてのプログラムエラーが発生することを意味します。この場合、ハードウェアはアプリケーションを検出してから、ソフトウェアの進行をブロックするための信号を送信します。

停滞問題には、一般的に2つの理由があります。 1つは、プロセスまたはスレッドがリソースを待機する場合です。これは解決されない可能性があります。他のプロセスまたはスレッドは、プロセスまたはスレッドが待機しているときにもリソースを占有するようにリソースを制限するため、他のプロセスまたはスレッドは待機することしかできません。例としては、それが占有している重要なリソースをロックし、それ自体が目的なしにインターネットを受け取っているというプロセスがあります。 2番目に一般的な理由は、2つ以上のプロセスが互いのリソースを待機しているため、一種の「ループバイループ」待機であるため、「デッドロック」になります。この状況を解決するには、ロックを解除するか、スペース内のメモリーを共有することが考えられます。

このような対立と停滞の中で、知事が適用できる基本的な調査規則は何ですか？

Wilding：最も基本的な指針の1つは、作業を体系化することです。 。収集したデータは、後で簡単に見つけられるように、明確な場所に保管することが非常に重要です。これは、複数の問題が同時に発生した場合に特に役立ちます。

Behman：もう1つの基本的な基準は、定性的ではなく定量的にデータを収集することです。たとえば、「昨夜の6時に、システムメモリの使用率が低い」という定性的な観察結果があります。これは問題処理にはほとんど影響しません。この例の定量版は、他の関連する診断コマンドと同様に、すべての出力データコマンドを収集して保存する必要があります。目的は、問題の再発をできるだけ回避するために十分なデータを収集することです;これは「1回限り」の方法で、問題を繰り返す必要がなく、複数のコレクションがより完全なデータを取得できます。 。