web-dev-qa-db-ja.com

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

Ubuntu 10.10、32ビットをext4パーティションで実行するMacbookProで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
linuxperformanceext4hard-disk
8
Iker Jimenez

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

ハードウェアが機能していることに加えて、カーネルも同様です。ベンチマーク（アプリケーション）をイオン化できれば、わずかな改善が見られるかもしれません（ただし、非同期IOを実行することで得られるものにはほど遠いでしょう）。リアルタイムIOスケジューリングクラスで実行します。デフォルトでは、アプリケーションはベストエフォートクラスでスケジュールされます。これにより、書き込みの待機時間も長くなる可能性があります。でリアルタイムスケジューリングクラスを使用してください。ディスクにアクセスするときに他のアプリケーションのパフォーマンスに悪影響を与えるため、自己のリスクがあります。

一般的に、私はあなたが見ている同期書き込みパフォーマンスにひどく悪いことは何もないと思います。同期IOは、一般に非同期IOと比較してひどいパフォーマンスを示します。

補足として、activemqと同期ioの簡単なグーグルは 以下 を与えました：

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

7
Kjetil Jorgensen

Cfq I/Oスケジューラーは、この種のテストでひどく実行される傾向があります。以前のioniceの提案に加えて、期限I/Oスケジューラへの切り替えを試してみることをお勧めします（elevator=deadlineで起動するか、ルートとしてfor n in /sys/block/sd*/queue/scheduler ; do echo deadline > $n ; doneを実行します）。

3
Steven Pritchard

同期書き込みは、それ自体を返す前に、書き込みがコミットされたという確認応答を受信する必要があります（コミットが成功したかエラーであったかは関係ありません）。これは仕様によるものであり、金属ディスクの回転に伴う待ち時間が長いため、本質的に同期書き込みが非常に遅くなります（ディスクRAMキャッシュではカウントされません）。

非同期書き込みは通常RAMに書き込まれ、OSは後でディスクへのコミットを処理します（後で通常はほんの数秒以下です（ZFSは5x /秒または5秒ごとだと思います））。ディスクシーク時間はミリ秒で測定され、RAMシーク時間はnsで測定されます。これは、1000倍の差です。

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

それ以外の場合は非同期書き込みを使用してください。

3
bahamat

このパフォーマンスの低下が見られる最も可能性の高い理由は、ジャーナルファイルシステムで「-osync」を使用していて、バリアがオンになっているためです（これはext4のデフォルトです）。

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

それは主にあなたがあなたのハードウェアをどれだけ信頼するかに要約されます。

Mount（8）から：「書き込みバリアはジャーナルコミットの適切なディスク上の順序を強制し、パフォーマンスの低下を伴いながら、揮発性ディスクの書き込みキャッシュを安全に使用できるようにします。ext3ファイルシステムはデフォルトで書き込みバリアを有効にしません。ディスクは何らかの方法でバッテリバックアップされています。そうしないと、電源障害が発生した場合にファイルシステムが破損するリスクがあります。」

したがって、「-o sync」のパフォーマンスが悪いという事実を受け入れるか、コントローラー用にバッテリーでバックアップされたキャッシュを購入し、本当に良いSASディスクの場合、「-o sync、nobarrier」を使用してバリアをオフにします。

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

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

（詳細については、 http://activemq.Apache.org/kahadb.html を参照してください）

2
Grega Bremec

同期書き込みは遅いので、すべてをバッファリングします。ウィキペディアで [〜＃〜] iops [〜＃〜] を見ると、一般的な7,200rpmのHDDのIOPSが75〜100であることがわかります。ここで Macbook Proの技術仕様 を見てください。5,400rpmのHDDが搭載されています。これはせいぜい75％のパフォーマンスなので、ラップトップではせいぜい50〜75IOPSを見ています。

MQは、データ元帳とアカウンティング元帳を作成している可能性があります。これにより、ActiveMQベンチマークで表示されている20IOPSに到達します。

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

1
Steve-o

同じくext4を使用してUbuntu11.10サーバー64ビットを実行しているホストされたVM（VirtualBox内））で、次の結果が得られました。

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

Ext3を使用してRedhat5.7 64ビットを実行している物理サーバーでは、次の結果が得られました。

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

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

1
Alex

より大きなブロックサイズを使用してください。同期/非同期IOと直接/バッファIO）を混同していませんか？

0
Thorsten Staerk