Kernel Traffic #136 For 8 Oct 2001

Ponieważ Ty dodajesz taką funkcjonalność i wygląda na to, że inni dodają podobne rzeczy, byłoby *bardzo* sensownie, aby umożliwić umieszczanie wszystkich zrzutów w jednym, wybranym miejscu (moje pierwsze skojarzenie to /var/core), tak aby nie skoñczyło się miejsce na dysku w przypadku uzyskania wielu zrzutów.

Nazwa katalogu mogłaby być ustalona w /proc/sys/coredir (czy jakoś tak) z domyślną wartością "." oczywiście.

Poza tym podoba mi się pomysł, chociaż uważam, że ,,nazwa'' procesu może spowodować wiele konfliktów pomiędzy wątkami, a pidy są powtarzalne. Być może jest lepszy pomysł, ale większość moich jest niedorobiona. To naprawdę ułatwiłoby większość analiz zrzutów.

Tak jak o to proszono, tu są wyniki testów, które przeprowadziłem na ostatnich łatach VM. Testy są opisane w poprzedniej wiadomości dostępnej tutaj:

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0109.3/0033.html

Wyniki:

Wydajność 2.4.10 jest o niebo lepsza w porównaniu do 2.4.[7-9], ale testy cały czas pokazują, że jest jeszcze miejsce na poprawki w VM z 2.4.10. 2.4.10 i 2.4.10(+00_vm-tweaks-1) zachowywały się podobnie. Łata vm-tweaks poprawiła działanie swapa, ale ani liczba stron wyswapowywanych, ani liczba stron zeswapowywanych się specjalnie nie zmieniły. Zatykanie systemu brudnymi stronami przy pomocy 'dd' cały czas powoduje przeskakiwanie w XMMS.

Przetestujemy dokładniej kod starzenia/porządkowania listy przez większe obciążanie systemu w kroku d), dodając mozillę do testów aplikacji zwykłego użytkownika. Będziemy także odgrywać strumieñ audio mp3 przez cały test.

2.4.10(+00_vm-tweaks-1)
48 sekund - ładowanie StarOffice
28 sekund - obrót obrazka 2560x2560 w GIMP-ie
82400 KB wyswapowanych, 92148 KB zeswapowanych z powrotem

