Ile wątków to za dużo?

312

Piszę serwer i wysyłam każdą akcję do osobnego wątku po otrzymaniu żądania. Robię to, ponieważ prawie każde żądanie wykonuje zapytanie do bazy danych. Korzystam z biblioteki wątków, aby ograniczyć budowę / niszczenie wątków.

Moje pytanie brzmi: jaki jest dobry punkt odcięcia dla takich wątków we / wy? Wiem, że to byłby tylko przybliżony szacunek, ale czy mówimy setki? Tysiące?

Jak mógłbym dowiedzieć się, co to będzie za granica?


EDYTOWAĆ:

Dziękuję wszystkim za odpowiedzi, wygląda na to, że będę musiał to przetestować, aby sprawdzić pułap liczby wątków. Pytanie jednak brzmi: skąd mam wiedzieć, że trafiłem w sufit? Co dokładnie powinienem zmierzyć?

ryeguy
źródło
1
@ryeguy: Chodzi o to, że nie powinieneś ustawiać maksimum w puli wątków, jeśli na początku nie ma problemów z wydajnością. Większość porad dotyczących ograniczania puli wątków do ~ 100 wątków jest absurdalna, większość pul wątków ma / znacznie / więcej wątków niż to i nigdy nie ma problemu.
GEOCHET
ryeguy, patrz dodatek do mojej odpowiedzi poniżej, co mierzyć.
paxdiablo
Nie zapominaj, że Python z natury nie jest przyjazny dla wielu wątków. W dowolnym momencie wykonywany jest pojedynczy kod operacji kodu bajtowego. Wynika to z faktu, że Python korzysta z globalnej blokady interpretera.
ZAPYTAJ
1
@Jay D: Powiedziałbym, że moment, w którym uderzyłeś w sufit, to moment, w którym wydajność spada.
ninjalj
6
@GEOCHET „Chodzi o to, że nie powinieneś ustawiać maksimum w puli wątków” Ummm ... powiedz co? Pule nici o stałym rozmiarze mają zalety płynnej degradacji i skalowalności. Np. W ustawieniach sieciowych, jeśli spawnujesz nowe wątki na podstawie połączeń klienckich, bez ustalonej wielkości puli grozi Ci bardzo realne niebezpieczeństwo dowiedzenia się ( na własnej skórze), ile wątków może obsłużyć Twój serwer i każdy podłączony klient będzie cierpieć. Pula o stałym rozmiarze działa jak zawór rurowy, uniemożliwiając serwerowi odgryzanie więcej, niż może przeżuć.
b1nary.atr0phy

Odpowiedzi:

206

Niektórzy powiedzieliby, że dwa wątki to za dużo - nie jestem w tym obozie :-)

Oto moja rada: zmierz, nie zgaduj. Jedną z sugestii jest skonfigurowanie go i ustawienie początkowo na 100, a następnie wypuszczenie oprogramowania na wolność i monitorowanie tego, co się stanie.

Jeśli użycie wątku osiąga wartość szczytową 3, to 100 to za dużo. Jeśli pozostanie na poziomie 100 przez większą część dnia, podnieś go do 200 i zobacz, co się stanie.

Państwo mogłoby rzeczywiście mają swój kod sama monitorowania użycia i dostosować konfigurację do następnej chwili jej rozpoczęcia, ale to chyba przesada.


W celu wyjaśnienia i opracowania:

Nie opowiadam się za stworzeniem własnego podsystemu pulowania wątków, za wszelką cenę użyj tego, który masz. Ale ponieważ pytałeś o dobry punkt odcięcia dla wątków, zakładam, że twoja implementacja puli wątków ma możliwość ograniczenia maksymalnej liczby utworzonych wątków (co jest dobrą rzeczą).

Napisałem kod puli połączeń wątków i baz danych i mają one następujące funkcje (które moim zdaniem są niezbędne dla wydajności):

  • minimalna liczba aktywnych wątków.
  • maksymalna liczba wątków.
  • zamykanie wątków, które nie były używane przez jakiś czas.

