kjournald yüksek kullanım nedenleri

Makinemde neden kjournalddelirdiğini anlamaya çalışıyorum . Hafızası bol olan 8 çekirdekli bir kutu. ~% 50 işlemci yükü var.

Iiotop herhangi bir özel işleme işaret etmiyor gibi görünüyor - burada ve orada bazı yazma patlamaları (çoğunlukla cron başlangıcı, üretilen bazı izleme istatistikleri, vb.) sys/vm/block_dumpYazma istatistiklerini toplarken, şöyle listeler aldım:

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

Nerede kjournaldeylemler sadece yazar vardır.

Bu neden oluyor? Kjournald etkinliğini biraz sınırlamak için başka nelere bakmalıyım? Aslında yazılanlarla orantısız görünüyor.

kjournaldext3 (günlük kaydı dosya sistemi) günlüğünden sorumludur. Belirli yükler altında çok fazla CPU kullanıldığı bilinmektedir. Başka bir dosya sistemi kullanmak veya günlük kaydını devre dışı bırakmak (fs ext2'yi etkin yapmak) dışında yapılacak çok şey yoktur.

Teorik olarak, ext3 günlük kaydının diğer modlarından birini kullanabilir ve CPU kullanımının düşüp düşmediğini kontrol edebilirsiniz, ancak her yöntemin diske yazılan verilerin güvenliğinden ödün verildiğini unutmayın. Modu, geri yazma modunu ve 'her şey' modunu sipariş ettiniz.

1. Sıralı: yalnızca meta verileri günlüğe kaydeder, ancak meta verilerle ilgili günlüğe değişiklikler yapılmadan önce meta verilerle ilgili verilerin kaydedilmesini sağlar.
2. writeback: yalnızca meta veriler günlüğe kaydeder, ancak günlük kaydedilmeden önce verilerin kaydedileceğini garanti etmez.
3. günlük: her şey günlüğe kaydedilir, veriler ve meta veriler. Yavaş ama YMMV olabilir.

Modu data=, sistemi monte ederken olduğu gibi seçeneğini kullanarak ayarlarsınız data=ordered.

Varsayılan olarak ext3 dosya sisteminiz atime açıkken monte edilecektir. Bir dosya veya dizin her okunduğunda / erişildiğinde dosya sisteminin bu atime kaydını güncellemek için disklere geri yazması gerekir. Bu, iş yükünüz çoğunlukla okuma tabanlı olsa bile, yine de her dosya ve dizinin erişim zamanlarını güncellemek için disklere basmanız gerektiği anlamına gelir ve bu da kjournaldişleminizin neden bu kadar çok blok yazdığına dair tahminimdir .

Atime'lerin kapatılması performansta büyük bir artış sağlayacaktır ancak POSIX uyumluluğunu bozacaktır. Atime'nin eleştirisi hakkında bazı tartışmalar için bu Wikipedia makalesine göz atın .

Atime'leri kapatmak için sadece noatimedosya sisteminizin bağlama seçeneklerine ekleyin veya poige tarafından önerilen şekilde yeniden monte edebilirsiniz. Kök dosya sisteminize bir örnek:

mount -o remount,noatime /

Verilerin mükemmelliği önemli değilse: bunu yapın

iostat -o -a

Gerçekten kjournald olduğundan emin olun. Sunucumun çökmesine neden olan şey bu.

Sabit sürücüyü SSD olarak değiştirmek işe yarayacaktır.

Kjournald 5-10MB veri yazdığınızı gördüğünüzde

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

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

burada sda1 bölümünüzün adıdır

Daha fazla kontrol edebilmem için sonucu yorum olarak bildirin.

Sırayla değil, sadece belirtmek gerekirse:

1. mount -oremount,noatime /fs/being_over/journaled- hızlı bir tahmin çekimi olarak (bize mountzaten neye benzediğini göstermedin )
2. Dergi boyutunu azaltmayı deneyin ( tune2fs -J …)
3. Geçin Reiser3 (oldukça uzun bir süre için sağlam, evet. Ve böyle bir kötü hiç günlük kaydı.)