Czytałem dokumentację próbującą zrozumieć, kiedy sensowne jest zwiększenie rozmiaru puli asynchronicznej za pomocą przełącznika + AN.Kiedy należy zwiększyć rozmiar nici asynchronicznych od zera?
Jestem doskonale przygotowany do testów porównawczych, ale zastanawiałem się, czy istnieje zasada, w której należy podejrzewać, że zwiększenie wielkości puli od 0 do N (lub od N do N + M) byłoby pomocne .
Dzięki
BEAM uruchamia kod Erlang w specjalnych wątkach, który wywołuje harmonogramy. Domyślnie uruchomi harmonogram dla każdego rdzenia procesora. Może to być kontrolowane i uruchamiane, na przykład, jeśli nie chcesz uruchamiać Erlanga na wszystkich rdzeniach, ale "zarezerwować" trochę na inne rzeczy. Zwykle podczas operacji wejścia/wyjścia pliku jest on uruchamiany w programie planującym, a operacje we/wy pliku są stosunkowo powolne, a następnie blokują ten program planujący, gdy są uruchomione. Które mogą wpływać na właściwości w czasie rzeczywistym. Zwykle nie wykonujesz zbyt wielu operacji wejścia/wyjścia pliku, więc nie stanowi to problemu.
Asynchroniczna pula wątków to wątki systemu operacyjnego używane do operacji we/wy. Zwykle pula jest pusta, ale jeśli korzystasz z +A podczas uruchamiania, to BEAM utworzy dodatkowe wątki dla tej puli. Te wątki będą używane tylko do operacji we/wy pliku, co oznacza, że wątki programu planującego nie będą już blokować oczekiwania na operacje we/wy pliku i poprawione zostaną właściwości w czasie rzeczywistym. Oczywiście koszty te, jak wątki systemu operacyjnego, nie są darmowe. Wątki nie mieszają się, więc wątki programu planującego są po prostu wątkami programu planującego, a wątki asynchroniczne są po prostu wątkami asynchronicznymi.
Jeśli piszesz połączone sterowniki dla portów, mogą one również korzystać z puli wątków asynchronicznych. Ale musisz sam wykryć, kiedy zostały uruchomione.
Ile trzeba, zależy od zastosowania. Domyślnie żadne nie są uruchamiane. Podobnie jak w @demeshchuk słyszałem również, że Riak lubi mieć dużą pulę wątków asynchronicznych, ponieważ otwiera wiele plików. Moja jedyna rada to spróbować i zmierzyć. Podobnie jak w przypadku wszystkich optymalizacji?
Domyślnie liczba wątków w Erlang uruchomiony VM jest równa liczbie rdzeni procesorów logicznych (jeśli używasz SMP, oczywiście).
Z mojego doświadczenia wynika, że zwiększenie parametru + A może poprawić wydajność, gdy użytkownik wykonuje wiele jednoczesnych operacji we/wy pliku. I wątpię, że zwiększenie + A może zwiększyć ogólną wydajność procesów, ponieważ program planujący BEAM jest niezwykle szybki i zoptymalizowany.
Mówiąc o dokładnych liczbach - to całkowicie zależy od Twojej aplikacji. Powiedzmy, że w przypadku Riaka, gdzie maksymalna liczba otwartych plików jest mniej lub bardziej przewidywalna, można ustawić + A na to maksimum, lub kilka razy mniej, jeśli jest zbyt duże (domyślnie jest to 64, BTW). Jeśli twoja aplikacja zawiera miliony plików i serwujesz je klientom internetowym - to już inna historia; Najprawdopodobniej warto przeprowadzić testy porównawcze za pomocą własnego kodu i własnego środowiska.
Wreszcie, wydaje mi się, że nigdy nie widziałem + A więcej niż sto. Nie znaczy, że nie możesz tego ustawić, ale prawdopodobnie nie ma w tym żadnego sensu.