多核系統上的Linux線程調度差異？

Question

我們有幾個延遲敏感的「管道」風格的程序，在一個Linux內核上運行時，其性能會有明顯的下降。尤其是，我們發現2.6.9 CentOS 4.x（RHEL4）內核的性能更好，而CentOS 5.x（RHEL5）2.6.18內核的性能更差。

「管道」程序，我的意思是一個有多個線程。多線程處理共享數據。每個線程之間都有一個隊列。因此，線程A獲取數據，將數據推入Qab，線程B從Qab中抽取，執行一些處理，然後推入Qbc，線程C從Qbc中抽取等等。初始數據來自網絡（由第三方生成）。

我們基本上測量從接收數據到最後一個線程執行任務的時間。在我們的應用程序中，當從CentOS 4移至CentOS 5時，我們看到從20微秒到50微秒的增加。

我已經使用了幾種分析我們應用程序的方法，並確定在CentOS 5上增加的延遲來自隊列操作（特別是彈出）。

但是，通過使用taskset將程序綁定到可用內核的子集，我可以提高CentOS 5的性能（與CentOS 4相同）。

因此，在CentOS 4和5之間，引起線程調度不同（對於我們的應用程序來說這是不理想的）的一些改變（可能是內核）。

雖然我可以使用taskset（或通過sched_setaffinity（）在代碼中）「解決」這個問題，但我的首選是不必這樣做。我希望有某種內核可調參數（或者可能是可調參數的集合），其默認值在版本之間進行了更改。

任何人都有這方面的經驗？也許還有一些地方需要調查？

更新：在這種特殊情況下，通過來自服務器供應商（Dell）的BIOS更新解決了此問題。我在這一張上拉了一會兒頭髮。直到我回到基礎，並檢查了我的供應商的BIOS更新。可疑的是，其中一項更新表示「在最佳性能模式下提高性能」。一旦我升級了BIOS，CentOS 5的速度更快 - 一般來說，但特別是在我的隊列測試和實際生產運行中。

Answer 1

嗯..如果生產者 - 消費者隊列中的pop（）操作花費的時間對應用程序的整體性能產生了重大影響，我建議您的線程/ workFlow的結構不是最佳的，某處。除非在隊列中存在大量的爭用，否則即使隊列在經典的「計算機科學」117中使用內核鎖，任何現代操作系統上的PC隊列推送/彈出都會超過μS左右，我都會感到驚訝 - 如何用三種信號燈的方式製作一個有限的PC隊列。

你能只吸收線/秒即做最少的功爲那些做的大部分功能，因此減少流經你的系統每總體工作項目推/彈出的號碼嗎？

Answer 2

Linux調度程序多年來一直是一個變化和爭論的熱點領域。你可能想嘗試一個非常新的內核，並給出一個去。是的，你可能必須自己編譯它 - 這對你有好處。你也可以（當你擁有較新的內核時）想要考慮將不同的進程放在不同的容器中，並將所有其他進程放入另一個容器中，看看是否有幫助。

就其他隨機事件而言，您可以提高各種流程的優先級，添加實時語義（注意，具有實時特權的錯誤診斷程序會使系統的其他部分癱瘓）。