同期の書き込みが非常に遅い。Ubuntu 10.10、32ビット、ext4


8

Ubuntu 10.10、32ビット、ext4パーティションを実行するMacbook ProでActiveMQを実行しています。

Linux iker-laptop 2.6.35-23-generic-pae #40-Ubuntu SMP Wed Nov 17 22:32:51 UTC 2010 i686 GNU/Linux

ActiveMQで永続化を有効にすると、パフォーマンスが大幅に低下します。私は同じことを他のマシンでテストしましたが、違いは2桁です。

HDをテストするためのactiveMQを備えたツールがあります。結果は次のとおりです。

iker@iker-laptop:~/apps/apache-activemq-5.4.1$ java -classpath lib/kahadb-5.4.1.jar org.apache.kahadb.util.DiskBenchmark 

Benchmarking: /home/iker/apps/apache-activemq-5.4.1/disk-benchmark.dat
Writes: 
  146171 writes of size 4096 written in 11.074 seconds.
  13199.477 writes/second.
  51.560455 megs/second.

Sync Writes: 
  197 writes of size 4096 written in 10.006 seconds.
  19.688187 writes/second.
  0.07690698 megs/second.

Reads: 
  5589861 reads of size 4096 read in 10.001 seconds.
  558930.2 writes/second.
  2183.321 megs/second.

同期書き込みのパフォーマンスはs ** tです。何か設定が間違っている必要がありますが、これは私がHDパフォーマンスの問題に気付いた唯一のアプリです。

hdparmは期待値をスローします。

iker@iker-laptop:~$ sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   6282 MB in  2.00 seconds = 3141.73 MB/sec
 Timing buffered disk reads:  240 MB in  3.00 seconds =  79.88 MB/sec

回答:


7

同期IOの主な制限要因は、ハードドライブのスループットではなく、書き込みが発行されてからディスクにコミットされるまでにかかる時間です。この点でハードドライブの最も適切なパフォーマンス測定基準は、ハードドライブのシーク時間であり、理想的な状況でのスループットではありません。

ハードウェアに加えて、カーネルも同様に機能しますが、ベンチマーク(アプリケーション)を実行して、リアルタイムIOスケジューリングクラスの下で実行します。デフォルトでは、アプリケーションはベストエフォートクラスの下でスケジュールされ、書き込みの待機時間も増える可能性があります。リアルタイムスケジューリングクラスは、ディスクにアクセスするときに他のアプリケーションのパフォーマンスに悪影響を与えるため、自己の責任において使用してください。

一般的に、同期書き込みのパフォーマンスにひどい問題があるとは思いません。同期IOは一般に、非同期IOと比較してひどく実行されます。

余談ですが、activemqと同期ioの簡単なgoogleは、次のことを示しています

パフォーマンス上の理由から、永続的なメッセージを使用している場合でも、可能な限り高速でメッセージをブローカーにストリーミングしたい場合があります。


運なしで次のことを試しました:ionice -c 1 -n 0 java -classpath lib / kahadb-5.4.1.jar org.apache.kahadb.util.DiskBenchmark
Iker Jimenez

3

cfq I / Oスケジューラは、このような種類のテストでひどく実行される傾向があります。前述のioniceの提案に加えて、デッドラインI / Oスケジューラーへの切り替えを試すこともできます(ブートするelevator=deadlineか、またはfor n in /sys/block/sd*/queue/scheduler ; do echo deadline > $n ; donerootとして実行することにより)。


変化は認められず、同じパフォーマンス:同期書き込み:サイズ4096の205書き込みが10.056秒で書き込まれました。20.38584書き込み/秒。0.079632185メガ/秒。
Iker Jimenez、

3

同期書き込みは、書き込みが自分自身に戻る前に、書き込みがコミットされたこと(コミットが成功したかエラーであったか)を確認する必要があります。これは設計によるものであり、金属ディスクの回転に伴う高いレイテンシ時間が原因で(ディスクRAMキャッシュはカウントされません)、本質的に同期書き込みが大幅に遅くなります。

