DTrace 的開發者之一 Brendan Gregg 目前正在 Linux 核心中開發基於 BPF 的效能分析工具，他總結了分析 Netflix 在將 Cassandra DBMS 從 CentOS 遷移到 Ubuntu 時遇到的效能問題所獲得的經驗。基於Xen 的Amazon EC2 雲。遷移後，CPU 負載增加了 30%，寫入作業期間的延遲增加了大約相同的量。事實證明，密集請求時間資訊的應用程式的效能很大程度上取決於系統中選擇的確切時間來源。
起初，效能下降的原因並不明顯，診斷開始於使用 top 和 execsnoop 實用程式監控持續運行或定期啟動資源密集型系統進程可能產生的影響。但一切都表明，資源消耗增加了，特別是在 Java 編寫的 Cassandra DBMS 中。比較在 CentOS 和 Ubuntu 上並行運行的兩個 Cassandra 進程處理相同查詢的分析指標，結果表明總時間的大約 32% 花費在調用 os::javaTimeMillis() 上，該函數用於獲取有關當前時間的信息。
之後，進行了一個實驗，編寫了一個簡單的 Java 應用程序，循環呼叫 System.currentTimeMillis() 方法一億次。運行該應用程式顯示，在 CentOS 上完成需要 13 秒，在 Ubuntu 上大約需要 68 秒，即慢5倍。用 C 語言編寫了一個類似的程序，該程序調用 gettimeofday() 函數一億次，但在執行時，得到了類似的結果。
由於很明顯問題的根源在於傳回當前時間的函數，因此在系統中選擇不同的精確時間源時，注意力轉向了指標的變化。從「/sys/devices/system/clocksource/clocksource0/current_clocksource」的內容來看，在客戶系統中執行Linux時，預設使用「xen」定時器。將時間來源變更為「tsc」後，Ubuntu中測試應用程式的執行時間從68秒減少到3.3秒，即它變得快了 20 倍。此外，也對kvm-clock時間源進行了效能測試，結果顯示與TSC相比延遲增加了20%。 $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ 時間 java TimeBench 真實 1m8.300m 使用者 $0m 38.337m0m 使用者 29.875m 0m0 echo tsc > /sys/devices/system/clocksource/clocksource3.370/current_clocksource $ 時間java TimeBench 真實0m3.353s 用戶0m0.026s sys XNUMXmXNUMXs
為了在選擇 TSC 來源時取得時間，使用 RDTSC 處理器指令，該指令的執行不需要係統呼叫（該指令不需要提升權限，並從 CPU 內建的時間計數器產生一個值）。預設情況下，TSC 未激活，因為在過去，該來源不排除逐漸時間漂移，而在其他處理器中，這種漂移是透過軟體調整以獲得更準確的讀數。據一位專門從事處理器開發的工程師稱，對使用 TSC 時的時間偏移的擔憂長期以來都是不真實的，在現代處理器中，該源可以產生穩定的讀數多年。
將 Netflix 的生產伺服器切換到 TSC 來源後，寫入延遲減少了 43%，使用 Ubuntu 實現的結果比運行具有「xen」時間來源的 CentOS 的配置快 4 倍。研究結果被轉移到亞馬遜，亞馬遜官方建議在基於 Xen 虛擬機管理程式的 AWS EC2 環境中使用預設的 TSC 時間來源（在基於 Nitro 虛擬機器管理程式的環境中仍建議使用 kvm-clock）。
來源： opennet.ru