Alasan kjournald untuk penggunaan tinggi

15

Saya mencoba mencari tahu mengapa kjournaldmesin saya menjadi gila. Ini adalah kotak 8-core dengan banyak memori. Itu punya ~ beban cpu 50%.

Iotop tampaknya tidak menunjuk pada proses tertentu - beberapa semburan penulisan di sana-sini (sebagian besar cron dimulai, beberapa statistik pemantauan dihasilkan, dll.) Ketika saya sys/vm/block_dumpmengumpulkan statistik penulisan, saya mendapat daftar seperti ini:

kjournald(1352): 1909
sendmail(28934): 13
cron(28910): 12
cron(28912): 11
munin-node(29015): 3
cron(28913): 3
check_asterisk_(28917): 3
sh(28917): 2
munin-node(29022): 2
munin-node(29021): 2

Di mana kjournaldtindakan hanyalah MENULIS.

Mengapa itu terjadi? Apa lagi yang harus saya perhatikan untuk membatasi aktivitas kjournald sedikit? Tampaknya tidak proporsional dengan apa yang sebenarnya ditulis.

— viraptor
sumber

OS apa yang Anda gunakan. Bisakah Anda memposting informasi yang tidak diketahui.

— Soham Chakraborty

Saya memiliki masalah yang sama persis

— Sharen Eayrs

15

kjournaldbertanggung jawab atas jurnal ext3 (journaling filesystem). Itu diketahui menggunakan banyak CPU di bawah beban tertentu. Tidak banyak yang bisa dilakukan kecuali menggunakan sistem file lain atau menonaktifkan penjurnalan (secara efektif membuat fs ext2).

Secara teoritis Anda dapat menggunakan salah satu mode lain dari penjurnalan ext3 dan memeriksa apakah penggunaan CPU turun, tetapi ingat bahwa setiap metode adalah kompromi pada keamanan data yang ditulis ke disk. Anda telah memesan mode, mode penulisan kembali dan mode 'semuanya'.

Dipesan: Hanya jurnal metadata, tetapi memastikan bahwa data yang terkait dengan metadata disimpan sebelum melakukan perubahan metadata ke jurnal.
writeback: hanya jurnal metadata, tetapi tidak memiliki jaminan bahwa data disimpan sebelum jurnal melakukan.
jurnal: semuanya dijurnal, data, dan metadata. Mungkin lambat tapi YMMV.

Anda mengatur mode menggunakan opsi data=saat memasang sistem, seperti data=ordered.

— coredump
sumber

Tidak ada gunanya untuk mengubah mode penjurnalan yang bertentangan dengan mematikannya sepenuhnya, tetapi bahkan lebih tidak masuk akal. Jadi, menjelaskan opsi jurnal apa yang tidak ada gunanya.

— poige

3

Mode jurnal yang berbeda menunjukkan perilaku CPU yang berbeda. Beberapa tes di sini .

— coredump

1

@coredump, masih tidak ada gunanya . Tidak ada grafik yang menunjukkan penggunaan CPU untuk mode penjurnalan yang berbeda, hanya throughput. Grafik penggunaan CPU menunjukkan perbedaan antara FSes saja, sebenarnya. Selain itu, mempertimbangkan perbedaan agak mencolok antara EXT3 dan Reiser3 pada grafik itu jelas bahwa keseluruhan dan rata-rata jejak CPU dianalisis, sedangkan @viraptor memiliki tombak aktivitas kjournald.

— poige

Kami akan setuju untuk tidak setuju. Hanya pengujian pada lingkungannya yang akan menunjukkan ada perbedaan atau tidak pada penggunaan CPU. Juga saya tidak akan merekomendasikan ReiserFS, karena pemerintah mendapat kunci permanen pada penulis FS :).

— coredump

8

Di sini, ambil cawan humor ini: \

— coredump

4

Secara default sistem file ext3 Anda akan dipasang dengan atimes dihidupkan. Setiap kali file atau direktori dibaca / diakses, sistem file harus menulis kembali ke disk untuk memperbarui catatan atime ini. Ini berarti bahwa meskipun beban kerja Anda sebagian besar berbasis baca, Anda masih perlu menekan disk untuk memperbarui waktu akses setiap file & direktori, dan ini adalah dugaan saya mengapa kjournaldproses Anda menulis begitu banyak blok.

Mematikan atime akan menghasilkan peningkatan kinerja yang besar tetapi akan merusak kepatuhan POSIX. Lihatlah artikel Wikipedia ini untuk beberapa diskusi seputar kritik terhadap atime.

Untuk mematikan atimes, tambahkan saja noatimeopsi mount untuk sistem file Anda, atau Anda dapat melakukan remount seperti yang disarankan oleh poige. Berikut ini contoh untuk sistem berkas root Anda:

mount -o remount,noatime /

— Evan Borgstrom
sumber

3

Perhatikan bahwa kernel yang lebih baru default ke relatimekompromi yang tampaknya dapat diterima antara noatimedan atime.

— Oliver

1

Jika kesempurnaan data tidak penting: lakukan ini

iostat -o -a

Pastikan itu benar-benar kjournald. Itu yang menyebabkan server saya crash.

Mengubah hard drive ke SSD akan berfungsi.

Ketika Anda melihat kjournald menulis 5-10MB data yang Anda lakukan

http://ubuntuforums.org/showthread.php?t=56621

sudo tune2fs -O ^has_journal /dev/sda1
sudo e2fsck /dev/sda1

di mana sda1 adalah nama partisi Anda

Laporkan hasil dalam komentar sehingga saya dapat memeriksa lebih lanjut.

— Sharen Eayrs
sumber

3

Maksudmu iotop, bukan iostat, kan?

— Joe Niland

0

Tidak untuk melakukan, hanya untuk menyebutkan:

mount -oremount,noatime /fs/being_over/journaled- sebagai tebakan cepat ( mounttoh Anda tidak menunjukkan seperti apa penampilan Anda )
Coba kurangi ukuran jurnal ( tune2fs -J …)
Beralih ke Reiser3 (kuat untuk waktu yang cukup lama, ya. Dan tidak ada jurnal yang jahat seperti itu.)

— poige
sumber