非同期書き込みは通常RAMに書き込まれ、OSは後でそれをディスクにコミットすることを扱います(後で通常はわずか数秒以下です(ZFSは5x /秒、つまり5秒ごとと考えています))。ディスクシーク時間はmsで測定され、RAMシーク時間はnsで測定されます。それは1000倍の違いです。

続行する前にデータを永続的に保存することが絶対的に重要であり、電力損失が発生する可能性がある1秒の遅延が許容できない場合は、同期書き込みを使用します。

それ以外の場合は非同期書き込みを使用します。


2

このパフォーマンスの低下が見られる最も可能性の高い理由は、ジャーナル化されたファイルシステムで "-o sync"を使用し、バリアをオンにしているためです(ext4のデフォルトです)。

これは、それを改善するために何をすべきかについての決定が非常に困難になるところです。

結局のところ、ハードウェアをどれだけ信頼するかにかかっています。

mount(8)から:「書き込みバリアは、ディスク上のジャーナルコミットを適切に順序付けし、揮発性ディスクの書き込みキャッシュを安全に使用できるようにします。パフォーマンスが低下します。ext3ファイルシステムでは、デフォルトで書き込みバリアが有効になっていません。必ずバリアを有効にしてください。ディスクは何らかの方法でバッテリでバックアップされています。そうしないと、停電時にファイルシステムが破損する危険があります。」

したがって、「-o sync」のパフォーマンスが悪いという事実を受け入れるか、コントローラ用のバッテリバックアップ式キャッシュと非常に優れたSASディスクを購入してから、「-o sync、nobarrier」を使用してバリアをオフにしてください。

現在使用しているものが適切なエンタープライズクラスのFCまたはiSCSIストレージバックエンドである場合は、後者も安全だと思います。

全体として、ActiveMQ 5.4はデフォルトでKahaDBストレージバックエンドを使用します。これには独自のトランザクションログもあるので、ファイルシステムレベルでジャーナリングをオフにしても機能する可能性がありますが、「enableJournalDiskSyncs」を使用するようにしてください。バックエンドのオプションです。まだ行っていない場合は、おそらく別のブロックデバイスにも配置します。

(詳しくは、http://activemq.apache.org/kahadb.htmlを参照してください


1

同期書き込みは遅いため、すべてをバッファリングします。ウィキペディアでIOPSを確認すると、典型的な7,200 rpmのHDDには75-100 IOPSがあることがわかります。Macbook Proの技術仕様を見てください。これには5,400 rpmのHDDが搭載されています。これは最高で75%のパフォーマンスであるため、ラップトップで最高50-75 IOPSを検討しています。

MQは、データ台帳と会計台帳を作成している可能性があります。これにより、ActiveMQベンチマークに表示されている20 IOPSに到達できます。

tmpfs、つまりインメモリファイルシステムでテストするか、SSDを使用するという2つのオプションがあります。通常、同期書き込みを使用するサーバーには、15,000 rpmのディスクを持つ重要なSAS / SCSI RAIDアレイがあります。容量を増やすのではなく、パフォーマンスを向上させるためにアレイに追加のディスクが追加されます。


1

ホスティングされたVM(VirtualBox内)で、64ビットのUbuntu 11.10サーバーを実行し、ext4も使用して、次の結果を得ました。

Sync Writes:
 288 writes of size 4096 written in 10.034 seconds.
 28.702412 writes/second.
 0.112118796 megs/second.

Redhat 5.7 64ビットを実行し、ext3を使用する物理サーバーでは、次の結果が得られました。

Sync Writes:
  54987 writes of size 4096 written in 10.001 seconds.
  5498.1504 writes/second.
  21.47715 megs/second.

OPがVMでもこれを実行していたのか、ext3とext4の間に問題があるのでしょうか。ホストされている環境とホストされていない環境に違いがある可能性があることを感謝しますが、そのような大きな違いは期待していませんでした。


0

より大きいブロックサイズを使用します。同期/非同期IOをダイレクト/バッファIOと混同しているのではないですか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.