Ile wątków to za dużo? [zamknięte]

To pytanie zostało omówione dość dokładnie i nie miałem okazji przeczytać wszystkich odpowiedzi. Ale oto kilka rzeczy, które należy wziąć pod uwagę, patrząc na górną granicę liczby jednoczesnych wątków, które mogą spokojnie współistnieć w danym systemie.

1. rozmiar stosu wątków : w Linuksie domyślny rozmiar stosu wątków to 8MB (możesz użyć ulimit-a, aby to sprawdzić).
2. Maksymalna pamięć wirtualna, którą obsługuje dany wariant systemu operacyjnego. Jądro Linux 2.4 obsługuje pamięć przestrzeń adresowa 2 GB. z kernelem 2.6, i trochę większy (3GB)
3. [1] pokazuje obliczenia dla maksymalnej liczby wątków na podaną maksymalną obsługiwaną maszynę wirtualną. Dla 2.4 okazuje się, że jest to około 255 wątków. dla 2.6 liczba jest nieco większa.
4. Jaki masz planer jądra . Porównując scheduler jądra Linuksa 2.4 z 2.6, późniejsze daje planowanie O(1) bez zależności od liczby zadań istniejących w systemie, podczas gdy pierwsze jest bardziej O (n). Tak i SMP Możliwości harmonogramu jądra odgrywają również dobrą rolę w maksymalnej liczbie zrównoważonych wątków w systemie.

Teraz możesz dostosować rozmiar stosu, aby włączyć więcej wątków, ale musisz wziąć pod uwagę ogólne koszty zarządzania wątkami(tworzenie/niszczenie i planowanie). Możesz wymusić powinowactwo procesora do danego procesu, a także do danego wątku, aby powiązać je z konkretnymi procesorami, aby uniknąć kosztów ogólnych migracji wątków między procesorami i uniknąć problemów z zimną gotówką.

Zauważ, że można utworzyć tysiące wątków na swoje życzenie, ale kiedy Linux skończy się maszyną wirtualną, to po prostu losowo rozpoczyna zabijanie procesów (a więc wątków). Ma to na celu zachowanie profilu użyteczności przed maksymalizacją. (Funkcja utility mówi o użyteczności całego systemu dla danej ilości zasobów. Przy stałych zasobach w tym przypadku cykli procesora i pamięci, krzywa użyteczności spłaszcza się z coraz większą liczbą zadań).

Jestem pewien, że Windows kernel scheduler również robi coś w tym rodzaju, aby poradzić sobie z nadmiernym wykorzystaniem zasobów

[1] http://adywicaksono.wordpress.com/2007/07/10/i-can-not-create-more-than-255-threads-on-linux-what-is-the-solutions/

Jeśli twoje wątki wykonują jakąkolwiek pracę wymagającą dużych zasobów (procesor/dysk), rzadko zobaczysz korzyści wykraczające poza jeden lub dwa, a zbyt wiele z nich bardzo szybko zabije wydajność.

Najlepszym przypadkiem jest to,że Twoje późniejsze wątki będą przeciągać się, gdy pierwsze zostaną ukończone, lub niektóre będą miały bloki o niskim napowietrzeniu na zasoby o niskiej zawartości. Najgorsze jest to, że zaczynasz uderzać w pamięć podręczną / dysk/sieć, a ogólna przepustowość spada na podłogę.

Dobrym rozwiązaniem jest aby umieścić żądania w Puli, które są następnie wysyłane do wątków roboczych z puli wątków (i tak, unikanie ciągłego tworzenia/niszczenia wątków jest świetnym pierwszym krokiem).

Liczba aktywnych wątków w tej puli może być następnie poprawiona i skalowana w oparciu o wyniki profilowania, sprzętu, na którym pracujesz i innych rzeczy, które mogą wystąpić na maszynie.

Należy pamiętać, że python (przynajmniej wersja oparta na C) używa tzw. globalnej blokady interpretera , która może mieć ogromny wpływ na wydajność na maszynach wielordzeniowych.

Jeśli naprawdę potrzebujesz najwięcej z wielowątkowego Pythona, możesz rozważyć użycie Jythona lub czegoś takiego.

Jak słusznie powiedział Pax, mierz, nie zgaduj . To, co zrobiłem dla DNSwitness i wyniki były zaskakujące: idealna liczba wątków była znacznie wyższa niż myślałem, coś w rodzaju 15,000 wątków, aby uzyskać najszybsze wyniki.

Oczywiście, to zależy od wielu rzeczy, dlatego musisz zmierzyć siebie.

Complete measures (in French only) in Combien de fils d ' exécution ?.

