☰

非常に大きなファイルのLVMキャッシュの調整

tag-icon • tag-icon lvm cache
非常に大きなファイルのLVMキャッシュの調整

私のシステムには、部分的にmdミラーリングされた2つの物理4TBハードドライブと、ルートファイルシステムを格納し、重要な大規模ファイルシステムをディスクにキャッシュする、非常に高速な512GB SSD M.2デバイスがあります。特定のファイルシステムは、VMWare Workstation仮想マシンのディスクファイルを保存します。これらのファイルは非常に大きい場合があります（10-70 GB）。私が実行する最も一般的なVMはWindows 10イメージで、これには78 GBの基本イメージと別の6 GBのスナップショットファイルが含まれています。

私はこのファイルシステム、特にこれらのファイルがより良いパフォーマンスを発揮できるように、LVMキャッシュ調整可能なアイテムを探しています。

これと同じM.2 SSDには実際のWin 10イメージもあり、Grub選択からWindowsログイン画面に直接イメージを起動するのに約8秒かかります。これに比べてVMWareブート選択からログインまで約28秒かかりました。キャッシュをオフにするよりもはるかに優れていません（ただし、最近テストを行ったことがないため、引用する数字はありません）。

Win 10 VMのフルディレクトリは82GBです。以下は私のlvmの詳細です（最後のvmCacheに焦点を当てます）。

lvs -a -o+devices
LV                     VG     Attr       LSize   Pool         Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices                            
games                  cache  Cwi-aoC--- 200.00g [gamesDataCache]        11.37  16.05           0.00             games_corig(0)
[gamesDataCache]       cache  Cwi---C---  10.00g                         11.37  16.05           0.00             gamesDataCache_cdata(0)
[gamesDataCache_cdata] cache  Cwi-ao----  10.00g                                                                 /dev/nvme0n1p6(23015)  
[gamesDataCache_cmeta] cache  ewi-ao----  12.00m                                                                 /dev/nvme0n1p6(23012)  
[games_corig]          cache  owi-aoC--- 200.00g                                                                 /dev/md126(0)          
home                   cache  Cwi-aoC--- 300.00g [homeDataCache]         100.00 16.05           0.01             home_corig(0)          
[homeDataCache]        cache  Cwi---C---  10.00g                         100.00 16.05           0.01             homeDataCache_cdata(0) 
[homeDataCache_cdata]  cache  Cwi-ao----  10.00g                                                                 /dev/nvme0n1p6(3)      
[homeDataCache_cmeta]  cache  ewi-ao----  12.00m                                                                 /dev/nvme0n1p6(0)      
[home_corig]           cache  owi-aoC--- 300.00g                                                                 /dev/md127(128000)     
[lvol0_pmspare]        cache  ewi-------  79.90g                                                                 /dev/md127(204800)     
vm                     cache  Cwi-aoC--- 500.00g [vmCache]               100.00 19.01           0.00             vm_corig(0)            
[vmCache]              cache  Cwi---C---  79.80g                         100.00 19.01           0.00             vmCache_cdata(0)       
[vmCache_cdata]        cache  Cwi-ao----  79.80g                                                                 /dev/nvme0n1p6(2563)
[vmCache_cmeta]        cache  ewi-ao----  80.00m                                                                 /dev/nvme0n1p6(22992)
[vm_corig]             cache  owi-aoC--- 500.00g                                                                 /dev/md127(0)      
root0                  fedora -wi-ao----  39.00g                                                                 /dev/nvme0n1p5(1)

キャッシュサイズはほぼ80GBで、このWin 10は私が起動する唯一のVMなので、ほぼ全体のイメージをキャッシュすることが期待されています。データ使用量は100％ですが、パフォーマンスは予想よりもはるかに低いです。

要求に応じてより詳細なLVM構成を提供できますが、現時点ではほとんどの値がデフォルト値であると仮定します。

どんな提案がありますか？

ありがとう、

ブライアン

答え1

使用しているシステムは何ですか（OS +バージョン+仮想化スイート/パッケージ）？

CentOS 6.8のLVMキャッシュで大規模なキャッシュの問題を発見しました。 100GB SSDを2TB HDD（ソフトウェアRAID SSDおよびHDD）と組み合わせると、スピードアップはまったくありません！ SATAコントローラ

iostat -m -x 2

SSD SATAポートは100％使用されていますが、おおよその書き込み操作のみが表示されます。 120MB/秒（HDDと同じ速度）キャッシュサイズを10GBに減らすと状況がずっと良くなると思いました！しかし、どちらも同じブロックサイズを持ちます。

lvconvert --type cache-pool --chunksize 960 --cachemode writeback --poolmetadata ${VGBASE}/cachemeta ${VGBASE}/cachedata

dmesgまた報告された（100Gキャッシュがある場合）

device-mapper：キャッシュ：複数の別々のキャッシュブロックを持つキャッシュデバイスを作成しました（1670400）。

ブロックのサイズを変更すると役に立ちますが、この値の設定に問題があるようです。

ブロックサイズは64（32KB）から2097152（1GB）の間で、64（32KB）の倍数でなければなりません。 https://www.kernel.org/doc/Documentation/device-mapper/cache.txt

これらの規則によれば、実際にブロックサイズを変更することができますが、多くのブロックサイズの場合、ディスクに再フラッシュすることは機能しません。キャッシュボリュームのキャッシュを解放し、次のような無限ループに陥らないことを確認することをお勧めします。

Xブロックはまだフラッシュする必要があります（これは常に起こります！）

SSDは高速書き込みを行い、後でHDDが実際に書き込みを実行するかどうかを調べるために使用されますiostat（公開時のCpy％Sync列を参照lvs -a）。

そのため、その項目を削除（更新）できることを確認し、正常に動作していることを確認してくださいiostat。

もちろん、キャッシュがいっぱいになると、新しいコンテンツを書き込むためにフラッシュする必要があるため、速度はHDD速度ほど低下します。

しかし、これまで私が下した結論は、チューニングが難しいということです。おそらく、CentOS 7で修正されたいくつかのバグが原因で、CentOS 6.8ではチューニングが困難になる可能性があります。

PS Windows VMをすばやく起動するには、SSDに存在する必要があります。したがって、この例では、キャッシュに収まらない何十ものOSイメージを同時に実行しているため、機能しない可能性があります。ハードウェアノードがリブートされると、ブートに必要な部分が長時間接触していないため、OSイメージ全体がキャッシュに（一部のみ）存在しなくなります。再起動したら、HDDを介して画像を再初期化する必要があります。しかし、それはあなたの問題ではないかもしれないと思います。

関連情報