キャッシュ使用時のディスクI / Oが高い？
数日前、ディスクI/Oの待機とディスクアクティビティの低下に気づきました（これはすばらしいことでした）。次に、キャッシュがいっぱい（*）で断片化されていることにも気付きます。次に、キャッシュをフラッシュしました。その後、ディスクの待ち時間とディスクのアクティビティが前のレベルに跳ね上がりました（これは悪いことでした）。
IOtopは、[jbd2/sda2-8]と[flush-8：00]が常にディスク使用率の上にあることを示しています。これは、多くの空きメモリを備えたDell R210、ハードウェアRAID 1（H200）です（合計16 GB、そのうち約8 GBがバッファ/キャッシュです）。
（*）キャッシュはPHP用のAPCオペコードキャッシュであり、PHPスクリプト実行のディスクアクセスを削減します。キャッシュには、開発インスタンスからのファイルが含まれていたため、フルでフラグメント化されていました。それらを出します。
問題は、理論的にはディスクI/Oが減少するはずなのに、なぜディスクI/Oが増加するのかということです。以下はmuninからのいくつかのグラフです。 2月6日から8日までキャッシュがいっぱいでした。
@ cyberx86の指示に従って、apc.mmap_file_maskをコメントアウトした後に変更します。
ファイルベースのメモリマッピングを使用する場合（例：apc.mmap_file_mask=/tmp/apc.XXXXXX）高いI/Oが表示される場合があります。
設定してみてくださいapc.mmap_file_mask共有メモリを使用します（例：/apc.shm.XXXXXX）または/dev/zero（匿名のmmappedメモリ）。設定を未定義のままにすると、デフォルトで匿名のmmapメモリが使用されます。
通常、mmapファイルはすばらしいことです。
- 何かを完全にメモリに保存する場合と比較して、マップされたファイルは通常、必要なメモリが少なくて済みます。
- ファイルに何かを保存する場合と比較して、mmappedファイルはディスクI/Oが少なくて済みます（書き込みを一緒に集約できるため）。
ただし、純粋にメモリに何かを保存する場合と比較すると、I/Oが追加されるため、ファイルが継続的に変化している場合にかなりの負担になります。 mmmapファイルを使用しないことの欠点は、永続性の欠如です-キャッシュはメモリにのみ保存されるため、再起動後も存続しません。
したがって、キャッシュがいっぱいになって安定している間、キャッシュはほとんどの変更を受けており、常にディスクに書き込む必要があったことを示唆しているかもしれません。キャッシュがいっぱいになると、各オブジェクトのttlにより、キャッシュ内のデータが反転する速度が遅くなり、変更が減少し、ディスクへの書き込みが減少しました。
数日後、いくつかのグラフを返したいと思います。この変更により、その状況は大幅に改善されます。 IOサービス時間以外のすべてが短縮されます（これは、簡単な小さなPHPファイルの読み取りが安価であるため）。
サーバーの負荷（すでにかなり低かったので、変更を発見していませんでした）。