2.4.9-ac14 + starzenie (ang. aging
33 sekundy - ładowanie StarOffice
25 sekund - obrót obrazka w GIMP-ie
30072 KB wyswapowanych, 22252 KB zeswapowanych z powrotem

2.4.9-ac15 + starzenie + czyszczenie (ang. launder)
33 sekundy - ładowanie StarOffice
24 sekundy - obrót obrazka w GIMP-ie
57556 KB wyswapowanych, 25900 KB zeswapowanych z powrotem

Sesje 'vmstat 1' dla wszystkich trzech przypadków są dostępne pod adresem: http://loke.as.arizona.edu/~ckulesa/kernel/

Widać, że 2.4.10+ pracuje DUŻO ciężej, aby trzymać cache dentry i i-węzłów w pamięci, i bardziej wyswapowuje, aby to zrównoważyć. Jądra ac14/ac15 znacznie swobodniej operują na tym cache'u, i nie wyswapowują stron pamięci używanych przez aplikację tak czytelnie.

Sprawdźmy to nie wypełniając uprzednio cache'u i-węzłów i dentry przy użyciu 'slocate' i przeprowadzając ten sam test:

2.4.10(+00_vm-tweaks)
26 sekund - ładowanie StarOffice
24 sekundy - obrót obrazka w GIMP-ie
48332 KB wyswapowanych, 33521 KB zeswapowanych z powrotem

2.4.9-ac14 + starzenie
32 sekund - ładowanie StarOffice
26 sekund - obrót obrazka w GIMP-ie
37392 KB wyswapowanych, 11952 KB zeswapowanych z powrotem

2.4.9-ac15 + starzenie + czyszczenie
32 sekundy - ładowanie StarOffice
22 sekundy - obrót obrazka w GIMP-ie
23884 KB wyswapowanych, 10828 KB zeswapowanych z powrotem

2.4.10 tym razem sprawuje się znacznie lepiej; w szczególności ładowanie StarOffice, które było tak obciążone przez wyswapowywanie, spowodowane przez cache'owanie dentry/i-węzłów poprzednio, przebiegło o wiele lepiej. Jednakże, cały czas jest więcej stronicowania niż w 2.4.9-ac1[4-5].

Zróbmy jeszcze jeden eksperyment ze starzeniem/porządkowaniem listy. Zamiast najpierw tworzyć obrazek 2560x2560 w GIMP-ie, a potem ładować StarOffice i inne aplikacje (aby rozpocząć swapowanie i spowodować, aby strony GIMP-a były kandydatami do zabrania) -- tym razem załadujmy StarOffice najpierw, a dopiero później stwórzmy obrazek w GIMP-ie. To powinno utrzymać strony obrazka w GIMP-ie 'młodszymi' i przypuszczalnie nie powinny stronicować się z powrotem do pamięci (obrót powinien być szybszy). Jednakże StarOffice może dużo intensywniej swapować.

2.4.10(+00_vm-tweaks)
25 sekund - ładowanie StarOffice
29 sekund - obrót obrazka w GIMP-ie
64427 KB wyswapowanych, 77422 KB zeswapowanych z powrotem

2.4.9-ac14 + starzenie
30 sekund - ładowanie StarOffice
24 sekundy - obrót obrazka w GIMP-ie
22147 KB wyswapowanych, 8922 zeswapowanych z powrotem

2.4.9-ac15 + starzenie + czyszczenie
31 sekund - ładowanie StarOffice
21 sekund - obrót obrazka GIMP-ie
17204 KB wyswapowanych, 8224 zeswapowanych z powrotem

Zachowanie 2.4.10 zaskoczyło mnie. Strony GIMP-a są młodsze w pamięci, ale obrót obrazka został spowolniony przez swapowanie -- wolniejszy niż poprzednio. Do tego więcej stron StarOffice zostało wyswapowanych, więc musiały zostać zeswapowane, aby zamknąć aplikację. Jestem zakręcony. Zachowanie ac14/ac15 było bliższe moim oczekiwaniom; strony GIMP-a były młode i nie swapowane. Tylko najwcześniejsze strony StarOffice musiały zostać przywołane.

To są przykłady raczej 'zwykłego' obciążenia, przy którym 2.4.10 musi wykonać trochę pracy przy obsłudze; jądro ac15 sprawuje się przynajmniej przy tym zestawie testów lepiej (ac15 również nie powoduje skoków XMMS przy tworzeniu dużej liczby brudnych stron przy pomocy 'dd'). Ale wszystkie trzy jądra w czasie testów nie powodowały zamrożenia systemu, co jest znacznym postępem w stosunku do wcześniejszych wersji 2.4. Bardzo fajnie.

Uwaga odnośnie page_lander(). ac14 ma najsprawniejsze swapowanie, z małymi kawałkami czyszczonymi za jednym razem. W ac14+starzenie oraz ac15+starzenie+czyszczenie wyswapowują duże (10-20 MB) kawałki za jednym razem. Trzeba jednak przyznać, że interfejs użytkownika odpowiadał cały czas, a XMMS nie przeskakiwał, ale większość z wyswapowanych 60MB w pierwszym teście w ac15+łaty wyszło z jedynie TRZECH linijek z rezultatu 'vmstat 1'. Poza tym nie było żadnego swapowania.

Po ostatnich pokręconych zmianach w podsystemie VM w jądrze Linuksa, zdecydowałem się przeprowadzić parę testów. Testy polegają na badaniu wydajności systemu plików. Pierwszy raz przeprowadziłem ten test mniej więcej rok temu z dość mizernymi wynikami, byłem więc ciekaw, jak się różne rzeczy poprawiły.

Dobra wiadomość -- poprawiło się. Zła wiadomość -- dalej nie jest dobrze.

Do testu użyłem serwera linuksowego, który działał jako serwer plików (wykorzystując netatalk) oraz 5 klientów macintosh. Każdy klient zapisywał 30MB plik i następnie go odczytywał. Każdy klient wykonywał te operacje 10 razy. Łączna suma przesłanych danych to 1.5GB danych zapisanych i 1.5GB danych odczytanych.

Testy zostały przeprowadzone z następującymi jądrami

2.4.10: oficjalne jądro 2.4.10
2.4.10-aa1: jądro 2.4.10 z łatą aa1 Andrei, włączając w to vm-tweaks-1
2.4.10-p: 2.4.10 z łatą wywłaszczającą jądro Roberta Love
2.4.9-ac15: ostatnie jądro Alana
2.4.9-ac15-al: 2.4.9-ac15 z łatami Rika ze starzeniem i czyszczeniem
2.4.9-ac15 nie spisało się za dobrze, ale łaty Rika pomogły rozwiązać te problemy, więc zostawiam 2.4.9-ac15 do dyskusji.

Sprzęt to jednoprocesorowy P-II 266 z 256MB pamięci i dyskami SCSI podłaczonymi do kontrolera Adapteca. Klienci i serwer byli podłączeni do switcha 100Mbit. Sprzęt nie jest rewelacyjny ale dyski i LAN są w stanie osiągnąć przepustowość 10MB/s.

W trakcie testu każdy z klientów działa na 30MB plikach. 5 klientów daje 150MB używanej przestrzeni dyskowej. Przy 256MB pamięci, wszystkie pliki się w niej mieszczą. Nie sądzę, aby to był realistyczny test serwera plików, ponieważ, jeśli wszystkie pliki na serwerze plików mieszczą się w pamięci, oznacza to, że jest tej pamięci za dużo :-).

