要創建多少個線程以及何時創建？

Question

我有一個聯網Linux應用程序，它接收來自多個目的地的RTP流，進行非常簡單的數據包修改，然后將流轉發到最終目的地。

如何確定處理數據所需的線程數？ 我想，我無法為每個RTP流打開一個線程，因為可能有數千個。 我應該考慮CPU核心的數量嗎？ 還有什么重要的？ 謝謝。

Answer 1

了解在服務器上使用多個線程的目的很重要; 服務器中的許多線程用於減少延遲而不是提高速度。 通過擁有更多線程，您不會使cpu更快，但是您更有可能在給定時間段內始終出現一個線程來處理請求。

擁有一堆只是並行移動數據的線程是一個相當低效的射擊槍（每個請求創建一個線程自然就完全失敗了）。 使用線程池模式可以是一種更有效，更集中的方法來減少延遲。

現在，在線程池中，您希望擁有至少與CPU /核心一樣多的線程。 你可以擁有更多，但額外的線程將再次只減少延遲而不是提高速度。

將組織服務器線程的問題視為類似於在超市中組織線路的問題。 您想讓很多收銀員工作得更慢，還是一位收銀員工作超快？ 快速收銀員的問題不在於速度，而是一個擁有大量雜貨的顧客可能仍會占用大量的時間。 對許多線程的需求來自於一些請求會占用大量時間並阻塞所有線程的可能性。 通過這種推理，您是否從許多較慢的收銀員中受益取決於您是否擁有相同數量的雜貨還是截然不同的數字。 回到基本模型，這意味着您必須使用您的線程編號來確定在給定流量的特定特征時最佳情況，並查看處理每個請求所花費的時間。

Answer 2

經典地，合理線程的數量取決於執行單元的數量，IO與計算的比率和可用內存。

執行單位數（ XU ）

這會計算同時有多少個線程處於活動狀態。 根據您的計算可能會或可能不會計算超線程等內容 - 混合指令工作負載更好。

IO與計算的比率（ %IO ）

如果線程永遠不會等待IO但總是計算（％IO = 0），則使用比XU更多的線程只會增加內存壓力和上下文切換的開銷。 如果線程總是等待IO並且從不計算（％IO = 1），則使用poll()或select()的變體可能是個好主意。

對於所有其他情況， XU / %IO給出了完全使用可用GPU所需的線程數的近似值。

可用內存（ Mem ）

這更像是一個上限。 每個線程使用一定量的系統資源（ MemUse ）。 Mem / MemUse為您提供系統可支持的線程數的近似值。

其他因素

即使您可以猜測或（更好地）測量上面的數字，整個系統的性能仍然可能受到其他因素的限制。 例如，可能在系統上運行另一個服務，該服務使用一些XU和內存。 另一個問題是一般可用的IO帶寬（ IOCap ）。 如果每個傳輸的字節所需的計算資源少於您提供的XU，那么顯然您需要更少關注完全使用它們以及更多關於提高IO吞吐量的信息。

有關后一個問題的更多信息，請參閱此Google Talk有關Roofline模型的信息 。

Answer 3

我會說，嘗試只使用一個線程; 它使編程更容易。 雖然您需要使用libevent之類的東西來復用連接，但您不會遇到任何意外的同步問題。

一旦有了可用的單線程實現，就可以進行性能測試，並決定是否需要多線程實現。

即使需要多線程實現，也可能更容易將其分解為多個進程而不是線程（即不共享地址空間; fork（）或執行來自父進程的多個進程副本）如果它們沒有很多共享數據。

您還可以考慮使用Python的“Twisted”之類的東西來簡化實現（這就是它的設計）。

對於在進程中使用線程可能不是一個好例子 - 但是在你的情況下可能很難說。 這取決於您需要在線程之間共享多少數據。

Answer 4

我會查看這個應用程序的線程池。

http://threadpool.sourceforge.net/

允許線程池管理線程和隊列。

您可以稍后根據性能分析調整最大和最小線程數。

Answer 5

聆聽建議您使用libevent（或OS特定實用程序，如epoll / kqueue）的人。 在許多連接的情況下，這是絕對必須的，因為像你說的那樣，創建線程將是一個巨大的性能命中，而select（）也不會完全削減它。

Answer 6

讓你的程序決定。 添加代碼來測量吞吐量並動態增加/減少線程數以最大化它。

這樣，無論執行核心數量和其他因素如何，您的應用程序始終都能正常運行

Answer 7

避免嘗試為每個客戶端請求創建一個（甚至N個）線程是個好主意。 這種方法通常是不可擴展的，你肯定會遇到內存使用或上下文切換的問題。 您應該查看使用線程池方法，並查看傳入請求作為池中任何線程要處理的任務。 然后，此方法的可伸縮性受池中理想線程數的限制 - 通常這與CPU核心數相關。 您希望嘗試讓每個線程在單個核心上使用100％的CPU - 因此在理想情況下，每個核心將有1個線程，這將減少上下文切換到零。 根據任務的性質，這可能是不可能的，也許線程必須等待外部數據，或從磁盤或其他任何內容讀取，因此您可能會發現線程數增加了一些比例因子。