PIDの再考1.パート3

ファイルシステムジョブの並列化

現在のディストリビューションのロードスケジュールを見ると、単なるデーモンの起動よりも多くの同期ポイントが表示されます。FSに関連付けられているタスクは、マウント、FSのエラーのチェック（fsck）、引用に最も時間がかかります。 現在、ブート中に、 / etc / fstabで指定されたすべてのディスクがデバイスツリーに表示されるまで待機してから、エラーのチェック、マウント、およびクォータの適用が行われます（もちろんオンになっていない限り）。 このすべての後、さらに先へ進むことができ、実際にサービスのダウンロードが開始されます。



このプロセスを改善できますか？ できることがわかりました。 Harold Hoyerは、由緒あるautofsを使用してプロセスを改善するというアイデアを思いつきました。



connect（）の呼び出しが別のサービスに関心があることを「宣言」するのと同様に、 open（） （または別の同様の呼び出し）の呼び出しも、ファイルまたはファイルシステムに関心があることを宣言します。 そのため、並列化を改善するには、探しているファイルシステムがまだマウントされていない場合にのみ、これらのアプリケーションを待機させる必要があります。 これを行うには、マウントポイントautofs （偽のマウントポイント）を接続し、通常のOSブート中に実際のFSがfsckユーティリティによる整合性チェックに合格すると、実際の監視ポイントに置き換えます。 実際のFSがまだマウントされていない間、FSへのアクセス試行はカーネルによってキューに入れられ、アクセス試行はブロックされますが、アドレス指定された唯一のデーモンに対してのみです。 したがって、すべてのFSが使用可能になるずっと前にデーモンを実行でき、同時にファイルアクセスを失うことなく、OSのロードプロセスを最大限に並列化できます。



FSタスクの並列化は、すべてのサービス（デーモン）とすべてのバイナリが配置されているマウントポイント-/（FSルート）には意味がありません。 それにもかかわらず、通常はより大きく、暗号化することもでき、リモートマシンからマウントされることもあり、OSブート中にデーモンがアクセスすることはほとんどないマウントポイント/ homeにより、OSのブート速度を大幅に上げることができます。 procfsやsysfsなどの仮想FSがautofsを介してマウントされるべきではないことを思い出す必要はおそらくないでしょう。



一部の読者が、 autofsをinitプロセスに統合するという決定を少し「脆弱」または奇妙にさえ感じ、それがより「ハッカー」的な側面と呼ばれる場合でも、私にとって驚くことではありません。 それにもかかわらず、彼と多くのことをしたので、私は現在の場所のautofsがとても気分が良いと言うことができます。 autofsを使用すると、実際のFSをすぐに提供せずに監視ポイントを作成できます。 実際、アクセスは延期されています。 アプリケーションがautofs FSにアクセスしようとして、実際のFSに置き換えるのに時間がかかる場合、アプリケーションは中断されたスリープでフリーズします。つまり、 Ctrl + Cなどを使用して簡単にキャンセルできます。 また、アプリケーションの実行中の任意の時点で、実際のFSが（ fsckの失敗により）正しくマウントできない場合、 autofsに実際のエラーコード（ ENOENTなど ）を返すように要求できることに注意してください。 だから...私は、初期化システムへのautofsの統合が最初は愚かに見えるかもしれませんが、私たちの実験的なコードは、当然のことながら、実際にアイデアが驚くほどうまく動作しないことを示したと思います正しい理由のため。



また、autofsモニターポイントは、いわゆるダイレクトマッピング （翻訳者の注意： ここでの表示タイプに関する情報）である必要があることに注意してください。

最初のユーザーPIDを小さく保つ

