Czym różnią się wycieki deskryptorów plików od prawidłowych szczytów połączeń na serwerze domowym?

Uzasadniony szczyt deskryptorów plików rośnie wraz z aktywnymi połączeniami lub otwartą pracą i spada po jej zakończeniu. Wyciek deskryptorów utrzymuje zasoby otwarte po tym, jak aplikacja ich już nie potrzebuje, więc licznik rozwija rosnącą linię bazową, która ostatecznie osiąga limit procesu, usługi, kontenera lub systemu.

Rozróżnienie jest ważne, ponieważ oba warunki mogą powodować ten sam ostateczny błąd. Podniesienie limitu deskryptorów może być prawidłowym planowaniem pojemności dla ruchliwego serwera proxy, ale tylko opóźnia awarię, gdy gniazda, pliki, rury lub obserwatory nigdy nie są zwalniane.

Jaki wzór definiuje uzasadniony szczyt deskryptorów?

Normalny szczyt podąża za współbieżnością obciążenia. uzasadnione szczyty odzwierciedlają aktywne obciążenie, a następnie spadają, gdy żądania się kończą, gniazda zamykają, procesy kończą działanie, a pliki tymczasowe są zwalniane.

Linia bazowa przed i po zdarzeniu pozostaje podobna. Okno kopii zapasowej, nagły strumień multimedialny lub wielu jednoczesnych klientów sieciowych może wygenerować wysoki licznik bez wskazywania na błędne zarządzanie zasobami.

Szczyt powinien również korelować z zakończoną pracą. Jeśli dwukrotnie więcej klientów tworzy mniej więcej dwukrotnie więcej aktywnych gniazd, a licznik wraca do normy po tym, system pokazuje zapotrzebowanie na skończoną pojemność, a nie trwałą utratę.

Jaki wzór wskazuje na wyciek deskryptorów?

Wycieki zmieniają linię bazową, a nie tylko maksimum. wycieki utrzymują otwarte deskryptory po zakończeniu pracy, więc każdy cykl żądania, ponowne połączenie, przeładowanie lub nieudana operacja pozostawia za sobą pewne zasoby.

Licznik może rosnąć na tyle powoli, że pozostaje niewidoczny podczas krótkich testów. Usługa może wyglądać na zdrową przez godziny lub dni, aż pozostały zapas deskryptorów stanie się zbyt mały dla kolejnego połączenia lub otwarcia pliku.

Ponowne uruchomienie procesu resetuje licznik, ponieważ jądro zamyka jego deskryptory, ale to odzyskanie nie dowodzi, że podstawowy problem został rozwiązany. Ten sam nachylenie pojawia się ponownie, gdy usługa zaczyna ponownie obsługiwać zadania.

Dlaczego gniazda, pliki i obserwatory generują różne wykresy?

Linux używa deskryptorów dla kilku typów zasobów I/O, a różne typy zasobów tworzą różne wzorce wzrostu. Każdy typ wymaga więc innego wyjaśnienia obciążenia.

Gniazda klienta powinny podążać za równoczesnymi sesjami. Pliki dziennika lub multimediów powinny podążać za aktywnymi uchwytami. Potoki mogą podążać za procesami potomnymi, podczas gdy deskryptory związane z obserwatorem mogą pozostać stabilne, mimo że liczba obserwowanych ścieżek rośnie przez osobny limit jądra.

Klasyfikacja deskryptorów według celu jest bardziej użyteczna niż odczyt jednej sumy. Setki oczekiwanych gniazd podczas nagłego wzrostu ruchu różnią się od stale rosnących usuniętych plików dziennika lub powtarzających się połączeń do jednej niedostępnej zależności.

Dlaczego podniesienie limitu opóźnia wyciek zamiast go naprawić?

Błąd `Too many open files` pojawia się tylko, gdy wzrost osiąga limit. wyższe limity tylko odkładają wyczerpanie wycieku.

