Historia: W wczesnych wersjach Go, blokujące wywołania systemowe bezpośrednio blokowały działający wątek OS, uniemożliwiając mu uruchamianie innych goroutines. To prowadziło do szybkiego zwiększania liczby wątków pod dużym obciążeniem, co skutkowało wyczerpaniem pamięci i „działaniami harmonogramu” w miarę, jak runtime generował nieograniczoną liczbę wątków, aby zapewnić postęp.
Problem: Kiedy goroutine wywołuje operację blokującą (np. operacje na plikach), podlegający wątek OS wchodzi w przestrzeń jądra i nie może wykonać innych goroutines aż do zakończenia wywołania systemowego. Bez interwencji, harmonogram musiałby uruchamiać nowe wątki, aby utrzymać współbieżność, naruszając „lekką” architekturę współbieżności Go i pogarszając wydajność z powodu narzutu przełączania kontekstu i obciążenia pamięci.
Rozwiązanie: Runtime Go wykorzystuje mechanizm przekazywania. Kiedy goroutine wchodzi w blokujące wywołanie systemowe, runtime.entersyscall odłącza jego Processor (P) — logiczny zasób CPU — i oddaje wątek. P natychmiast planuje inną goroutine, zapobiegając głodzeniu. Oryginalny wątek wykonuje wywołanie systemowe. Po zakończeniu, runtime.exitsyscall próbuje ponownie przejąć oryginalne P; jeżeli jest niedostępne, goroutine przechodzi do globalnej kolejki uruchamiania lub kradnie inne P, co zapewnia efektywne ponowne użycie wątków bez nieograniczonego wzrostu.
// Ta operacja na pliku automatycznie uruchamia mechanizm przekazywania wywołania systemowego func ProcessLogFile(path string) error { // W tym momencie wywoływana jest runtime.entersyscall // P jest przekazywane innej goroutine podczas blokady tego wątku data, err := os.ReadFile(path) if err != nil { return err } // Po powrocie wywoływana jest runtime.exitsyscall // Goroutine jest ponownie planowane na dostępne P processData(data) return nil }
Prowadziliśmy wysokowydajną usługę agregacji logów przetwarzającą miliony zdarzeń na sekundę. Każda goroutine wykonywała intensywne operacje parsowania CPU, a następnie atomowe zapisy na dysku za pomocą os.WriteFile. Pod obciążeniem usługa wykazywała błędy OOM, mimo niskiego użycia sterty i efektywnej zbiórki śmieci.
Analiza problemu: pprof i metryki runtime ujawniły, że proces wygenerował ponad 50 000 wątków OS, z których każdy był zablokowany na operacjach dyskowych. Domyślny limit wątków (10000) został przekroczony, co spowodowało głodzenie goroutines i kaskadowe przekroczenia czasu w całej siatce mikroserwisów.
Rozwiązanie A: Buforowane I/O z pulą roboczą z ograniczeniem semaforowym: Rozważaliśmy wdrożenie stałej puli roboczej z buforowanymi kanałami, aby ograniczyć jednoczesny dostęp do dysku do stu równoczesnych operacji. To podejście zapewniało przewidywalne wykorzystanie zasobów i opóźnienia, ale wprowadzało skomplikowaną logikę sterowania przepływem, potencjalne zakleszczenia podczas zamykania oraz skutecznie łamało naturalny model współbieżności Go poprzez dodanie ręcznego zarządzania semaforami, które runtime powinien obsługiwać.
Rozwiązanie B: Asynchroniczne I/O za pomocą raw epoll: Rozważaliśmy użycie syscall.RawSyscall z nieblokującymi deskryptorami plików i integrację z netpollerem. Choć wydajne dla gniazd, Linux nie wspiera prawdziwego asynchronicznego I/O przez epoll jednorodnie we wszystkich systemach plików, wymagając skomplikowanego zarządzania pulą wątków dla operacji dyskowych. To skutkowało w praktyce ponownym wdrażaniem strategii wywołania systemowego runtime z większymi kosztami i mniejszą niezawodnością.
Rozwiązanie C: Zaufaj runtime przy dostrajaniu architektonicznym: Zdecydowaliśmy się wykorzystać istniejące obsługi wywołań systemowych Go, optymalizując nasze wzorce I/O. Tymczasowo zwiększyliśmy debug.SetMaxThreads jako wentyl bezpieczeństwa, przeszliśmy na bufio.Writer, aby zmniejszyć częstotliwość wywołań systemowych dzięki buforowaniu i wdrożyliśmy wykładnicze opóźnienie dla logiki ponownych prób. To pozwoliło mechanizmowi entersyscall/exitsyscall runtime działać poprawnie bez eksplozji wątków, poprzez zmniejszenie częstości blokujących wywołań.
Rezultat: Liczba wątków ustabilizowała się poniżej 1000 podczas szczytowego obciążenia, błędy OOM całkowicie ustały, a wydajność zwiększyła się o 40% z powodu zmniejszenia narzutu przełączania kontekstu. Usługa teraz radzi sobie ze wzrostami ruchu bez problemów, pozwalając harmonogramowi na multiplikację goroutines w dostępnej puli wątków podczas oczekiwania na I/O, dokładnie tak, jak zaprojektowano to w runtime Go.
1. Dlaczego blokowanie na kanale nie zużywa wątku OS, podczas gdy blokowanie na odczycie z pliku to robi, i jak runtime rozróżnia te stany?
Blokowanie na kanale to zarządzana zmiana stanu goroutine całkowicie w przestrzeni użytkownika. Runtime parkuje goroutine (oznacza ją jako czekającą) za pomocą gopark, natychmiast ponownie planuje wątek OS, aby uruchomić inną goroutine z lokalnej kolejki uruchamiania P, a wątek nigdy nie wchodzi w przestrzeń jądra. Z drugiej strony, odczyt z pliku wchodzi w przestrzeń jądra za pośrednictwem wywołania systemowego. Runtime wywołuje runtime.entersyscall, co informuje harmonogram, że ten wątek będzie niedostępny przez nieokreślony czas, co prowadzi do natychmiastowego przekazania P w celu zapobieżenia głodzeniu CPU. Różnica leży w parkowaniu w przestrzeni użytkownika (kanał) versus delegacji w przestrzeni jądra (wywołanie systemowe).
2. Jaki katastrofalny tryb awarii występuje, gdy przed blokującym wywołaniem systemowym wywołuje się runtime.LockOSThread(), i dlaczego pomija to mechanizm multiplikacji?
runtime.LockOSThread() wiąże goroutine z jej aktualnym wątkiem OS na czas trwania blokady. Jeśli zablokowana goroutine wykonuje blokujące wywołanie systemowe, wątek nie może odłączyć swojego P, ponieważ umowa związku wymaga, aby ten konkretny wątek wykonywał tę konkretną goroutine. P skutecznie znika z puli harmonogramu, aż wywołanie systemowe się zakończy. Jeśli wiele zablokowanych goroutines zablokuje się równocześnie, aplikacja traci całkowicie równoległość, potencjalnie prowadząc do zakleszczenia, jeśli zablokowane operacje zależą od innych goroutines, które nie mogą być zaplanowane z powodu braku dostępnych Ps.
3. Jak wykonanie CGO wchodzi w interakcję z mechanizmem entersyscall, i dlaczego nadmierne wzorce wywołań CGO powodują podobne wyczerpanie wątków co blokujące wywołania systemowe?
CGO wywołania są przez runtime traktowane jako operacje blokujące. Gdy Go wywołuje kod C, wywoływana jest runtime.entersyscall, zwalniając P w celu zapobieżenia głodzeniu. Jednak CGO działa na osobnym stosie systemowym i wymaga, aby wątek OS przeszedł do kontekstu wykonania C. Jeśli kod C wykonuje operacje blokujące lub działa przez dłuższy czas, wątek OS pozostaje zajęty. W przeciwieństwie do czystych wywołań systemowych Go, wywołania CGO nie wspierają "szybkiej ścieżki" powrotu, w której goroutine mogłaby kontynuować na tym samym wątku bez kolejkowania. Nadmiar wywołań CGO może wyczerpać pulę wątków, ponieważ każde wywołanie wiąże kombinację wątek-stos, a harmonogram może generować nowe wątki, aby obsłużyć inne goroutines, prowadząc do tej samej eksplozji wątków, co nieobsługiwane blokujące wywołania systemowe.