MacOSのブートロジックから学べるもう1つの良い点は、シェルスクリプト（翻訳者のメモ：シェル、シェル）は悪であるということです。 シェルは「高速」であり、シェルは低速です。 シェルスクリプトでは、何が何であるかをすばやく把握できますが、実行速度には多くのことが望まれます。 従来のsysvinitブートシステムは、シェルスクリプトを中心にモデル化されています。 / bin / bashまたは他のシェル（シェルスクリプトの実行を高速化するために書かれた可能性が高い）であっても、最終的には遅くなる運命にあります。 私のマシンでは、/ etc / init.dのスクリプトがgrepを 77回呼び出します。 awkは92回、 cut -23およびsed -74で呼び出されます。これらのコマンド（またはその他）が呼び出されるたびに、新しいプロセスが生成され、関連するライブラリが検索され、 i18nなどが構成されます。 些細な文字列操作よりも少し複雑な操作がまれにしか実行されない場合でも、読み込みプロセスは中断されます。 もちろん、これはすべて非常にゆっくり実行されます。 しかし、シェル以外の言語ではそのようなことはできません。 さらに、上で述べたように、シェルスクリプトは非常に「壊れやすい」ものです。環境変数や、追跡や制御が困難なその他の類似のものから動作を変更します。



ブートプロセス中のシェルスクリプトの負荷を取り除きましょう。 これを行う前に、最初にそれらが実際に何に使用されているかを把握する必要があります。 ほとんどのスクリプトは、サービスの起動と停止にさほど時間をかけず、Cで書き直すか、個別の実行可能ファイルとして書き直すか、サービス自体（デーモン）内で転送するか、ブートシステム自体に実装する必要があります。



近い将来、シェルスクリプトの負担を完全に取り除くことができるようには見えません。 それらをCに書き換えるには時間がかかります。場合によっては、このアクティビティにまったく意味がなく、シェルスクリプトが非常に便利な場合があります。 しかし、一般的には、以前よりも必要性と遍在性を低くすることができます。



OSブートプロセスでのシェルスクリプトの侵襲性を測定するための適切なメトリックは、OSが完全にブートした後に開始できる最初のプロセスのPID番号です。 起動してログインし、ターミナルを開いてecho $$と入力します。 Linuxマシンでこれを試して、結果をMacOSと比較してください！ （ヒント、結果は次のようになります：Linux PID-1823; MacOS PID-154。テストマシンで測定しました。）

プロセス追跡

サービスを起動および管理するシステムの主要コンポーネントは「看護師」プロセスである必要があります。彼はサービスを監視する必要があります。 停止したらサービスを再起動します。 サービスが「落ちた」場合、管理者が将来それらを見ることができるように、クラッシュに関するすべての必要な情報を収集し、それらを近くのどこかに保管するとともに、そのようなクラッシュダンプ収集システムに存在する情報とのクロスリンクを構築する必要がありますabrtと同様に、 syslogなどのログサービスや監査システムでも同様です 。



オブザーバプロセス（「看護師」）は、サービスを完全に停止することもできなければなりません（約：翻訳者：サービスプロセスとそのすべての子プロセスを意味します）。 これは些細な作業のように思えるかもしれませんが、実際には見かけよりもさらに複雑です。 伝統的に、Unixでは、自身を2回分岐するプロセスは、親プロセスによる自身の観察を取り除くことができ、最初の親は、子孫が実際に作成した新しいプロセスとの接続を認識しません。 たとえば、現在の状況では、Apacheサービスが停止しても、自分自身を2回分岐させた「いたずらな」（不正な）CGIスクリプトは停止しません。 さらに、名前と目的がわかるまで、CGIスクリプト「naughty」とApacheの間に接続を確立する機会さえありません。



では、プロセスを追跡して「看護師」を取り除くことができず、数百万回分岐した場合に1つのエンティティとして制御できるようにするにはどうすればよいでしょうか。



さまざまな人々がこの問題に対するさまざまなソリューションを提供しています。 この記事のフレームワーク内で詳しく説明するつもりはありませんが、少なくともソリューションはptraceまたはnetlinkコネクター（システム内のプロセスがfork（）またはexitを呼び出すたびにnetlinkメッセージを受信できるカーネルインターフェイス）に基づいていると言えます一部の人々はこれを専用に実装しましたが、多くの人がbyくてスケーラブルでないソリューションとして批判されています。



