Sinkronisasi menulis sangat lambat. Ubuntu 10.10, 32 bit, ext4

Saya menjalankan ActiveMQ pada Macbook Pro saya yang menjalankan Ubuntu 10.10, 32 bit dengan partisi ext4.

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

Jika saya mengaktifkan kegigihan di ActiveMQ kinerja turun sangat. Saya sudah menguji hal yang sama pada mesin lain dan perbedaannya adalah 2 urutan besarnya.

Ada alat dengan activeMQ untuk menguji HD, berikut hasilnya:

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.

Performa untuk Sync Sync adalah s ** t. Pasti ada sesuatu yang salah konfigurasi, tetapi ini adalah satu-satunya aplikasi di mana saya perhatikan ada masalah kinerja HD.

hdparm melempar nilai yang diharapkan:

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

Faktor pembatas utama untuk IO sinkron bukanlah throughput dari hard drive Anda, melainkan waktu yang diperlukan dari saat penulisan dikeluarkan dan sedang dilakukan ke disk. Metrik kinerja yang paling relevan untuk harddrive dalam hal ini adalah waktu yang dibutuhkan harddrive dan bukan throughputnya dalam kondisi ideal.

Selain perangkat keras yang bekerja melawan Anda, begitu juga kernelnya, saya kira Anda mungkin melihat peningkatan kecil (meskipun, mungkin jauh dari apa yang akan Anda dapatkan dari melakukan Iync async) jika Anda dapat mengukur benchmark (aplikasi) ke berjalan di bawah kelas penjadwalan IO realtime. Secara default, aplikasi akan dijadwalkan di bawah kelas upaya terbaik, yang mungkin juga akan menambah waktu tunggu penulisan Anda. Gunakan kelas penjadwalan waktu nyata dengan risiko Anda sendiri, karena akan memiliki efek buruk pada kinerja aplikasi lain saat mengakses disk.

Secara umum, saya tidak benar-benar berpikir ada yang salah dengan kinerja penulisan sinkron yang Anda lihat. Synchronous IO secara umum akan berperforma buruk dibandingkan dengan IO asynchronous.

Sebagai catatan, google cepat activemq dan syncio memberikan yang berikut :

Untuk alasan kinerja, Anda mungkin ingin mengalirkan pesan ke broker secepat mungkin bahkan jika Anda menggunakan pesan persisten

Penjadwal cfq I / O cenderung berkinerja buruk dalam jenis tes ini. Selain saran ionice sebelumnya, Anda mungkin ingin mencoba beralih ke penjadwal I / O batas waktu (baik dengan booting dengan elevator=deadlineatau dengan melakukan for n in /sys/block/sd*/queue/scheduler ; do echo deadline > $n ; donesebagai root).

Tulisan sinkron harus menerima kembali pernyataan bahwa penulisan telah dilakukan (apakah komit itu berhasil atau salah) sebelum dapat kembali dengan sendirinya. Ini adalah desain, dan secara inheren membuat sinkron menulis jauh lebih lambat karena waktu latensi tinggi yang terlibat dengan disk logam berputar (pada cache ram disk tidak masuk hitungan).

Penulisan asinkron biasanya ditulis ke RAM dan OS berurusan dengan mengkomit ke disk nanti (nanti biasanya hanya beberapa detik atau kurang (saya percaya ZFS adalah 5x / detik, atau setiap 5 detik)). Waktu pencarian disk diukur dalam ms sedangkan waktu pencarian RAM diukur dalam ns. Itu perbedaan 1000x.

Gunakan penulisan sinkron ketika sangat penting bahwa data disimpan secara permanen sebelum melanjutkan dan penundaan 1 detik di mana kehilangan daya dapat terjadi tidak dapat diterima.

Gunakan tulisan asinkron di semua waktu lainnya.

Alasan yang paling mungkin Anda melihat gangguan kinerja ini adalah karena Anda menggunakan "-o sync" dengan sistem file jurnal dan hambatan dihidupkan (yang merupakan standar untuk ext4).

Di sinilah keputusan tentang apa yang harus dilakukan untuk memperbaikinya menjadi sangat sulit.

Sebagian besar bermuara pada seberapa banyak Anda mempercayai perangkat keras Anda.

Dari mount (8): "Hambatan tulis memberlakukan pemesanan jurnal yang dilakukan di disk, membuat cache tulisan volatile disk aman untuk digunakan, pada beberapa penalti kinerja. Sistem file ext3 tidak mengaktifkan penghalang penulisan secara default. Pastikan untuk mengaktifkan penghalang kecuali disk Anda didukung oleh baterai dengan satu atau lain cara. Kalau tidak, Anda berisiko korupsi sistem file jika terjadi kegagalan daya. "

Jadi, terima fakta bahwa "-o sync" kinerjanya suram, atau beli cache yang didukung baterai untuk controller Anda dan disk SAS yang sangat bagus, lalu matikan penghalang menggunakan "-o sync, nobarrier".

Jika yang saat ini Anda gunakan adalah backend penyimpanan kelas perusahaan FC atau iSCSI yang tepat, maka saya kira Anda juga aman untuk melakukan yang terakhir.

Secara keseluruhan, ActiveMQ 5.4 menggunakan backend penyimpanan KahaDB secara default, dan bahwa seseorang memiliki log transaksi sendiri juga, jadi mungkin bahkan mematikan penjurnalan pada tingkat filesystem dapat bekerja untuk Anda, tetapi kemudian pastikan Anda menggunakan "enableJournalDiskSyncs" opsi untuk backend, dan Anda mungkin ingin meletakkannya di perangkat blok terpisah juga jika Anda belum.

(lihat http://activemq.apache.org/kahadb.html untuk lebih lanjut)

Menulis sinkron lambat, itu sebabnya kami buffer semuanya. Lihatlah IOPS di Wikipedia dan Anda akan melihat HDD 7.200 rpm memiliki 75-100 IOPS. Sekarang lihat spesifikasi teknis Macbook Pro , dan ia memiliki HDD 5.400 rpm. Itu kinerja terbaik 75% sehingga Anda melihat 50-75 IOPS terbaik untuk laptop.

Seorang MQ mungkin menulis buku besar data dan buku besar akuntansi, yang membawa Anda ke 20 IOPS yang Anda lihat di benchmark ActiveMQ.

Anda memiliki dua opsi, uji pada tmpfs , yaitu sistem file dalam memori, atau gunakan SSD. Biasanya server yang menggunakan penulisan sinkron akan memiliki array RAID SAS / SCSI yang signifikan dengan disk 15.000 rpm. Disk tambahan ditambahkan ke array untuk meningkatkan kinerja, bukan untuk meningkatkan kapasitas.

Pada VM yang dihosting (dalam VirtualBox) yang menjalankan Ubuntu 11.10 server 64 bit juga menggunakan ext4, kami memperoleh hasil sebagai berikut:

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

Pada server fisik yang menjalankan Redhat 5.7 64 bit menggunakan ext3 hasil berikut diperoleh:

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

Saya bertanya-tanya apakah OP menjalankan ini dalam VM juga atau jika ada masalah antara ext3 dan ext4. Saya menghargai bahwa mungkin ada perbedaan antara lingkungan yang dihosting dan yang tidak dihosting, namun tidak mengharapkan perbedaan yang begitu besar.

Gunakan ukuran blok yang lebih besar. Apakah Anda mungkin mengacaukan sync / async IO dengan IO langsung / buffered?