web-dev-qa-db-ja.com

同期的にマウントすると、mdadmの書き込みが非常に遅くなるのはなぜですか？

書き込みのベンチマークを行いたい6ディスクraid6mdadmアレイがあります。

root@ubuntu:~# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid6 sda[0] sdf[5] sde[4] sdd[3] sdc[2] sdb[1]
      1953545984 blocks level 6, 64k chunk, algorithm 2 [6/6] [UUUUUU]

キャッシュが原因でベンチマークが不正確になる可能性があります。たとえば、ここでの書き込み速度が本来よりも速いことに注意してください。

root@ubuntu:/mnt/raid6# dd if=/dev/zero of=delme bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.276026 s, 380 MB/s

これで、各ディスクキャッシュを非常に簡単に無効にできます。

root@ubuntu:~# hdparm -W0 /dev/sd*

/dev/sda:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)

/dev/sdb:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)

/dev/sdc:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)

/dev/sdd:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)

/dev/sde:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)

/dev/sdf:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)

しかし、Linuxのキャッシュはまだあります。

root@ubuntu:/mnt/raid6# dd if=/dev/zero of=delme bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00566339 s, 1.9 GB/s

Linuxキャッシュを無効にするために、ファイルシステムを同期的にマウントできます。

mount -o remount,sync /mnt/raid6

しかし、この書き込みの後、way本来よりも遅くなります：

root@ubuntu:/mnt/raid6# dd if=/dev/zero of=delme bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 23.3311 s, 449 kB/s

これは、mdadmが機能するために非同期マウントを必要とするかのようです。何が起きてる？

ubuntudebianraidmdadmdisk-cache
6
chrishiestand

質問者による引用：

しかし、Linuxのキャッシュはまだあります。

root@ubuntu:/mnt/raid6# dd if=/dev/zero of=delme bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00566339 s, 1.9 GB/s

Linuxキャッシュを無効にするために、ファイルシステムを同期的にマウントできます。

mount -o remount,sync /mnt/raid6

それは完全には正しくありません...同期は、ベンチマークで必要なようにキャッシュを無効にするだけではありません。これにより、すべての書き込み結果が「同期」コマンドになります。これは、キャッシュをディスクまでフラッシュすることを意味します。

よりよく説明するために、ここにサーバーがあります：

$ dd if=/dev/zero of=testfile bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 0.183744 s, 2.9 GB/s

$ dd if=/dev/zero of=testfile bs=1M count=500 conv=fdatasync
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 5.22062 s, 100 MB/s

conv = fdatasyncは、単に書き込み後のフラッシュを意味し、そのフラッシュを含む時間を通知します。または、次のことを行うことができます。

$ time ( dd if=/dev/zero of=testfile bs=1M count=500 ; sync )
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 0.202687 s, 2.6 GB/s

real    0m2.950s
user    0m0.007s
sys     0m0.339s

次に、上記の0.2秒ではなく2.95秒のリアルタイムからMB /秒を計算します。しかし、ddによって出力された統計には同期が含まれていないため、これは醜く、より多くの作業が必要です。

「同期」を使用した場合、すべての書き込みをフラッシュします...多分それはすべてのブロックを意味し、非常に遅く実行されます。 「同期」は、非常に厳密なシステムでのみ使用する必要があります。ディスク障害による単一のトランザクションの損失が許容できないデータベース（たとえば、銀行口座からあなたの銀行口座に10億ドルを送金し、システムがクラッシュし、突然あなたがお金を持っている場合）。

これは、私がずっと前に読んだ、追加のオプションを含む別の説明です。 http://romanrm.ru/en/dd-benchmark

そしてもう1つ注意してください：あなたがこのように行っているあなたのベンチマークは私の意見では完全に有効ですが、他の多くの意見では有効ではありません。しかし、それは実際のテストではありません。これは、シングルスレッドの順次書き込みです。実際のユースケースがそのような場合、たとえば。ネットワークを介していくつかの大きなファイルを送信する場合、それは良いベンチマークになる可能性があります。ユースケースが異なる場合、たとえば。 500人が同時に小さなファイルをアップロードしているftpサーバーの場合、それはあまり良くありません。

また、最良の結果を得るには、RAMでランダムに生成されたファイルを使用する必要があります。ゼロをフィードするとスマートすぎるファイルシステムもあります。たとえば、マウントされているramファイルシステムtmpfsを使用するLinuxの場合/ dev /上（および一部のシステムでは/ dev/randomまたは/ dev/urandomが遅いので、他を使用します...どちらかを忘れますが、どちらの場合もRAM =直接使用しないでください）

dd if=/dev/random of=/dev/shm/randfile bs=1M count=500
dd if=/dev/shm/randfile bs=1M count=500 conv=fdatasync
1
Peter

同期書き込みではパリティ計算が強制的にディスクに負荷がかかるため、パフォーマンスは劇的に低下します。

一般に、パリティの計算と書き込みは、特にRAID 6の場合、比較的遅いプロセスです。この場合、mdはデータを4つのチャンクにフラグメント化する必要があるだけでなく、ストライプごとに2つのパリティチャンクを計算します。パフォーマンスを向上させるために、RAID実装（mdを含む）は最近使用されたストライプをメモリにキャッシュして、書き込まれるデータを既存のデータと比較し、書き込み時にパリティをすばやく再計算します。新しいデータがキャッシュされたストライプに書き込まれると、ディスクに触れることなくパリティを比較、フラグメント化、および再計算し、後でフラッシュすることができます。 mdが常にキャッシュを見逃す状況を作成しました。この場合、ディスクからストライプを読み取り、データを比較し、新しいデータをフラグメント化し、パリティを再計算してから、新しいストライプをディスクに直接フラッシュする必要があります。キャッシュヒット時にディスクとの間で読み取りと書き込みをゼロにする必要があるのは、6回の読み取りと6回の書き込みになります書き込まれるストライプごとに

確かに、観察したパフォーマンスの違いは非常に大きいです（1.9GB /秒と449KB /秒）が、データの整合性を維持するためにmdが実行している作業量がすべて原因だと思います。

このパフォーマンスへの影響は、ディスクの配置方法によって悪化する可能性があります...すべてを1つのコントローラーに配置している場合、余分な読み取りと書き込みが多くなると、パフォーマンスが停止します。

1
tmehlinger

6つのディスクがどのように構成されているか教えてください。ターゲットが何であれ、SAN/DASの一部であるかのように聞こえます。おそらく、同じ物理ディスクで構成されています（したがって、6つすべてが同じディスク上にある場合、単一のディスクと比較してパフォーマンスが6低下します）。

anwerleaks.comへのこのリンクをご覧ください。

では、ビットマップをどのように設定しましたか？

0
Nils