Linux ページ キャッシュの基礎

Linux では、ページ キャッシュにより、不揮発性ストレージ上のファイルへの多くのアクセスが高速化されます。 これは、ハード ドライブなどのデータ メディアから最初に読み込んだり書き込んだりするときに、Linux もデータをメモリの未使用領域に保存し、キャッシュとして機能するためです。 このデータは、後で再び読み込まれる場合、メモリ内のこのキャッシュから素早く読み込むことができる。 この記事では、このページ キャッシュに関する貴重な背景情報を提供します。

ページ キャッシュまたはバッファ キャッシュ

バッファ キャッシュという用語は、ページ キャッシュに対してしばしば使用されます。 バージョン 2.2 までの Linux カーネルには、ページ キャッシュとバッファ キャッシュの両方がありました。 2.4 カーネルでは、この 2 つのキャッシュは統合されました。

機能的アプローチ

Linuxでは、ページ キャッシュに現在使用されているメイン メモリのメガバイト数は、free -m コマンドによって生成されるレポートの [キャッシュ] 列で示されます。

# free -m total used free shared buffers cachedMem: 15976 15195 781 0 167 9153-/+ buffers/cache: 5874 10102Swap: 2000 0 1999# 

書き込み

データが書き込まれると、まずページ キャッシュに書き込まれ、そのダーティ ページの 1 つとして管理されます。 ダーティとは、データがページ キャッシュに保存されているが、基盤となるストレージ デバイスに最初に書き込まれる必要があることを意味します。 これらのダーティページのコンテンツは、定期的に（システムコールのsyncやfsyncと同様に）基礎となるストレージデバイスに転送されます。

次の例では、10 MB のファイルを作成し、最初にページ キャッシュに書き込む様子を示しています。 この場合、同期コマンドに応答して手動で書き込まれます。

wfischer@pc:~$ dd if=/dev/zero of=testfile.txt bs=1M count=1010+0 records in10+0 records out10485760 bytes (10 MB) copied, 0,0121043 s, 866 MB/swfischer@pc:~$ cat /proc/meminfo | grep DirtyDirty: 10260 kBwfischer@pc:~$ syncwfischer@pc:~$ cat /proc/meminfo | grep DirtyDirty: 0 kB

バージョン 2.6.31 までの Kernel: pdflush

2.6.2 までは、および 2.6.1 までの Kernel を含めて、ダーティ ページは増加しました。31 バージョンの Linux カーネルでは、pdflush スレッドが、ダーティ ページが基礎となるストレージ デバイスに定期的に書き込まれるようにしました。

バージョン 2.6.32 以降: バッキング デバイスごとのライトバック

pdflush にはいくつかのパフォーマンスの欠点があったので、Jens Axboe は Linux カーネル バージョン 2.6.32 で新しい、より有効なライトバック機構を開発しました。

このアプローチでは、SSD (/dev/sda) とハード ディスク (/dev/sdb) を備えた次のコンピューターの例が示すように、各デバイスにスレッドを提供します。

root@pc:~# ls -l /dev/sdabrw-rw---- 1 root disk 8, 0 2011-09-01 10:36 /dev/sdaroot@pc:~# ls -l /dev/sdbbrw-rw---- 1 root disk 8, 16 2011-09-01 10:36 /dev/sdbroot@pc:~# ps -eaf | grep -i flushroot 935 2 0 10:36 ? 00:00:00 root 936 2 0 10:36 ? 00:00:00 

読み取り

ファイル ブロックは書き込み時だけではなく、ファイルの読み取り時にも Page Cache に書き込みを行うことができます。 たとえば、100 メガバイトのファイルを 2 回に分けて読む場合、ファイル ブロックはメモリ内のページ キャッシュから直接来るので、ハード ディスクから再度読み込む必要がないため、2 回目のアクセスはより速くなります。 次の例は、200 メガバイトの良質なビデオを再生した後、ページ キャッシュのサイズが増加したことを示しています。

user@adminpc:~$ free -m total used free shared buffers cachedMem: 3884 1812 2071 0 60 1328-/+ buffers/cache: 424 3459Swap: 1956 0 1956user@adminpc:~$ vlc video.aviuser@adminpc:~$ free -m total used free shared buffers cachedMem: 3884 2056 1827 0 60 1566-/+ buffers/cache: 429 3454Swap: 1956 0 1956user@adminpc:~$

通常のアプリケーションで現在利用できる以上のメモリを Linux が必要とすると、もはや使用されていないページ キャッシュの領域は自動的に削除されます。

ページ キャッシュの最適化

ページ キャッシュに自動的にファイル ブロックを保存することは通常かなり有利に働きます。 ログ ファイルや MySQL ダンプ ファイルのような一部のデータは、一度書き込まれると、もはや必要ないことがよくあります。 したがって、そのようなファイル ブロックはしばしば不必要に Page Cache のスペースを使用します。

定期的な logrotate の実行と gzip 圧縮は、ログ ファイルを多少助けることができます。 500 メガバイトのログ ファイルが logrotate と gzip によって 10 メガバイトに圧縮されると、元のログ ファイルはそのキャッシュ領域とともに無効になります。 そして、ページキャッシュの490メガバイトが、そうすることで利用可能になる。

したがって、一部のアプリケーションが通常、特定のファイルおよびファイル ブロックをキャッシュに保存しないことは、完全に合理的です。

追加情報

• Page Cache, the Affair Between Memory and Files (Blog)
• Linux buffer cache state (Blog)
• The Linux Page Cache and pdflush: Theory of Operation and Tuning for Write-Heavy Loads (Last update 8/08/2007)
• drop_caches (linuxinsight.com)
• Examining Linux 2.6 Page-Cache Performance (linuxinsight.com)
• Page cache (en.wikipedia.org)