Tak więc do wszystkich testów, oprócz bazowego testu, pamięć serwera została przy pomocy LILO ograniczona do 128MB.

Cechy serwera plików, które uważam za istotne to przede wszystkim szybkość serwerowania plików. Ale także sprawiedliwość przy obsłudze klientów powinna zapewnić mniej więcej równy podział przepustowości. Tak więc we wszystkich testach podaję czas zakoñczenia ostatniego klienta, który określa całkowitą szybkość działania, a także czas zakoñczenia działania pierwszego klienta, który nie powinien być wiele wcześniejszy niż ostatniego klienta.

Podsumowanie wyników
======================

W bazowym teście z 256MB pamięci, wszystkie jądra sprawiały się bez zarzutu. Mniej więcej 10MB/s przepustowości było sprawiedliwie rozdzielone pomiędzy klientów.

W rzeczywistych testach z 128MB pamięci nie było już tak różowo. Wszystkie jądra działały podobnie, ale żadne zadowalająco. Problem, który zaobserwowałem polegał na tym, że wszyscy klienci w pewnym momencie zaczynali dostawać dane z mniejszą szybkością - jedynie kilku MB/s łącznie na wszystkich maszynach. Towarzyszyło temu głośne jeżdżenie po dysku (tak było słychać). Potem jeden z klientów stał się ,,wybrañcem''. Ten klient uzyskali pełne 10MB/s pasma, a pozostałe były w tym czasie głodzone. Ten klient doszedł tak do koñca, podczas gdy pozostałe były na początku pracy. Gdy ten klient skoñczył, dysk zaczał pracować jak szalony przez kilka chwil ograniczając znacznie transfer, dopóki kolejny klient nie stał się ,,wybrañcem''. Taka sytuacja trwała do momentu, gdy zostało 2-3 klientów, a pliki zaczęły się w całości mieścić w pamięci.