Wyższy limit wydłuża czas między restartem a awarią. Może to sprawić, że usługa będzie wydawać się naprawiona podczas krótkiego okna obserwacji, jednocześnie pozwalając wyciekowi zużywać więcej pamięci jądra oraz więcej stanu sieci lub pamięci masowej.

Zmiany pojemności powinny zatem podążać za dowodami, że deskryptory są zwalniane normalnie. W przeciwnym razie nowy limit to większa przestrzeń awarii, a nie poprawa stabilności.

Które pomiary oddzielają pojemność od awarii cyklu życia?

Całkowita liczba to tylko pierwszy sygnał. wiek i typ deskryptora ujawniają przyczynę źródłową. Śledź liczbę, typ celu, czas otwarcia, tempo tworzenia, tempo zamykania, ruch i zakończone żądania na tej samej osi czasu.

Dla szczytu liczba deskryptorów powinna zmieniać się wraz z równoczesnością i ostatecznie wrócić do normy. W przypadku wycieku czas otwarcia i wzrost linii bazowej rosną, podczas gdy ilość aktywnej użytecznej pracy nie zwiększa się proporcjonalnie.

Porównuj wiele cykli zamiast jednego migawki. Pojedyncza wysoka liczba nie może pokazać, czy proces jest blisko szczytu normalnej fali, czy w trakcie trwałego trendu wzrostowego.

Kiedy wyższy limit deskryptorów jest faktycznie uzasadniony?

ponowne użycie połączeń zmniejsza zapotrzebowanie na prawidłowe deskryptory. Przed zwiększeniem limitów usuń możliwą do uniknięcia rotację połączeń, ogranicz pule i potwierdź, że zasoby zamykają się po zakończeniu pracy.

Większy limit jest uzasadniony, gdy testowana prawidłowa współbieżność zbliża się do obecnego efektywnego limitu usługi, liczby deskryptorów wracają do linii bazowej, a pamięć, bufory gniazd, pule backendowe i zachowanie odzyskiwania mogą obsłużyć większe zapotrzebowanie.

Ustaw alerty poniżej punktu twardej awarii i zachowaj zapas administracyjny. Celem nie jest uczynienie limitu nieosiągalnym; chodzi o utrzymanie normalnych szczytów w zmierzonym zakresie operacyjnym przy jednoczesnym wczesnym wykrywaniu nieprawidłowego wzrostu.

Najczęściej zadawane pytania

Czy wyciek deskryptora pliku może wystąpić przy niskim zużyciu CPU?

Tak. Proces może zatrzymać gniazda lub pliki podczas oczekiwania i zużywać prawie żadnego CPU, aż nowa alokacja się nie powiedzie.

Czy TIME_WAIT dowodzi wycieku deskryptora?

Nie. TIME_WAIT to stan jądra TCP po zamknięciu gniazda. Wyciek deskryptora oznacza, że aplikacja nadal trzyma otwarty deskryptor.

Dlaczego ponowne uruchomienie usługi wydaje się to naprawiać?

Zakończenie procesu zamyka jego deskryptory i przywraca zapas. Jeśli cykl życia aplikacji pozostaje uszkodzony, liczba zaczyna ponownie rosnąć.

Czy alerty powinny używać stałej liczby deskryptorów?

Używaj zarówno procentu efektywnego limitu, jak i zachowania wzrostu. Stabilna wysoka liczba może być normalna, podczas gdy niższa, ale stale rosnąca liczba może być niebezpieczna.

Ostateczne wnioski

Prawidłowe szczyty deskryptorów pojawiają się po aktywnej pracy i wracają do stabilnej linii bazowej. Wycieki zatrzymują zasoby po zakończeniu pracy, tworząc rosnącą podłogę, która ostatecznie przekracza określony limit. Diagnozuj krzywą, typ zasobu i wiek deskryptora przed podniesieniem limitów, ponieważ dodatkowy zapas wspiera rzeczywistą pojemność tylko wtedy, gdy cykl życia jest już poprawny.