Pierwszy określa punkt odniesienia dla minimalnej wydajności pod względem klienta puli wątków (ta liczba wątków jest zawsze dostępna do użycia). Drugi określa ograniczenie wykorzystania zasobów przez aktywne wątki. Trzeci powraca do linii podstawowej w spokojnych czasach, aby zminimalizować zużycie zasobów.

Musisz zrównoważyć zużycie zasobów wynikające z nieużywanych wątków (A) z zużyciem zasobów, ponieważ nie ma wystarczającej liczby wątków do wykonania pracy (B).

(A) to ogólnie użycie pamięci (stosy i tak dalej), ponieważ wątek niedziałający nie będzie zużywał dużo procesora. (B) zazwyczaj opóźnia przetwarzanie żądań, gdy przychodzą, ponieważ musisz poczekać, aż wątek stanie się dostępny.

Właśnie dlatego mierzysz. Jak twierdzisz, ogromna większość twoich wątków będzie czekała na odpowiedź z bazy danych, więc nie będą działać. Istnieją dwa czynniki, które wpływają na liczbę wątków, na które powinieneś zezwolić.

Pierwszy to liczba dostępnych połączeń DB. Może to być twardy limit, chyba że możesz go zwiększyć w DBMS - Zakładam, że twój DBMS może w tym przypadku przyjmować nieograniczoną liczbę połączeń (chociaż najlepiej też to mierzysz).

Następnie liczba wątków, które powinieneś mieć, zależy od twojego historycznego wykorzystania. Minimum, które powinieneś mieć, to minimalna liczba, którą kiedykolwiek miałeś + A%, z absolutnym minimum (na przykład i skonfiguruj go tak jak A) 5.

Maksymalna liczba wątków powinna być historycznym maksimum + B%.

Powinieneś także monitorować zmiany zachowań. Jeśli z jakiegoś powodu twoje użycie osiągnie 100% dostępnego poziomu przez dłuższy czas (tak, aby wpłynęło to na wydajność klientów), powinieneś podnieść maksymalne dozwolone maksimum, aż znów będzie wyższe o B%.


W odpowiedzi na pytanie „co dokładnie powinienem zmierzyć?” pytanie:

To, co powinieneś dokładnie zmierzyć, to maksymalna liczba wątków jednocześnie używanych (np. Oczekujących na powrót z wywołania DB) pod obciążeniem. Następnie dodaj na przykład współczynnik bezpieczeństwa wynoszący 10% (podkreślono, ponieważ inne plakaty wydają się brać moje przykłady za stałe rekomendacje).

Ponadto należy to zrobić w środowisku produkcyjnym w celu dostrojenia. Wcześniej można uzyskać oszacowanie, ale nigdy nie wiadomo, jaka produkcja rzuci Ci drogę (dlatego wszystkie te rzeczy powinny być konfigurowalne w czasie wykonywania). Ma to na celu uchwycenie sytuacji, takiej jak nieoczekiwane podwojenie przychodzących połączeń klientów.

paxdiablo
źródło
Jeśli wątki są odradzane na przychodzących żądaniach, użycie wątków będzie odzwierciedlać liczbę niezapewnionych żądań. Na tej podstawie nie można ustalić „optymalnej” liczby. Rzeczywiście, znajdziesz więcej wątków, które powodują większą rywalizację o zasoby, a zatem liczba aktywnych wątków wzrośnie.
Andrew Grant
@Andrew, tworzenie wątek wymaga czasu, a może określić optymalną liczbę na podstawie danych historycznych [%] + N (stąd zmierzyć, nie sądzę). Ponadto więcej wątków powoduje rywalizację o zasoby tylko wtedy, gdy wykonują pracę, a nie czekają na sygnał / semafor.
paxdiablo
Gdzie te dane dotyczące „tworzenia wątków” powodują problemy z wydajnością podczas korzystania z puli wątków? Dobra pula wątków nie tworzy i nie niszczy wątków między zadaniami.
GEOCHET
@Pax Jeśli wszystkie twoje wątki oczekują na te same semafory, aby uruchomić zapytania DB, to właśnie ta definicja rywalizacji. Nie jest również prawdą twierdzenie, że nici nic nie kosztują, jeśli czekają na semaforze.
Andrew Grant
1
@Andrew, nie rozumiem, dlaczego semaforowo blokujesz zapytania DB, każdy porządny DB pozwoli na równoczesny dostęp, z wieloma wątkami oczekującymi na odpowiedzi. Wątki nie powinny kosztować czasu wykonywania, gdy semafor jest zablokowany, powinny siedzieć w zablokowanej kolejce do momentu zwolnienia semafora.
paxdiablo
36