では、これで何ができるでしょうか？ さて、最近、 Control Groups （別名「cgroups」）がカーネルに登場しました。 一般に、これらを使用してプロセスグループの階層を作成できます。 階層は仮想ファイルシステムに直接投影されるため、簡単にアクセスできます。 グループ名は、仮想FS内のディレクトリの名前です。 プロセスがいずれかのグループに属している場合、 fork（）呼び出しで作成されたすべての子孫（子プロセス）も同じグループに属します。 プロセスに特権（ルートなど）はないが、cgroup FSへのアクセス権がある場合、そのグループから離脱できません。 当初、コンテナ目的でcgroupがカーネルに追加されました。特定のカーネルサブシステムは、CPUまたはメモリ使用量の制限など、リソースまたは特定のグループに制限を加える場合があります。 従来、制限の制限（ setrlimit（）で実装されている）は、各プロセスに対して（主に）設定されていました。 一方、 cgroupsを使用すると、プロセスのグループ全体に制限を設定できます。 cgroupsは 、コンテナの直接的な責任の範囲外で制限を設定するためにも使用されます。 たとえば、 cgroupsを使用して、Apacheとそのすべての子プロセスが使用するメモリまたはCPUの最大量を設定できます。 そうなると、CGIスクリプトの動作がおかしくなり、そのグループをsetrlimit（）で公開したままにできなくなり、単にfork（）を再度呼び出すだけで済みます。



コンテナとリソースの制限の設定に加えて、cgroupはプロセス（サービス）を追跡するツールとしても非常に便利です。cgroupのメンバーシップは、エスケープできないすべての子プロセスに安全に継承されます。 通知システムも存在し、実行中のcgroupが空の場合、親プロセスに通知されます。 ファイル/ proc / $ PID / cgroupを読み取ると、プロセスのcgroupを確認できます。 したがって、 cgroupsはプロセスの背後にある「看護師」の役割に非常に適しています。 直接追跡。

プロセスランタイムの制御

優れた看護師は、サービスがいつ、どのように開始または停止するか、または突然落ちたときを監視および制御するだけでなく、サービスを実行するための最小限の優れた安全な環境も提供する必要があります。



心を保護するということは、リソース制限-setrlimit 、ユーザー/グループ識別子、または環境変数のブロックなどの明白なプロセスパラメーターを設定することを意味しますが、それだけではありません。 Linuxカーネルは、ユーザーと管理者にプロセスの適切なレベルの制御を提供します。 プロセスごとに、CPUとIOのスケジューラーパラメーター、CPUへのアトラクション、そしてもちろんcgroup環境に追加の制限などを設定できます。



例として、 IOPRIO_CLASS_IDLEを指定してioprio_set（）を呼び出すと、システムの対話性に対するupdatedb Locateユーティリティの影響を最小限に抑えることができます。



さらに、読み取り専用の監視ポイントに基づいて追加の読み取り専用ファイルレイヤーをマウントする（バインドマウント）など、特定の高レベルの監視ツールが役立ちます。 したがって、特定のデーモン（サービス）を起動して、FSのすべて（または一部）が読み取り専用モードで表示されるようにすることができます。したがって、書き込み試行ごとにEROFSエラーが返されます。 このようにして、貧弱なSELinuxと同じ方法で、デーモンをできることで隔離できます（ただし、この方法はSELinuxに代わるものではありません。SELiなどの悪いアイデアは使用しないでください...）。



そして最後に。 ロギングは、サービス実行の重要な部分です。理想的には、サービスによって生成されたすべての出力をログに記録する必要があります。 したがって、ブートシステムは、ダウンロードの最初から開始するデーモンにロギングサービスを提供し、標準出力とエラー出力をsyslogに添付するか、場合によっては/ dev / kmsgに添付する必要があります。これは多くの場合、 syslog （組み込みシステムに関係する人は、リッスン！）、特にカーネルログバッファが非常に大きく設定されている場合。



継続するには...