Ogólnie, całkowita szybkość działania nie jest taka zła, ale fakt, że jest to osiągane przez obsługę jednego klienta na raz, przy jednoczesnym głodzeniu innych jest niedopuszczalny w serwerze plików.

Uwaga: to nie jest dokładny test w tym sensie, że czasy wykonania nie są raczej powtarzalne. To znaczy, że nie bardzo można ich wykorzystać do cyzelowania jądra. Ale w tej chwili nie skupiam się na podrasowywaniu, ale na wielkiej, otwartej dziurze w wydajności serwowania plików w Linuksie. Przypuszczalnie, takie niepowtarzalne wyniki same w sobie stanowią problem. Z lepiej dostrojonym jądrem wyniki byłby znacznie bardziej powtarzalne.

Szczegółowe wyniki
===============

Tu są czasy działania testów dla różnych jąder. Czasy są w formacie minuty:sekundy. Każdy test przeprowadziłem dwa razy. Wyniki vmstat 5 są dostępne pod adresem http://tltsu.anu.edu.au/~robert/linux_logs/ Jednak żaden z wyników vmstata nie pokazywał problemów. Żadne jądro nie używało zbytnio swapa. I nie widziałem żadnych problemów z demonami takimi jak kswapd zużywającymi czas.

Test podstawowy z 256MB

Przebieg 1     Czas pierwszego 4:05       Czas ostatniego: 4:18

Uwagi: to jest najlepsza zanotowana wydajność

linux-2.4.10:
Przebieg 1     Czas pierwszego 2:15       Czas ostatniego: 5:36
Przebieg 2     Czas pierwszego 1:41       Czas ostatniego: 6:36

Linux-2.4.10-aa1
Przebieg 1     Czas pierwszego 3:38       Czas ostatniego: 8:40
Przebieg 2     Czas pierwszego 1:35       Czas ostatniego: 7:07

Uwagi: nieco gorzej niż czyste 2.4.10

Linux-2.4.10-p
Przebieg 1     Czas pierwszego 1:39       Czas ostatniego: 8:33
Przebieg 2     Czas pierwszego 1:46       Czas ostatniego: 6:10

Uwagi: wcale nie lepiej niż 2.4.10, oczywiście jądro z wywłaszczaniem nie jest polecane na serwery, ale skoro problem, który obserwowałem wynikał z niesprawiedliwego rozdzielania zasobów, to miałem nadzieję, że coś pomoże.

Linux-2.4.9-ac15-al
Przebieg 1     Czas pierwszego 2:00       Czas ostatniego: 5:30
Przebieg 2     Czas pierwszego 1:45       Czas ostatniego: 5:07

Uwagi: tu jest nieco lepiej niż w 2.4.10 w tym sensie, że 2 klientów naraz staje się ,,wybrañcami'' i koñczą wcześniej niż kolejnych 2 itd.

Analiza
========

W bazowym teście z 256MB, ponieważ wszystkie pliki mieszczą się w pamięci, nie ma żadnego odczytu. Tylko zapis. VM zdaje się obsługiwać tę sytuację poprawnie.

W testach z 128MB mieliśmy zarówno odczyty, jaki i zapisy, ponieważ różnie rzeczy były wyrzucane z cache'u stron. VM nie radzi sobie z tym za dobrze. Symptom rzężenia dyskiem, który zaobserwowałem podczas testów, wiążę z kiepską wydajnością windy (ang. elevator). Jeśli winda nie grupuje wystarczająco żądañ, dostajesz zachowanie dysku takie: ,,mały odczyt, szukanie, mały odczyt, szukanie'', zamiast grupowania rzeczy w większe kawałki przy jednym odczycie, bądź kilkukrotnych odczytów pomiędzy szukaniem.

Problem, gdy jeden klient dostaje całą szerokość pasma musi być związany z jakąś blokadą. Normalnie podejrzewałbym, że zablokowany proces zostanie wyswapowany, ale w tym przypadku swap nie jest w ogóle używany. Przypuszczam, że strony procesów klientów mogły zostać zapisane, aby dostać wolne miejsce na cache stron. Ale to zaowocowałoby wzrostem rozmiaru cache'u stron w vmstat. A tak się nie dzieje.