To pytanie zostało dość dokładnie omówione 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ą pokojowo współistnieć w danym systemie.

  1. Rozmiar stosu wątków: W Linuksie domyślny rozmiar stosu wątków wynosi 8 MB (możesz to sprawdzić za pomocą ulimit -a).
  2. Maksymalna pamięć wirtualna obsługiwana przez dany wariant systemu operacyjnego. Linux Kernel 2.4 obsługuje przestrzeń adresową pamięci 2 GB. z Kernel 2.6 jestem trochę większy (3 GB)
  3. [1] pokazuje obliczenia dla maksymalnej liczby wątków na dane maks. Obsługiwane VM. W wersji 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 program planujący jądro Linuksa 2.4 z wersją 2.6, później oferuje planowanie O (1) bez zależności od liczby zadań istniejących w systemie, podczas gdy pierwsze z nich jest bardziej O (n). Zatem również możliwości SMP harmonogramu jądra odgrywają dobrą rolę w maksymalnej liczbie zrównoważonych wątków w systemie.

Teraz możesz dostroić rozmiar stosu, aby uwzględnić więcej wątków, ale musisz wziąć pod uwagę 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ąć narzutu 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 jego życzenie, ale kiedy Linuxowi zabraknie VM, to po prostu losowo zaczyna zabijać procesy (czyli wątki). Ma to na celu uniknięcie maksymalnego przekroczenia profilu narzędzia. (Funkcja użyteczności mówi o ogólnosystemowym narzędziu dla określonej 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 program planujący jądro systemu Windows również robi coś takiego, 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/

Jay D.
źródło
17

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

„Najlepszy przypadek” polega na tym, że twoje późniejsze wątki utkną, gdy pierwsze zostaną ukończone, lub niektóre będą miały narzuty blokujące zasoby o niskiej rywalizacji. Najgorsze jest to, że zaczynasz przerzucać pamięć podręczną / dysk / sieć, a ogólna przepustowość spada.

Dobrym rozwiązaniem jest umieszczanie żądań 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 to świetny pierwszy krok).

Liczbę aktywnych wątków w tej puli można następnie dostosować i skalować w oparciu o wyniki profilowania, sprzęt, na którym pracujesz, i inne rzeczy, które mogą wystąpić na komputerze.

Andrew Grant
źródło
Tak i należy go używać w połączeniu z kolejką lub pulą żądań.
Andrew Grant
2
@Andrew: Dlaczego? Powinien dodawać zadanie do puli wątków za każdym razem, gdy odbierze żądanie. To do puli wątków należy przydzielenie wątku dla zadania, gdy jest ono dostępne.
GEOCHET
Co więc robisz, gdy przychodzą setki próśb i brakuje im wątków? Utworzyć więcej? Blok? Zwrócić błąd? Umieść swoje żądania w puli, która może być tak duża, jak to konieczne, a następnie wprowadź te kolejkowane żądania do puli wątków, gdy wątki staną się wolne.
Andrew Grant
„wiele wątków jest tworzonych w celu wykonania szeregu zadań, które zwykle są zorganizowane w kolejce. Zazwyczaj jest o wiele więcej zadań niż wątków. Gdy wątek zakończy swoje zadanie, zażąda następnego zadania z kolejki aż wszystkie zadania zostaną zakończone. ”
GEOCHET
@Andrew: Nie jestem pewien, jakiej puli wątków Pythona używa OP, ale jeśli chcesz rzeczywisty przykład tej funkcji, opisuję: msdn.microsoft.com/en-us/library/…
GEOCHET
10

