奇妙に聞こえるかもしれませんが、より低速の、またはキャッシュされたファイルシステムが必要なのです。
私には、Linux VM のペアにデータを syslog で送信するファイアウォールが多数あります。これらのファイルは、ext3 形式のディスク (実際には FC SAN が接続されています) に書き込まれ、Splunk サーバーにもメッセージが転送されます。
問題は、syslog サーバーがこれらの syslog メッセージを数百、時には数千の、毎秒約 4k の小さな書き込みとして FC SAN に書き戻すことです。FC SAN は現在このワークロードを処理できますが、今後数か月で FW トラフィックが少なくとも 5000% 増加し (実際)、SAN にとって負担となるため、問題になる前に根本原因を修正したいと考えています。
したがって、これらの書き込みを「物理」ディスクから何らかの方法でキャッシュまたは保留して、VM がより大規模で頻度の低い書き込みを実行する方法を見つけるのに助けが必要です。これらの書き込みを回避する方法はありませんが、非常に多くの小さな書き込みを実行する必要はありません。
さまざまな ext3 オプションを調べて、noatime と nodiratime を設定しましたが、問題はあまり改善されませんでした。もちろん、他のファイル システムも調査中ですが、将来他の人に同じ問題が発生する場合に備えて、これを投稿しようと思いました。
ああ、これらのメッセージを Splunk に転送することはできません。ファイアウォール チームは、診断の目的でメッセージを元の形式のままにしておくことを要求しています。
答え1
おそらく、commitext3 マウント オプションが役立つでしょう。たとえば、commit=60すべてのデータとメタデータを 1 分間に 1 回だけフラッシュします。
必須の警告: これにより、最大 1 分分のデータが失われる可能性があります (commit=60 値を渡す場合)。
答え2
ファイルシステム: デバイスが書き込みバリアを使用している場合はそれを無効にし、atime 更新を全面的に無効にします。
ただし、障害イベント (電源など) が発生した場合にデータがさらに失われるという代償を払って、syslog を調整することもできます。
ディレクティブの例syslog-ng(使用しているものと異なる可能性があります):
flush_lines()一度に宛先にフラッシュされる行数を指定します。Syslog-ng は、この行数が蓄積されるまで待機し、それらを 1 つのバッチで送信します。flush_timeout()syslog-ng が出力バッファに行が蓄積されるのを待機する時間を指定します。詳細については、flush_lines オプションを参照してください。
この場合の保存先はディスク ファイルです。