Linux UNIXソケットでのライブロック、どうすればよいですか？

Question

私たちは、多数の（1000以上の）子プロセスをフォークするLinuxアプリケーションを動作させます。これらの子プロセスは、UNIXデータグラムソケット（すべての子プロセスで共有される）を介してマスタープロセスと通信します。 UNIXデータグラムソケットは、ログ用の他の通信の他にも使用されます。アプリケーションが大規模な外部エラーに反応するまでシステム全体が正常に動作します - アプリケーションデータベースのクラッシュを考えましょう。このような状況では、子プロセスは大量のエラーログイベントを生成し始めます。これは、各子がそのクラッシュの影響を受けるため正しいと思われます。数分後、負荷は8000を超えて80-100％のCPUで増加します。システム（消費者ではありません）消費。状態が回復するのは、アプリが強制終了された場合、または一般的に、応答が遅いためにボックスを使用できなくなり、再起動する必要がある場合のみです。

コアダンプの調査では、子プロセスがUNIXソケット上のsend() syscallでブロックされ、プロセスをマスターすることが示されています。 UNIXソケットは非ブロッキングとして設定され、アプリケーションはEAGAINの適切な処理を実装します。より詳細な分析は、カーネルにライブロック状態が存在することを示します。明らかに、プロセスはUNIXソケットに関連するリソースへのアクセスのために競合しています。

質問：これまでにこのような動作をしたことがありますか？ UNIXソケットの並列処理について何か不足していますか？

バージョン：
- CentOS Linuxリリース7.3.1611（コア）。
- カーネルLinux 3.10.0-514.16.1.el7.x86_64 x86_64。

Answer 1

カーネル側には改善の余地がありますが、チャンスはかなり低いです。私は推測するつもりはない。問題は火炎グラフで簡単に見える可能性があります。

ただし、この文脈での並べ替えの考慮事項は赤いニシンです。議論のために、カーネルが0のオーバーヘッドですべてのこれらのエラーメッセージをプッシュすると仮定します。ギガバイトの反復エラーメッセージが生成され、値が追加されませんでした。

例えば、データベースへの接続が死亡した注意し、それがアップ戻ったときに注意しますが、それぞれにログオンしていない（主要なイベントがあるときに代わりに、ちょうどたら、それをログに記録し、それがクリアされていることをもう一度ログインそれが死んでいるという質問）。あるいは、定期的にまたはratelimitでログに記録することもできます。いずれにしても、スパム送信は間違ったことです。

子供の純粋な数（1000+？）は非常に過剰であり、このプロジェクトのデザインの有効性に疑問符を付けます。あなたは何が起こっているのかを精緻化できますか？