Sambaサーバーでの高iowaitの解決
Webサーバーのクラスターが「重い」ページを格納するために使用する一元化されたファイルキャッシュがあります。各Webサーバーは、Sambaを使用してこの共有領域をマウントします。
サーバー上で多くのiowaitを取得していますが、より効率的な集中型キャッシュを作成するためにどのような手順を実行できるのでしょうか。一部のオブジェクトの最初の行のキャッシュとしてすでにmemcacheを使用しており、単にメモリを増やす可能性がありますが、ファイルベースのキャッシュを高速化するために使用できる手法を見つけることに興味があります。すべてのサーバーはUbuntuの最新リリースを実行します。
サーバーは、LVMでext3ファイルシステムを使用します。たぶん、他のファイルシステムがこの種のアクティビティに対してよりパフォーマンスが高いでしょうか？誰もがSambaに慣れていて、NFSでメンテナンスの問題が発生した（たとえば、マウント解除の拒否）という理由だけで、Sambaを長年使用していました。たぶんもっと良い技術があります...
そのボリュームに割り当てられているioスケジューラ（カーネルドキュメントではioエレベータと呼ばれます）を確認します。
$ cat /sys/block/sda/queue/scheduler
noop anticipatory [deadline] cfq
ほとんどのRedHatおよびFedoraディストリビューションでは、デフォルトはCFQスケジューラーです。私見では、これはioboundサーバープロセスには最適ではありません。締め切りスケジューラをお勧めします
$ echo "deadline" > /sys/block/sda/queue/scheduler
これを変更するか、追加します
elevator=deadline
これを永続的にするためのブート引数に。
長いiowait時間は、積極的な先読みによっても発生する可能性があり、ワークロードには不要な場合があります。 RedHatおよびFedoraシステムのデフォルトは128kです
$ cat /sys/block/sda/queue/read_ahead_kb
128
そのファイルに低い値をエコーしてみて、それによってiowait時間が減少するかどうかを確認してください。
また、基になるディスクまたはアレイを確認してください。劣化または再構築すると、基盤となるディスクサブシステムが再構築中にio帯域幅を盗むため、iowait時間が急増します。
サーバーのIOWait％が高いということは、より高速なディスク/ディスクキャッシュ用のより多くのメモリが必要であることを意味します。
'iostat -x 5'統計を見てください-ディスクが飽和していますか？アプリケーションのセマンティクスによっては、ファイルサーバーのメモリを増やすとうまくいく可能性があります。
サーバーによるページの保存と取得の間に長い遅延がある場合は、より高速なディスクが必要です。
Freeの出力をチェックして、使用しているメモリの量とその使用目的を確認してください。
Sambaはネットワーク経由でアクセスされるため、最初にネットワークがボトルネックになると思います。ネットワークを介して送信されるファイル/パケットのタイプとサイズに合わせてリンクが最適化されていますか？
リンクを監視して、リンクがどの程度利用されているかを確認できますか？
ネットワークがボトルネックになっていないように思われる場合は、 このガイド のヒントをいくつか見て、Samba構成を少し最適化してください。
編集
LVMについておっしゃっていますが、どのタイプのディスクですか？通常の既製の7200RPM IDEドライブ？本当にIO待つなら、はい、より高速なディスクが必要です。これはSATAと同じくらい簡単かもしれません。 10kドライブ、または高性能レイドに入る。
別のオプションは、同じデータに到達するために異なるレイヤーを経由するのではなく、Squidやワニスなどのリバースプロキシキャッシュソリューションを使用することです。そのようなソリューションとして考慮すべきことは、（より一般的なファイル提供ソリューションとは対照的に）Webページを提供するために最適化されるでしょう。