web-dev-qa-db-ja.com

Linuxファイルシステムキャッシュ：データをダーティからライトバックに移動

私のソフトウェアRAIDは800 MB /秒の書き込みを持続できます。 cat /proc/meminfo |grep Writeback:は> 2 GBを返します。ただし、ほとんどの場合、書き戻しは約0.5 GBであり、約200 MB /秒のパフォーマンスが得られます。

書き込むデータはたくさんあります。 cat /proc/meminfo |grep Dirty:は、ダーティキャッシュが90 GBであることを示しています。

私が理解しているように、ダーティは書き込む必要があるものですが、ライトバックはディスクにアクティブに書き込まれているものです。そのため、ライトバックのブロックのすぐ隣にあるディスク上にあるダーティのブロックがあり、これらは同じ場所に書き込まれません。

これは、シークに費やされた時間が数MBの書き込みに費やされた時間よりもはるかに長いため、ライトバックが小さい場合にパフォーマンスが大幅に低下する理由を説明できます。

だから私の質問は：どういうわけか、より多くのデータをダーティからライトバックにさらに積極的に移動してライトバックを増やすようにカーネルに指示できますか？

-編集-

これは低パフォーマンス時です：

$ cat /proc/meminfo
MemTotal:       264656352 kB
MemFree:          897080 kB
Buffers:              72 kB
Cached:         233751012 kB
SwapCached:            0 kB
Active:          3825364 kB
Inactive:       230327200 kB
Active(anon):     358120 kB
Inactive(anon):    47536 kB
Active(file):    3467244 kB
Inactive(file): 230279664 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:      204799996 kB
SwapFree:       204799996 kB
Dirty:          109921912 kB
Writeback:        391452 kB
AnonPages:        404748 kB
Mapped:            12428 kB
Shmem:               956 kB
Slab:           21974168 kB
SReclaimable:   21206844 kB
SUnreclaim:       767324 kB
KernelStack:        5248 kB
PageTables:         7152 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    337128172 kB
Committed_AS:     555272 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      544436 kB
VmallocChunk:   34124336300 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      149988 kB
DirectMap2M:    17649664 kB
DirectMap1G:    250609664 kB


cat /proc/sys/vm/dirty_background_ratio
1

Dirty_writeback_centisecsを下げると、ダーティがさらに小さなビットで切り取られるだけです。

linuxperformancesoftware-raid
5
Ole Tange

/ proc/meminfoの出力全体を提供しなかったため、事前に行った調整があるかどうかはわかりません。

使用できる2つの即時調整可能パラメーターはこれらです。

/proc/sys/vm/dirty_background_ratio

 dirty_background_ratio

Contains, as a percentage of total system memory, the number of pages at which
the pdflush background writeback daemon will start writing out dirty data.

デフォルトは10です。30または40に増やしてテストします。

/proc/sys/vm/dirty_writeback_centisecs

dirty_writeback_centisecs

The pdflush writeback daemons will periodically wake up and write `old' data
out to disk.  This tunable expresses the interval between those wakeups, in
100'ths of a second.

Setting this to zero disables periodic writeback altogether.

デフォルトは500です。300に設定してテストします。

これらは絶対値ではないことに注意してください。自分の環境に最も適したものを見つけるには、試行錯誤を繰り返す必要があります。

私はあなたが提供した説明に基づいてこれらの値を理解し、それが正しいと仮定しました。

Kernel-docパッケージがインストールされている場合は、sysctlに移動し、vm.txtを開いて読みます。

3
Soham Chakraborty

実際の問題は、Linuxカーネルのダーティページフラッシュアルゴリズムが大きなメモリサイズにスケーリングしないため、/ proc/meminfoのダーティページが約1 GBを超えると、ライトバック速度が徐々に低下し、最終的に/ proc/sys/vm/dirty_ratioまたは/ proc/sys/vm/dirty_bytes制限を超え、カーネルがすべての書き込みのスロットルを開始して、ダーティページがそれ以上成長しないようにします。

高い書き込み速度を維持するには（OPの場合、最大800Mb /秒、キャッシュ付きのハードウェアRAIDコントローラーの場合は2Gb /秒になる可能性があります）、/ proc/sys/vm/dirty_bytesとdirty_background_bytesを直感的に下げて256Mにし、それぞれ64M

最初に必ず同期を行ってください。そうしないと、/ proc/meminfoのダーティページの値が/ proc/sys/vm/dirty_bytesの新しい値を下回るまで、システムは書き込み時に数時間フリーズします。同期にも数時間かかりますが、少なくともこの間、システムはフリーズしません。

1
Thomas Anantharaman

Writebackは、IOキューのサイズを表します。

IOキューの最大サイズは、nr_requests（およびmax_sectors_kbの可能性があります）を増やすことで増やすことができます。Dirtyメモリの量を考えると、この制限に達しているのではないかと思います。

https://www.google.com/search?q=linux+block+queue+nr_requests+OR+max_sectors_kb

最近のカーネルでは、wbt_lat_usecの影響にも注意する必要があります。これに0を書き込むことで無効にでき、-1を書き込むことでデフォルト値にリセットできます。

I/Oスケジューラーの質問もあります。サーバーのアドバイスの多くは、CFQではなくdeadlineスケジューラを使用するように言っています。 CFQ（およびある程度、BFQ）は、一度に1つのプロセスから連続した順次I/Oを要求するために、意図的にディスクを「アイドル」にします。

どのようにmd RAIDデバイスを調整すべきかわかりません。個々のディスクデバイス。

（キューに入れられたIOリクエストの数を測定することもできます。atopsar -d 1、またはsar -d 1、またはiostat -dx 1。ただし、「平均キューサイズ」統計は 利用率（ "io_ticks"）から派生） で、これは カーネルバージョン5.0以降、誤って報告されます です。現在のキューのサイズは依然として正確です。しかし、既存のツールでは、平均キューサイズ。これがより有用な値だったためです）。

0
sourcejedi