Należy pamiętać, że Python (przynajmniej wersja oparta na języku C) używa tak zwanej globalnej blokady interpretera, która może mieć ogromny wpływ na wydajność na komputerach wielordzeniowych.

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

Czad Okere
źródło
4
Po przeczytaniu tego spróbowałem uruchomić sito zadań Eratostenesa na trzech wątkach. Rzeczywiście było o 50% wolniejsze niż wykonywanie tych samych zadań w jednym wątku. Dzięki za heads-upy. Uruchomiłem Eclipse Pydev na maszynie wirtualnej, której przydzielono dwa procesory. Następnie wypróbuję scenariusz obejmujący niektóre wywołania bazy danych.
Don Kirkby
3
Istnieją dwa (przynajmniej) typy zadań: związane z procesorem (np. Przetwarzanie obrazu) i związane z operacjami we / wy (np. Pobieranie z sieci). Oczywiście „problem” GIL nie wpłynie zbytnio na zadania związane z operacjami we / wy. Jeśli twoje zadania są związane z procesorem, powinieneś rozważyć przetwarzanie wielowątkowe zamiast wielowątkowe.
iutinvg
1
tak, wątek pytona poprawił się, jeśli masz dużo sieci io.Zmieniłem go na wątek i dostałem 10 * szybciej niż zwykły kod ...
tyan
8

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

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

Kompletne środki (tylko w języku francuskim) w Combien de fils d'exécution? .

bortzmeyer
źródło
1
15 000? To odrobinę wyższa, niż bym się spodziewał. Mimo to, jeśli to właśnie masz, to właśnie to masz, nie mogę się z tym kłócić.
paxdiablo
2
W przypadku tej konkretnej aplikacji większość wątków czeka tylko na odpowiedź z serwera DNS. Im więcej równoległości, tym lepiej w czasie zegara ściennego.
bortzmeyer
18
Myślę, że jeśli masz 15000 wątków blokujących niektóre zewnętrzne wejścia / wyjścia, lepszym rozwiązaniem byłoby znacznie mniej wątków, ale z modelem asynchronicznym. Mówię z doświadczenia tutaj.
Steve,
5

Napisałem wiele bardzo wielowątkowych aplikacji. Zasadniczo zezwalam na określenie liczby potencjalnych wątków w pliku konfiguracyjnym. Po dostrojeniu się do konkretnych klientów, ustawiłem wystarczająco wysoką liczbę, aby moje wykorzystanie wszystkich rdzeni procesora było dość wysokie, ale nie tak wysokie, że napotkałem problemy z pamięcią (były to 32-bitowe systemy operacyjne na czas).

Mówiąc inaczej, po osiągnięciu pewnego wąskiego gardła, czy to procesora, przepustowości bazy danych, przepustowości dysku itp., Dodanie większej liczby wątków nie zwiększy ogólnej wydajności. Ale dopóki nie osiągniesz tego punktu, dodaj więcej wątków!

Pamiętaj, że zakłada to, że omawiane systemy są dedykowane twojej aplikacji i nie musisz dobrze grać (unikaj głodowania) innych aplikacji.

Matthew Lund
źródło
1
Czy możesz podać niektóre liczby, które widziałeś dla liczby wątków? Przydałoby się to po prostu zrozumieć. Dzięki.
kovac
3

Odpowiedź „dużego żelaza” to na ogół jeden wątek na ograniczony zasób - procesor (związany z procesorem), uzbrojenie (związany z we / wy) itp. - ale działa to tylko wtedy, gdy można skierować pracę do właściwego wątku dla zasobu być dostępnym.

Jeśli nie jest to możliwe, weź pod uwagę, że masz zasoby wymienne (CPU) i zasoby nie wymienne (uzbrojenie). W przypadku procesorów nie jest ważne przypisanie każdego wątku do konkretnego procesora (choć pomaga to w zarządzaniu pamięcią podręczną), ale w przypadku uzbrojenia, jeśli nie można przypisać wątku do ramienia, przechodzi się do teorii kolejkowania i optymalnej liczby, aby zachować uzbrojenie zajęty. Ogólnie myślę, że jeśli nie możesz kierować żądań w oparciu o używane ramię, to posiadanie 2-3 wątków na ramię będzie odpowiednie.

