Najnowsze wersje RHEL / CentOS (EL6) przyniósł kilka interesujących zmian w systemie plików XFS ja zależała w dużym stopniu od ponad dziesięciu lat. Spędziłem część zeszłego lata, ścigając sytuację rzadkich plików XFS wynikającą ze źle udokumentowanego backportu jądra. Inni mieli niefortunne problemy z wydajnością lub niespójne zachowanie od czasu przejścia na EL6.
XFS był moim domyślnym systemem plików dla partycji danych i wzrostu, ponieważ oferował stabilność, skalowalność i dobry wzrost wydajności w porównaniu z domyślnymi systemami plików ext3.
Wystąpił problem z XFS w systemach EL6, które pojawiły się w listopadzie 2012 r. Zauważyłem, że moje serwery wykazują nienormalnie wysokie obciążenia systemu, nawet gdy są bezczynne. W jednym przypadku nieobciążony system wykazywałby stałą średnią wartość obciążenia wynoszącą 3+. W innych wystąpił wzrost obciążenia o 1+. Wydaje się, że liczba zamontowanych systemów plików XFS wpływa na nasilenie wzrostu obciążenia.
System ma dwa aktywne systemy plików XFS. Obciążenie wynosi +2 po aktualizacji do dotkniętego jądra.
Kopanie głębiej, znalazłem kilka tematów na liście dyskusyjnej XFS , które wskazywały na zwiększoną częstotliwością xfsaildprocesu siedzi w STAT D państwa. Odpowiednie wpisy śledzenia błędów CentOS i błędów Bugzilli w Red Hat przedstawiają specyfikę problemu i stwierdzają, że nie jest to problem z wydajnością; tylko błąd w raportowaniu obciążenia systemu w jądrach nowszych niż 2.6.32-279.14.1.el6 .
WTF?!?
W jednorazowej sytuacji rozumiem, że raportowanie obciążenia może nie być wielkim problemem. Spróbuj zarządzać tym za pomocą NMS i setek lub tysięcy serwerów! Zostało to zidentyfikowane w listopadzie 2012 r. W jądrze 2.6.32-279.14.1.el6 pod EL6.3. Jądra 2.6.32-279.19.1.el6 i 2.6.32-279.22.1.el6 zostały wydane w kolejnych miesiącach (grudzień 2012 i luty 2013) bez zmiany tego zachowania. Od czasu zidentyfikowania tego problemu pojawiła się nawet nowa, niewielka wersja systemu operacyjnego. EL6.4 został wydany i jest teraz w jądrze 2.6.32-358.2.1.el6 , który wykazuje takie samo zachowanie.
Miałem nową kolejkę kompilacji systemu i musiałem obejść ten problem, albo blokując wersje jądra w wersji przed listopadem 2012 dla wersji EL6.3, albo po prostu nie używając XFS, wybierając ext4 lub ZFS , z poważnym ograniczeniem wydajności dla konkretnej aplikacji niestandardowej działającej na szczycie. Ta aplikacja w dużej mierze opiera się na niektórych atrybutach systemu plików XFS, aby uwzględnić wady w projekcie aplikacji.
Idąc za płatną stroną bazy wiedzy Red Hat , pojawia się wpis z informacją:
Po zainstalowaniu jądra 2.6.32-279.14.1.el6 obserwuje się wysoką średnią obciążenia. Wysoka średnia obciążenia jest spowodowana przejściem xfsaild w stan D dla każdego urządzenia sformatowanego w systemie XFS.
Obecnie nie ma rozwiązania tego problemu. Obecnie jest śledzony za pośrednictwem Bugzilli # 883905. Obejście problemu Zmień wersję zainstalowanego pakietu jądra na wersję niższą niż 2.6.32-279.14.1.
(z wyjątkiem obniżenia jądra, które nie jest opcją w RHEL 6.4 ...)
Mamy więc ponad 4 miesiące od pojawienia się tego problemu i nie planujemy żadnej prawdziwej poprawki dla wersji systemu operacyjnego EL6.3 lub EL6.4. Jest proponowana poprawka do EL6.5 i łatka na jądro dostępna ... Ale moje pytanie brzmi:
W jakim momencie sensowne jest odejście od jąder i pakietów dostarczanych przez system operacyjny, gdy opiekun nadrzędny zepsuje ważną funkcję?
Red Hat wprowadził ten błąd. One powinny zawierać poprawki do jądra o errata. Jedną z zalet korzystania z systemów operacyjnych dla przedsiębiorstw jest to, że zapewniają one spójny i przewidywalny cel platformy . Ten błąd zakłócił działanie systemów już produkowanych podczas cyklu łatania i zmniejszył zaufanie do wdrażania nowych systemów. Chociaż mógłbym zastosować jedną z proponowanych poprawek do kodu źródłowego , jak bardzo jest to skalowalne? Wymagałoby to zachowania czujności, aby aktualizować się wraz ze zmianami systemu operacyjnego.
Jaki jest odpowiedni ruch tutaj?
- Wiemy, że można to naprawić, ale nie kiedy.
- Wspieranie własnego jądra w ekosystemie Red Hat ma własny zestaw ostrzeżeń.
- Jaki wpływ ma na kwalifikowalność do wsparcia?
- Czy powinienem po prostu nałożyć działające jądro EL6.3 na nowo budowane serwery EL6.4, aby uzyskać odpowiednią funkcjonalność XFS?
- Czy powinienem tylko poczekać, aż zostanie to oficjalnie naprawione?
- Co to mówi o braku kontroli nad cyklami wydań Linuxa dla przedsiębiorstw?
- Czy poleganie na systemie plików XFS było tak długo błędem planowania / projektowania?
Edytować:
Ta łatka została włączona do najnowszej wersji jądra CentOSPlus ( kernel-2.6.32-358.2.1.el6.centos.plus ). Testuję to na moich systemach CentOS, ale to niewiele pomaga serwerom opartym na Red Hat.