データがキャッシュされている場合でも、Sambaサーバーがデータを処理するのが遅いのはなぜですか？
基本のSambaがインストールされたCentOS5.6サーバーがあります。アレカ1880に接続された8ドライブのRAID5があり、hdparmテストで約450MBpsが返され、/ dev/nullへのddでそれに近いことを確認できます。ネットワークにファイルを提供するのは10gbeMyricomカードであり、クライアントはすべて1gbe Broadcom/intel/etcで同じスイッチ上にあります。
私が抱えている問題は、全体を通してかなり一貫しているようです。ファイルがサーバーのメモリにキャッシュされていない場合、シングルストリームファイルのコピーパフォーマンスが低下します。 1GBのファイルをコピーする場合は9-12MBのファイルについて話しますが、パフォーマンスは屋根を越えており、通常は1gbeクライアントで90％以上です。 9〜12 MBのファイル（たとえば100個）をコピーすると、約40〜50％の使用率が得られます。サーバーにキャッシュされると、1gbeクライアントNICで55〜65％の使用率になる可能性がありますが、それ以上になることはありません。なぜ？！？
キャッシュされた複数のシーケンシャルファイルシーケンスをコピーして、クライアントNICで85％以上の使用率を得ることができますが、単一のファイルシーケンスが95％以上に達しないのはなぜですか？すべてのクライアントは、tx/rxパケットをアダプターにオフロードするように設定されています。残念ながら、クライアントはジャンボフレームを使用していませんが、ジャンボをオンにしてテストしたところ、同じパフォーマンスが見られました。
大規模なシーケンシャルアクセスが最良のシナリオであり、あなたが言うように、システムはそのシナリオでパイプを飽和させます。
1つの大きなファイルに対して多くの小さなファイルを使用すると、メタデータが生成され、オーバーヘッドがロックされる可能性があります。複数のストリームを使用すると、複数の送信データを取得できると思います。マルチコアシステムでは、並行して実行できるため、帯域幅が増加します。この動作は、多くの小さなファイルのシングルスレッドパフォーマンスに拘束されていることを示しているようです。 SSDでテストできる場合、パフォーマンスの問題がディスクI/O（ロック、アクセス時間の変更、メタデータ）によるものなのか、CPUバウンドなのか（sambaプロセスがtopのコア全体を消費しているのを確認できる場合もあります）データの転送中に表示されます。これは良い指標になります）。
SystemTapを試して、「大きなファイル」と「多くの小さなファイル」のシナリオでカーネルが時間を費やしている場所を正確に確認することもできます。