Komplikacja pojawia się, gdy jednostka pracy przekazana do wątku nie wykonuje rozsądnie atomowej jednostki pracy. Na przykład wątek może mieć dostęp do dysku w innym miejscu, w innym miejscu należy zaczekać w sieci. Zwiększa to liczbę „pęknięć”, do których mogą dostać się dodatkowe wątki i wykonują użyteczną pracę, ale także zwiększa możliwość wzajemnego zanieczyszczania pamięci podręcznych itp. I zapychania systemu.

Oczywiście musisz to wszystko porównać z „ciężarem” nici. Niestety większość systemów ma bardzo ciężkie wątki (a tak zwane „wątki lekkie” często wcale nie są wątkami), więc lepiej jest pomylić się z niskimi stronami.

W praktyce widziałem, że bardzo subtelne różnice mogą mieć ogromny wpływ na to, ile wątków jest optymalnych. W szczególności problemy z pamięcią podręczną i konflikty blokad mogą znacznie ograniczyć praktyczną współbieżność.

Hot Licks
źródło
2

Jedną rzeczą do rozważenia jest to, ile rdzeni istnieje na komputerze, który będzie wykonywał kod. Jest to twardy limit liczby wątków, które mogą być wykonywane w danym momencie. Jeśli jednak, tak jak w twoim przypadku, wątki często oczekują na wykonanie zapytania przez bazę danych, prawdopodobnie zechcesz dostroić wątki na podstawie liczby jednoczesnych zapytań, które baza danych może przetworzyć.

nowe powstanie
źródło
2
yyy ... nie. Cały sens wątków (zanim wielordzeniowe i wiele procesorów stało się powszechne) ma być w stanie naśladować posiadanie wielu procesorów na maszynie, która ma tylko jeden. W ten sposób otrzymujesz responsywne interfejsy użytkownika - główny wątek i wątki pomocnicze.
mmr
1
@mmr: Um no. Ideą wątków jest umożliwienie blokowania I / O i innych zadań.
GEOCHET
4
Stwierdziłem, że liczba rdzeni na maszynie stanowi twarde ograniczenie liczby wątków, które mogą wykonywać pracę w danym czasie, co jest faktem. Oczywiście inne wątki mogą oczekiwać na zakończenie operacji we / wy, i na to pytanie jest ważna kwestia.
nowy dzień
1
W każdym razie - masz GIL w Pythonie, co czyni wątki tylko teoretycznie równoległymi. Jednocześnie może działać nie więcej niż 1 wątek, więc liczy się tylko reakcja i operacje blokowania.
Abgan
2
+1 Do faktycznego zrozumienia działania komputerów. @mmr: Musisz zrozumieć różnicę między, która wydaje się mieć wiele procesorów i ma wiele procesorów. @Rich B: Pula wątków jest tylko jednym z wielu sposobów obsługi kolekcji wątków. Jest dobry, ale na pewno nie jedyny.
zasmucają
2

Myślę, że to trochę unika twojego pytania, ale dlaczego nie podzielić ich na procesy? Moje rozumienie sieci (od mglistych dni, tak naprawdę wcale nie koduję sieci) było takie, że każde połączenie przychodzące może być traktowane jako osobny proces, ponieważ wtedy, gdy ktoś robi coś nieprzyjemnego w twoim procesie, nie robi to nuke cały program.

