kjournald powodów wysokiego zużycia

Próbuję dowiedzieć się, dlaczego kjournaldwariuje na mojej maszynie. To 8-rdzeniowe pudełko z dużą ilością pamięci. Ma ~ 50% obciążenia procesora.

Wydaje się, że iotop nie wskazuje na żadne specyficzne procesy - niektóre serie zapisów tu i tam (głównie uruchamianie crona, generowanie statystyk monitorowania itp.) Kiedy sys/vm/block_dumpzbierałem statystyki zapisu, otrzymałem takie listy:

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

Gdzie kjournalddziałania są po prostu NAPISZ.

Dlaczego tak się dzieje? Na co jeszcze należy spojrzeć, aby nieco ograniczyć aktywność kjournald? Wydaje się nieproporcjonalne w stosunku do tego, co faktycznie jest pisane.

kjournaldodpowiada za dziennik systemu ext3 (kronikowanie systemu plików). Znane jest używanie dużej ilości procesora pod pewnymi obciążeniami. Nie ma wiele do roboty poza użyciem innego systemu plików lub wyłączeniem kronikowania (skutecznie tworząc fs ext2).

Teoretycznie możesz użyć jednego z innych trybów kronikowania ext3 i sprawdzić, czy zużycie procesora spada, ale pamiętaj, że każda metoda stanowi kompromis w zakresie bezpieczeństwa danych zapisywanych na dysku. Masz zamówiony tryb, tryb zapisu i tryb „wszystko”.

1. Zamówione: tylko metadane dziennika, ale zapewnia, że ​​dane związane z metadanymi są zapisywane przed zatwierdzeniem zmian metadanych w dzienniku.
2. zapis zwrotny: metadane tylko dla dziennika, ale nie ma gwarancji, że dane zostaną zapisane przed zatwierdzeniem dziennika.
3. czasopismo: wszystko jest kronikowane, dane i metadane. Może to być powolne, ale YMMV.

Tryb ustawia się za pomocą opcji data=podczas montażu systemu, np data=ordered.

Domyślnie twój system plików ext3 będzie montowany z włączonymi czasami. Za każdym razem, gdy plik lub katalog jest odczytywany / uzyskiwany do niego dostęp, system plików będzie musiał ponownie zapisywać na dyskach, aby zaktualizować ten rekord atime. Oznacza to, że nawet jeśli obciążenie jest w większości oparte na odczycie, nadal musisz uderzać dyski, aby zaktualizować czasy dostępu do każdego pliku i katalogu, i to jest moje przypuszczenie, dlaczego twój kjournaldproces pisał tak wiele bloków.

Wyłączenie atime spowoduje znaczny wzrost wydajności, ale złamie zgodność z POSIX. Sprawdź ten artykuł w Wikipedii, aby uzyskać dyskusję na temat krytyki atime.

Aby wyłączyć czasami, po prostu dodaj noatimedo opcji montowania systemu plików lub możesz zamontować ponownie, jak sugeruje poige. Oto przykład twojego głównego systemu plików:

mount -o remount,noatime /

Jeśli doskonałość danych nie jest ważna: zrób to

iostat -o -a

Upewnij się, że to naprawdę kjournald. To powoduje awarię mojego serwera.

Działa zmiana dysku twardego na SSD.

Gdy zobaczysz, że Kjournald pisze 5-10 MB danych, robisz

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

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

gdzie sda1 to nazwa twojej partycji

Zgłoś wynik w komentarzu, abym mógł dalej sprawdzić.

Nie w kolejności, aby wspomnieć:

1. mount -oremount,noatime /fs/being_over/journaled- jako szybkie zgadywanie (i tak nie pokazałeś nam, mountjak wyglądasz)
2. Spróbuj zmniejszyć rozmiar dziennika ( tune2fs -J …)
3. Przejdź na Reiser3 (solidny od dłuższego czasu, tak. I nigdy nie było tak nieprzyjemnego dziennikarstwa).