Sądzę, że, jak na ironię, jest to związane ze zbyt agresywnym sortowaniem żądañ przez windę. Wszystkie dane plików dla procesów, które są zablokowane, muszą zostać wzięte z cache'u stron i zapisane, i zablokowany proces nie może pobrać wystarczająco dużo danych, aby zanotować jakikolwiek postęp. Operacje dyskowe dla ,,dobrego'' procesu przebiegają wystarczająco szybko, aby zajmować dysk i są przesortowywane na górę windy, ponieważ są blisko obecnej pozycji głowicy. I nikt inny nie jest w stanie zanotować żadnego postępu.

Były sugestie, że problemy mogą być specyficzne dla netatalk. Nie byłem jednakże w stanie znaleźć niczego, co by wskazywało, że netatalk robi coś dziwnego. Strace'owanie procesów serwera plików pokazuje, że są wykonywane po prostu odczyty i zapisy bloków 8KB. Pliki nie są otwierane O_SYNC, a proces serwera plików nie wykonuje żadnych odwołañ do fsync. Tym bardziej, że to wszystko działa dobrze przy 256MB pamięci.

Nie byłem w stanie znaleźć jakiegoś niesieciowego testu, który pokazałby te same problemy. Testy takie jak 5 równoczesnych bonnie czy tiotest z 5 wątkami niewątpliwie robią to samo, ale nie byłem w stanie zauwazyć podobnych problemów.

W tej chwili uważam, że przyczyna tkwi w tym, że skoro 5 klientów walczy o pasmo sieci, to pakiety od każdego klienta przychodzą przemieszane. Więc ziarnistość operacji, które wykonuje serwer jest w porządku. W lokalnym teście, takim jak 5 bonnies, każdy proces dostaje pełny kawałek czasu do dostępu do swojego pliku, zanim następny plik zostanie obsłużony. To prowadzi do większej ziarnistości. Sądzę zatem, że zmodyfikowana wersja tiotest, która wykonuje sched_yeild po każdej operacji zapisu lub odczytu może mieć identyczne problemy. Nie sprawdziłem jednak jeszcze tej teorii.

W Linuksie 0.01 jest błąd w sortowaniu żądañ dysku - jeśli w momencie wystąpienia przerwania sortowanie jest włączone, procedura przerwañ nie wyczyści do_dh - i tak dysk będzie zablokowany na zawsze.

W funkcji add_request również brakuje zabezpieczeñ pamięci - kompilator mógłby zmienic porządek wpisów do zmniennych i wpisów do kolejki żądañ - tworząc wyścig.

Cóż, IIRC, Alan i DaveM byli głównymi opiekunami 1.2.x z różnymi łatkami -ac i "ISS" (dodatkowe punkty dla tego, kto pamięta, co "ISS" oznaczało). Prawdopodobnie gdzieś mam jakieś łatki do 1.2.13...

Co do 1.0.9, w którymś momencie, lata temu, uaktualniłem je (cf. linux-lite), aby dało się kompilować z "nowym" gcc-2.7.2, kiedy RAM kosztował wielkie $$$ - nie wyobrażam sobie, aby ktokolwiek od tamtej pory tego dotykał.

$ ls -l date

-rwxr-xr-x   1 root     root        13624 Sep  4  1992 date

$ ldd ./date

        /lib/libc.so.4 (4.0)

$ ./date
Thu Sep 27 15:58:19 EDT 2001
$

łoooo! :) Gdybym tak miał Decwritera dla konsoli szeregowej...

Możesz spróbować przeczytać archiwa listy dyskusyjnej z 1991 i początku 1992 roku:

http://www.kclug.org/old_archives/linux-activists/

Zmontowałem podsumowanie kilku ciekawszych wcześniejszych listów z 1991 i początków 1992 roku do pisanej przeze mnie ksiązki o historii komputerów...

