3

読み取り時のレイテンシ スパイクが非常に悪いという意味で、非常にレイテンシの影響を受けやすいアプリケーションがあります。

私は XFS と ext4 をテストしました。ファイルに O_ASYNC を書き込み、最後に fdatasync() を書き込むと、読み取りレイテンシーが 1 秒以上急上昇する可能性があります。

次に O_SYNC を試してみたところ、読み取りレイテンシーがはるかに安定しましたが、ファイルへの書き込みは非常に遅くなりました。

そこで、O_ASYNC を書き込んで、ファイルに書き込まれる 5 メガバイトごとに同期しようとしましたが、その速度と読み取りレイテンシーもかなり安定しています。

ただし、30 分でも 1 秒以上かかる読み取りを取得できます。

Linux で遅延の影響を受けやすいアプリケーションを構築した場合、ファイルシステムの操作にどのように対処しましたか? または、まったく使用せずにデバイスを RAW デバイスとしてマウントしましたか?

4

1 に答える 1

0

ファイルシステムは常に少量のレイテンシを追加するため、レイテンシに非常に敏感なアプリケーションの場合は、raw デバイスを使用してファイル システムをバイパスするか、OS キャッシュをバイパスして O_DIRECT でファイルを開くことを検討します。

SSD ストレージのレイテンシーに関するその他のトリックは次のとおりです。

  • 複数のスレッドから読み取り/書き込みを行うことにより、最新の SSD に固有の並列処理を使用します。遅延は減少しませんが、実際の問題が IOPS である場合、これは役立ちます。
  • SSD 上のファイルシステムの配置を確認します。これを正しく行わないと、パフォーマンスが半分になり、レイテンシが 2 倍になります。
  • ディスク スケジューリング アルゴリズムを確認します。Linux の「noop」スケジューラーは通常、SSD ベースのストレージに最適です。
  • より優れた SSD ハードウェア (通常ははるかに低いレイテンシーを提供する PCIe ベースの SSD など) を使用します。

つまり、1 秒からの読み取り時間は正しく聞こえません。負荷/使用率が高すぎてハードウェアが対応できず、より多くの/より優れたハードウェアが最適なソリューションであるか、何か他のことがひどく間違っています。

于 2011-10-16T11:11:21.963 に答える