Red Hat chce zadbać o przydział zasobów dla głodzonych wątków Strona główna Aktualności31.08.2020 23:07 Red Hat chce zadbać o przydział zasobów dla głodzonych wątków (fot. Image by Pixabay) Udostępnij: O autorze Kamil J. Dudek @wielkipiec Portal Phoronix zwraca uwagę na projekt nowego demona opracowywanego przez firmę Red Hat i wkrótce gotowego do włączenia do Fedory. Jest nim stalld, wykrywacz ugrzęzłych (stalled) wątków. Ma on odpowiadać za zapewnienie zasobów umożliwiających finalizację pracy wątku i złączenie (join) z programem, celem kontynuacji przepływu. Choć intuicja podpowiada co innego (w jaki sposób kolejne narzędzie ma pomóc w rozwiązaniu braku zasobów?), demon stalld jest prosty i całkiem sensowny. Sytuacja, w której system nie potrafi zapewnić zasobów pozwalających na ukończenie wątku nie zawsze wynika ze stuprocentowego obciążenia procesora/węzła pracą. Czasami jest to problem wynikający z niuansów działania systemowego planisty (scheduler). Pewne rzeczy trudno bowiem optymalnie zaplanować: programy mogą przełączać się między rdzeniami procesora i korzystać z różnych rdzeni celem wykonywania swojej pracy, ale wątki nie mają takiej wolności. Gdy wątek rozpocznie obliczenia na jakimś rdzeniu, nie da się go tak po prostu przenieść na inny (podobnie jak nie da się w pełni swobodnie gospodarować jego pamięcią). Głodzone wątki Można więc napotkać na sytuację, w której na tym samym rdzeniu zachodzi jakaś priorytetowa praca, przez którą pozostałe wątki nie mogą nawet wystartować. Taką sytuację nazywa się głodzeniem wątku. Kombinacja odpowiednio niekorzystnych okoliczności może sprawić, że wysoki priorytet stanie się priorytetem całkowitym: żadne inne zadanie nie może wystartować, choć jest już przygotowane i zaplanowane. (kernellorg Stalld ma wykrywać takie sytuacje i wymuszać alokację ułamka czasu procesora tak, aby wątek mógł rozpocząć pracę. Takie zachowanie podważa "autorytet" systemowego planisty, nie zmieniając jednocześnie priorytetów (nice) procesów. Linuksowy planista nie jest wystarczająco elastyczny, by rozwiązać ten problem bez poważnego przeprojektowania, stąd też może zachodzić potrzeba innego rozładowania rosnącej kolejki zadań. Zaawansowana kontrola zasobów Stalld, aby pracować wydajnie, musi być przywiązany do rdzenia nieobarczonego pracą. Zatem poprawne jego wdrożenie wymaga świadomego zarządzania zasobami i zaawansowanej alokacji zasobów. W wielu takich czynnościach może pomagać systemd i jego mechanizm slices. Być może jednak stalld nie każdemu będzie potrzebny. Jeżeli specyfika zastosowania maszyny nie prowadzi do zakleszceń będących efektem głodzenia CPU, stalld się nie przyda. man sched_setscheduler Wreszcie, nie zawsze problemy z zagłodzeniem wątków brakiem CPU wynikają z łakomych zadań o wysokim priorytecie. O czas procesora mogą nie móc "doprosić się" na przykład maszyny wdrożone na niezoptymalizowanym hipernadzorcy. Osiem maszyn na ośmiordzeniowym serwerze wirtualizacji, w przypadku wyższego obciążenia może często nie otrzymywać czasu potrzebnego na niektóre zadania, co doprowadzi do zakleszczeń. Optymalizowanie dostępności (availability, nie accessibility) wykracza dziś, jak widać, daleko poza klasycznego planistę opisywanego w książkach o projektowaniu systemów operacyjnych. W sytuacjach, gdy automatyczny load-balancing zawodzi, z pomocą przychodzą właśnie takie cudaczne pomysły, jak stalld. Można się z nim zapoznać na repozytorium Git projektu kernel.org. To ciekawa odmiana po dziesiątkach nowości rozwijanych pod egidą freedesktop. Oprogramowanie IT.Pro Udostępnij: © dobreprogramy Zgłoś błąd w publikacji Zobacz także Homed: od teraz systemd potrafi zarządzać także katalogami domowymi 31 sty 2020 Kamil J. Dudek Oprogramowanie IT.Pro 74 Komputery Lenovo ThinkStation i laptopy ThinkPad w 100 proc. gotowe na Linuksa 9 cze 2020 Piotr Urbaniak Oprogramowanie Sprzęt 170 Red Hat, OpenShift i bezpieczeństwo. Kiedy proste staje się zbyt proste? 19 kwi 2020 Kamil J. Dudek Oprogramowanie Bezpieczeństwo IT.Pro 29 Wydano nowy systemd. Do twórców dołącza Microsoft 31 lip 2020 Kamil J. Dudek Oprogramowanie Bezpieczeństwo IT.Pro 74
Udostępnij: O autorze Kamil J. Dudek @wielkipiec Portal Phoronix zwraca uwagę na projekt nowego demona opracowywanego przez firmę Red Hat i wkrótce gotowego do włączenia do Fedory. Jest nim stalld, wykrywacz ugrzęzłych (stalled) wątków. Ma on odpowiadać za zapewnienie zasobów umożliwiających finalizację pracy wątku i złączenie (join) z programem, celem kontynuacji przepływu. Choć intuicja podpowiada co innego (w jaki sposób kolejne narzędzie ma pomóc w rozwiązaniu braku zasobów?), demon stalld jest prosty i całkiem sensowny. Sytuacja, w której system nie potrafi zapewnić zasobów pozwalających na ukończenie wątku nie zawsze wynika ze stuprocentowego obciążenia procesora/węzła pracą. Czasami jest to problem wynikający z niuansów działania systemowego planisty (scheduler). Pewne rzeczy trudno bowiem optymalnie zaplanować: programy mogą przełączać się między rdzeniami procesora i korzystać z różnych rdzeni celem wykonywania swojej pracy, ale wątki nie mają takiej wolności. Gdy wątek rozpocznie obliczenia na jakimś rdzeniu, nie da się go tak po prostu przenieść na inny (podobnie jak nie da się w pełni swobodnie gospodarować jego pamięcią). Głodzone wątki Można więc napotkać na sytuację, w której na tym samym rdzeniu zachodzi jakaś priorytetowa praca, przez którą pozostałe wątki nie mogą nawet wystartować. Taką sytuację nazywa się głodzeniem wątku. Kombinacja odpowiednio niekorzystnych okoliczności może sprawić, że wysoki priorytet stanie się priorytetem całkowitym: żadne inne zadanie nie może wystartować, choć jest już przygotowane i zaplanowane. (kernellorg Stalld ma wykrywać takie sytuacje i wymuszać alokację ułamka czasu procesora tak, aby wątek mógł rozpocząć pracę. Takie zachowanie podważa "autorytet" systemowego planisty, nie zmieniając jednocześnie priorytetów (nice) procesów. Linuksowy planista nie jest wystarczająco elastyczny, by rozwiązać ten problem bez poważnego przeprojektowania, stąd też może zachodzić potrzeba innego rozładowania rosnącej kolejki zadań. Zaawansowana kontrola zasobów Stalld, aby pracować wydajnie, musi być przywiązany do rdzenia nieobarczonego pracą. Zatem poprawne jego wdrożenie wymaga świadomego zarządzania zasobami i zaawansowanej alokacji zasobów. W wielu takich czynnościach może pomagać systemd i jego mechanizm slices. Być może jednak stalld nie każdemu będzie potrzebny. Jeżeli specyfika zastosowania maszyny nie prowadzi do zakleszceń będących efektem głodzenia CPU, stalld się nie przyda. man sched_setscheduler Wreszcie, nie zawsze problemy z zagłodzeniem wątków brakiem CPU wynikają z łakomych zadań o wysokim priorytecie. O czas procesora mogą nie móc "doprosić się" na przykład maszyny wdrożone na niezoptymalizowanym hipernadzorcy. Osiem maszyn na ośmiordzeniowym serwerze wirtualizacji, w przypadku wyższego obciążenia może często nie otrzymywać czasu potrzebnego na niektóre zadania, co doprowadzi do zakleszczeń. Optymalizowanie dostępności (availability, nie accessibility) wykracza dziś, jak widać, daleko poza klasycznego planistę opisywanego w książkach o projektowaniu systemów operacyjnych. W sytuacjach, gdy automatyczny load-balancing zawodzi, z pomocą przychodzą właśnie takie cudaczne pomysły, jak stalld. Można się z nim zapoznać na repozytorium Git projektu kernel.org. To ciekawa odmiana po dziesiątkach nowości rozwijanych pod egidą freedesktop. Oprogramowanie IT.Pro Udostępnij: © dobreprogramy Zgłoś błąd w publikacji