http://penguicon.sourceforge.net/comphist/1991.html

http://penguicon.sourceforge.net/comphist/1992.html

Lista z późnego 1993->95 jest zarchiwizowana na

http://www.linux.org.uk/Old-LK/Old-linux-kernel

Nie wiem teraz, czy reszta 1992-> późnego 1993 istnieje

Archiwa kclug utrzymują, że sięgają drugiego tygodnia października 1993 roku. Jeszcze nie przegryzłem się przez nie tak daleko.

http://www.kclug.org/old_archives/linux-activists/

Nie wykorzystujcie ich, proszę, ZBYTNIO, wydaje mi się, że są na linii ISDN lub czymś podobnym...

(Powodem ograniczenia poszukiwañ do połowy 1992 jest fakt, że wtedy dotyczyły już 0.95, 0.01 nie było więc aktualne...)

Największym problemem jest zapewnienie, że serwer pozbędzie się wszystkich wątków, gdy klient będzie zapchany.

W kodzie UDP używamy nieblokującego wy/we i po prostu ignorujemy wszystkie odpowiedzi, które nie przeszły. Dla TCP ignorowanie odpowiedzi nie będzie dobre, jako że klient będzie przysyłał ponownie żądanie co ~60 sekund. Obecnie kod używa blokującego we/wy czyli, że jeśli gniazdo się blokuje, zaczyna brakować wolnych wątków nfsd...

Są dwa możliwe sposoby postępowania:

1. Alokowanie jednego wątku na każde połączenie TCP
2. Użycie nieblokującego wy/we, pozwolenie połączeniom TCP odłożenia na później odpowiedzi i poczekanie aż gniazdo będzie dostępne (i pozwolenie wątkowi obsłużyć inne żadąnia podczas, gdy gniazdo jest zajęte).

Zacząłem pracę nad (2) zeszłej jesieni, ale nie miałem czasu zrobić dużo od tamtej pory. Jednakże jest to na mojej liście priorytetów w 2.5.x, więc jeśli nikt inny nie będzie chciał tym brudzić rąk to wrócę...

Wydaje mi się bardzo zawstydzającym fakt, że podstawowe sterowniki takie jak aic7xxx, emu10k1, tulip, itp. regularnie nie działają w jądrach głównej linii. Nie miałem żadnych kłopotów z takimi rzeczami w Windows od paru lat... Oczywiście sterowniki dla Windows są parę procent wolniejsze, ale jak raz napisał Nathan Myers, ,,Nie ma sensu porównywać efektywności jednego systemu z drugim, który może wykonywałby pewne operacje szybciej, gdyby tylko się nie wywalał.''

Myślę, że główne podziękowania winni jesteśmy Alanowi Coksowi, który najbardziej stara się utrzymać porządek w domu, wśród chaosu w jakim rozwija się jądro (chwała panu Coksowi za wystarczająco długie, aż do uzyskania stabilności, utrzymywanie obsługi pamięci wirtualnej autorstwa Rika)

Następujący bardzo prosty program ilustruje taką sytuację:

#include <unistd.h>
int main()
{

char buf[512];
while (read(0, buf, sizeof(buf)) == sizeof(buf));
return 0;

}

Program powinien czytać z urządzenia blokowego, ale wielki plik prawdopodobnie spowoduje to samo.

./a.out < /dev/hde1

Podczas działania programu wszystkie strony w cache ustawiają się na liście stron aktywnych, a kiedy pamięć jest wypełniona stronami aktywnymi, komputer zaczyna te strony usuwać z pamięci, w tym czasie właściwie przestaje odpowiadać, a po około pół minuty okazuje się, że brakuje mu pamięci (OOM) i zaczyna zabijać procesy. W tym czasie jest całe mnóstwo wolnej przestrzeni wymiany. W logach pojawiło się także sporo błędów typu nieudana alokacja rzędu zero.