mmr
źródło
1
W przypadku Pythona jest to szczególnie prawdziwe, ponieważ wiele procesów może działać równolegle, a wiele wątków - nie. Koszt jest jednak dość wysoki. Musisz za każdym razem uruchamiać nowy interpreter języka Python i łączyć się z DB przy każdym procesie (lub użyć przekierowania potoków, ale ma ono również swoją cenę).
Abgan
Przełączanie między procesami jest - przez większość czasu - droższe niż przełączanie między wątkami (przełączanie całego kontekstu zamiast niektórych rejestrów). Na koniec zależy to w dużej mierze od twojej biblioteki wątków. Ponieważ pytania dotyczyły wątków, zakładam, że procesy już nie wchodzą w rachubę.
Leonidas,
Słusznie. Nie jestem jednak pewien, dlaczego właśnie dlatego otrzymuję -2-punktowy wynik, chyba że ludzie naprawdę chcą zobaczyć odpowiedzi tylko w wątku, zamiast uwzględniać inne, które działają.
mmr
@mmr: Biorąc pod uwagę, że pytanie dotyczyło / wątku / puli, tak, myślę, że ludzie powinni oczekiwać odpowiedzi na temat wątków.
GEOCHET
Tworzenie procesu można wykonać raz podczas uruchamiania (tj. Pula procesów zamiast puli wątków). Amortyzowane przez okres stosowania, może być niewielki. Nie mogą łatwo udostępniać informacji, ale to daje im możliwość pracy na wielu procesorach, więc ta odpowiedź jest przydatna. +1.
paxdiablo
1

ryeguy, obecnie opracowuję podobną aplikację, a mój numer wątków jest ustawiony na 15. Niestety, jeśli zwiększę ją o 20, zawiesza się. Tak, tak, myślę, że najlepszym sposobem na poradzenie sobie z tym jest sprawdzenie, czy twoja obecna konfiguracja pozwala na więcej lub mniej X wątków.

hiperborejskie
źródło
5
Dodanie do liczby wątków nie powinno losowo powodować awarii aplikacji. Jest jakiś powód. Dobrze byłoby ustalić przyczynę, ponieważ w niektórych okolicznościach może to wpłynąć na ciebie nawet przy mniejszej liczbie wątków.
Matthew Lund,
-6

W większości przypadków należy pozwolić puli wątków sobie z tym poradzić. Jeśli opublikujesz jakiś 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ć, można znaleźć tutaj: http://en.wikipedia.org/wiki/Thread_pool_pattern

GEOCHET
źródło
1
@Pax: To nie byłby pierwszy raz, gdy większość ludzi nie chciała odpowiedzieć na pytanie (lub zrozumieć). Nie martwię się.
GEOCHET
-10

Często słyszałem tyle wątków, ile rdzeni procesora.

masfenix
źródło
5
@Rich, przynajmniej wyjaśnij dlaczego :-). Ta praktyczna zasada obowiązuje tylko wtedy, gdy wszystkie wątki są powiązane z procesorem; każdy otrzymuje po jednym „CPU”. Gdy wiele wątków jest związanych z operacjami we / wy, zwykle lepiej jest mieć dużo więcej wątków niż „CPU” (procesor jest cytowany, ponieważ dotyczy fizycznych wątków wykonania, np. Rdzeni).
paxdiablo
1
@Abgan, nie byłem tego pewien, myśląc, że może Python stworzy „prawdziwe” wątki systemu operacyjnego (działającego na wielu procesorach). Jeśli to, co mówisz, jest prawdą (nie mam powodu wątpić), to ilość procesora nie ma łożyska - wątki są przydatne tylko wtedy, gdy większość wątków na coś czeka (np. We / Wy DB)
paxdiablo
1
@Rich: gdy (rzeczywiste) wątki, liczba procesorów MNIE ma wpływ, ponieważ naprawdę możesz uruchamiać wiele oczekujących wątków naprawdę jednocześnie. Z jednym procesorem działa tylko jeden i zyskuje to na tym, że wiele innych wątków czeka na zasób bez procesora.
paxdiablo
1
@Pax: Chyba nie rozumiesz pojęcia pul wątków.
GEOCHET
1
@Rich, rozumiem dobrze pule wątków; wygląda na to, że ja (i inni tutaj) również rozumiem sprzęt lepiej niż ty. Z jednym procesorem może działać tylko jeden wątek wykonawczy, nawet jeśli inne czekają na procesor. Dwa procesory, dwa mogą działać. Gdy wszystkie wątki czekają na procesor, idealna liczba wątków jest równa ...
paxdiablo