Napisałem kilka mocno wielowątkowych aplikacji. Ogólnie pozwalam na określenie liczby potencjalnych wątków w pliku konfiguracyjnym. Kiedy dostroiłem się do konkretnych klientów, ustawiłem liczbę na tyle wysoką, że moje wykorzystanie wszystkich rdzeni procesora było dość wysokie, ale nie tak wysokie, że napotkałem problemy z pamięcią (były to wtedy 32-bitowe systemy operacyjne).

Ująć inaczej, gdy osiągniesz jakieś wąskie gardło, czy to CPU, przepustowość bazy danych, przepustowość dysku, itp., dodanie większej liczby wątków nie zwiększy ogólnej wydajności. Ale dopóki nie trafisz w ten punkt, dodaj więcej wątków!

Zauważ, że zakłada to, że dany system(y) jest dedykowany dla Twojej aplikacji i nie musisz ładnie grać (unikać głodowania) innych aplikacji.

Odpowiedź "big iron" to zazwyczaj jeden wątek na ograniczony zasób-procesor (CPU bound), arm (i/o bound) itp., ale działa tylko wtedy, gdy możesz skierować pracę do właściwego wątku, aby uzyskać dostęp do zasobu.

Jeśli nie jest to możliwe, weź pod uwagę, że masz zasoby wymienne (CPU) i zasoby nie wymienne (arms). W przypadku procesorów przypisanie każdego wątku do konkretnego procesora nie jest kluczowe (chociaż pomaga to w zarządzaniu pamięcią podręczną), ale dla arms, jeśli nie możesz przypisać wątku do ramienia, dostajesz się do teorii kolejkowania i jaka jest optymalna liczba, aby ramiona były zajęte. Generalnie myślę, że jeśli nie możesz kierować żądań na podstawie używanego ramienia, to posiadanie 2-3 wątków na ramię będzie miało rację.

Komplikacja pojawia się, gdy jednostka pracy przekazywana do wątku nie wykonuje racjonalnie atomowej jednostki pracy. Np. wątek może mieć w jednym punkcie dostęp do dysku, w innym punkcie czekać w sieci. Zwiększa to liczbę "pęknięć", gdzie dodatkowe wątki mogą dostać się i wykonać użyteczną pracę, ale Zwiększa to również możliwość dodatkowego wątku zanieczyszczania pamięci podręcznych innych itp.

Oczywiście musisz zważyć to wszystko na "wagę" nici. Niestety, większość systemów ma bardzo ciężkie wątki (a to, co nazywają "lekkimi wątkami", często nie są wątkami w ogóle), więc lepiej błądzić po niskiej stronie.

W praktyce widziałem, że bardzo subtelne różnice mogą zrób ogromną różnicę w tym, ile wątków jest optymalnych. W szczególności problemy z pamięcią podręczną i konflikty blokad mogą znacznie ograniczyć ilość praktycznej współbieżności.

Należy wziąć pod uwagę, ile rdzeni istnieje na maszynie, która będzie wykonywała kod. Oznacza to twardy limit liczby wątków, które mogą być kontynuowane w danym momencie. Jeśli jednak, tak jak w Twoim przypadku, wątki będą często czekać na bazę danych do wykonania zapytania, prawdopodobnie będziesz chciał dostroić swoje wątki na podstawie liczby jednoczesnych zapytań, które baza danych może przetworzyć.

Myślę, że to trochę unik dla Twojego pytania, ale dlaczego nie rozwidlić ich na procesy? Moje zrozumienie sieci (z mglistych dni yore, naprawdę nie kod sieci w ogóle) było to, że każde przychodzące połączenie może być traktowane jako oddzielny proces, bo wtedy, jeśli ktoś robi coś paskudnego w procesie, to nie nuke cały program.

Ryeguy, obecnie rozwijam podobną aplikację i mój numer wątków jest ustawiony na 15. Niestety, jeśli zwiększę go do 20, to się zawiesza. Tak więc, tak, myślę, że najlepszym sposobem radzenia sobie z tym jest zmierzenie, czy obecna konfiguracja pozwala na więcej lub mniej niż liczba X wątków.

W większości przypadków należy zezwolić puli wątków, aby to obsłużyć. Jeśli opublikujesz kod lub podasz więcej szczegółów, łatwiej będzie sprawdzić, czy istnieje jakiś powód, dla którego domyślne zachowanie puli wątków nie byłoby najlepsze.

Więcej informacji o tym, jak to powinno działać, znajdziesz tutaj: http://en.wikipedia.org/wiki/Thread_pool_pattern

Tyle wątków ile rdzeni procesora, to jest to, co słyszałem bardzo często.