Potężny stracemnie zawiódł. Jak to jest możliwe?
time foopokazuje, że foouruchomienie zajmuje kilka sekund („rzeczywisty”), ale zużywa nieznaczny czas procesora, zarówno w przestrzeni użytkownika („użytkownik”), jak i w jądrze („sys”). Dla ciekawskich foozdefiniowano poniżej.
Dlatego spędza większość czasu czekając na coś innego, nie wykonując instrukcji procesora. Zwykle widzę, jak czeka strace- tzn. Jakie wywołanie systemowe blokuje przez długi czas. Niestety takie podejście nie zadziałało.
strace -ttt -T -C -w foopokazuje wywołania systemowe, znaczniki czasu oraz podsumowanie (rzeczywistego) czasu spędzonego na wywołaniach systemowych. Ale ten szczególny proces pokazał, że spędzanie nieistotnego czasu (w czasie rzeczywistym) wewnątrz wywołań systemowych.
foojest właściwie journalctl -b -u dev-hugepages.mount. Tyle że musiałem za każdym razem zmieniać ostatni argument na inną jednostkę systemową, aby to odtworzyć. Innymi słowy, opóźnienie, które badam, zdarzyło się po raz pierwszy, gdy próbuję uzyskać dzienniki dla dowolnej jednostki systemowej. EDYCJA : po udzieleniu odpowiedzi na główne pytanie, zdałem sobie również sprawę z tego, dlaczego miałem problem z odtworzeniem opóźnienia .
Czas spędzony przez ten proces jest szczególnym problemem, najwyraźniej nie występuje we wszystkich systemach. https://github.com/systemd/systemd/issues/7963
journalctldziała tylko jeden proces. Mam wrażenie, że journalctlużywa jednego dodatkowego wątku z jakiegokolwiek powodu - iirc była jedna rozmowa clone (). Myślę, że oznacza to, że masz techniczną rację, ale jest to również technicznie nieistotne dla pytania. timepatrzy na proces jako całość i wykazał, że proces jako całość jest raczej senny (blokuje na czymś). stracenie pokazał wystarczającej ilości snu. Nie ma znaczenia, czy śpi drugi wątek, główny wątek również musi być bardzo śpiący, aby wyjaśnić timewynik.