r   e   k   l   a   m   a
r   e   k   l   a   m   a

Im więcej rdzeni tym gorzej: Windows 10 zacina się przy poważnej pracy

Strona główna AktualnościOPROGRAMOWANIE

Bruce Dawson, autor bloga Random ASCII, używa niezłego komputera. 24 rdzenie, 48 wątków, 64 GB RAM, szybki dysk SSD. Można by się było spodziewać, że nawet poważna praca na takiej maszynie, np. kompilowanie przeglądarki Chrome, będzie przebiegać błyskawicznie. Tymczasem gdy rozpoczynała się kompilacja, system zamierał, Dawsonowi przycinał się nawet wskaźnik myszy. I to wcale nie dlatego, że zabrakło rdzeni. Zawinił Windows 10.

Gdyby jeszcze rdzenie były obciążone w 100%, problem byłby zrozumiały. Sęk w tym, że analiza obciążeń za pomocą tracera ETW pokazała, że obciążenie pojedynczego rdzenia rzadko kiedy przekraczało 50%. Musiało chodzić o coś innego – problem tkwił w samym systemie.

Przyglądając się zachowaniu procesów, szybko tworzonych i niszczonych w takich związanych z kompilacją obciążeniach roboczych, programista zauważył, że znaczna ich część zostaje zablokowana na 200 mikrosekund przez funkcję NtGdiCloseProcess, należącą do zintegrowanego z kernelem podsystemu GDI (Graphics Device Interface).

r   e   k   l   a   m   a

W testowanym okresie zamrożenia interfejsu użytkownika na 1,125 sekundy, okres oczekiwania dla wszystkich wątków wyniósł łącznie ponad 63 sekundy. Z tego okresu 1,125 sekund 95% czasu spędzane było wewnątrz NtGdiCloseProcess – najwyraźniej wąskim gardle Windowsa.

Stąd też całe wyczekiwanie systemu, gdy tysiące procesów zamykanych procesów walczyły o jedną blokadę w NtGdiCloseProcess, zamrażając aktywność interfejsu użytkownika, a im dłużej komputer pracował, tym sytuacja była gorsza – jak pokazuje Dawson, po restarcie problem nie był tak dotkliwy.

Programista przygotował więc testowy program, który tworzył tak szybko jak możliwe tysiące procesów, czekał pół sekundy, a następnie nakazywał wszystkich tych procesów jednoczesne zamknięcie. Program ten został uruchomiony na słabszych komputerach – czterordzeniowym, ośmiowątkowym laptopie z Windowsem 10, oraz starym dwurdzeniowym komputerze z Windows 7. Porównanie pokazało coś zaskakującego: na tej starej maszynie tworzenie procesów było oczywiście znacznie powolniejsze, ale ich niszczenie było tak szybkie, jak tylko możliwe, odbywało się w pełni równolegle.

Gdzieś między Windowsem 7 a Windowsem 10 doszło więc w tym systemie do regresji, w wyniku której NtGdiCloseProcess stało się wąskim gardłem, tym węższym, im potężniejsza jest maszyna. Jak bowiem podkreśla Dawson, środowisko kompilacji Chrome uruchamia tym więcej procesów, im więcej mamy rdzeni, a to oznacza więcej procesów rywalizujących o tę funkcję.

Odkrycie trafiło do Microsoftu, który zapowiedział, że zbada problem. Póki co, mamy do czynienia z podręcznikowym wręcz przykładem prawa Amdahla, które mówi, że im więcej rdzeni stosowanych jest do wykonania programu, w tym większym stopniu na czas wykonania wpływają te fragmenty kodu, których nie można wykonać równolegle. Dawson pisze: to nie jest po prostu „mam 24-rdzeniowe CPU i nie mogę ruszyć myszą”, ale „mam 24-rdzeniowe CPU i dlatego nie mogę ruszyć myszą”.

Szczegóły analizy i linki do wykorzystanych narzędzi znajdziecie na blogu Random ASCII.

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.   

Trwa konkurs "Ogól naczelnego", w którym codziennie możecie wygrać najnowsze maszynki systemowe Hydro Connect 5 marki Wilkinson Sword.

Więcej informacji

Gratulacje!

znalezione maszynki:

Twój czas:

Ogól Naczelnego!
Znalazłeś(aś) 10 maszynek Wilkinson Sword
oraz ogoliłaś naszego naczelnego!
Przejdź do rankingu
Podpowiedź: Przyciśnij lewy przycisk myszki i poruszaj nią, aby ogolić brodę.