CAS更新的Cassandra亞毫秒延遲

我們試圖在單節點上運行的cassandra（v2.1.8）上的簡單列系列中實現CAS（比較和設置）更新的亞毫秒延遲。我們在同一臺機器上運行一系列測試，每個測試包含一個讀取和一個寫入CAS操作（RW），最多隻能看到4 ms。CAS更新的Cassandra亞毫秒延遲

當我們剖析Cassandra過程時，我們看到SEPWorker類在旋轉等待中花費了大部分時間，而實際的RW操作花費的時間更少。我們分析了代碼，並在SEPWorker.doWaitSpin方法中使用的LockSupport.parkNanos方法中添加了一些跟蹤語句，我們發現即使計劃平均睡眠時間爲12μs，實際上每次呼叫也會睡眠800μs 。因此，由於旋轉等待單個SEP Worker的任務，這將平均增加400μs到等待時間。請注意，對於CAS操作，paxos需要執行多個此類任務，這會多次增加此開銷。

任何人都可以建議如何可以避免這種開銷？

來源

2016-04-15 Deepak Kumar

，當涉及到調度線程執行你所描述的是一個普遍的問題。不幸的是，不可能在任意精確的時間間隔內將線程停在WAITING狀態。你可以做的是儘量優化Linux的中斷計時器頻率。但是由於800微秒已經非常靈敏，我不打算看到你的用例有很多性能改進。此外Paxos作爲共識協議並不是針對最少數量的往返旅行而設計的，這種微型優化不會幫助您解決這個問題。

來源

2016-04-15 09:18:43

謝謝@Stefan如果我的計算是正確的，與實際工作相比，等待的開銷似乎相當高。讀取或寫入大約需要50μs。因此，即使對於非paxos操作，它也會爲延遲增加大約10倍的開銷。
在cassandra中沒有出現亞毫秒延遲？在人們實現它的時候，我找不到任何結果。 –

您應該能夠看到至少CL ONE的亞毫秒延遲。有關對併發處理進行建議更改的另請參見以下故障單：https://issues.apache.org/jira/browse/CASSANDRA-10989 –

感謝Stefan提供的鏈接。看起來，當Cassandra移出SEDA架構時，調度開銷應該減少。我試着天真地修改代碼以在同一個netty線程中執行工作，並且我看到了很大的改進。無論如何，直到Cassandra解決這個問題，我們將嘗試通過改變我們的設計來減少對Cassandra的調用的延遲。 –

你或許應該創建一個JIRA，並提出了一個補丁的核心團隊卡桑德拉

來源

2016-04-15 08:46:39 doanduyhai

謝謝@doanduyhai我想知道這是否是通過設計和交易的可擴展性。我看到有計劃讓事情更加異化，例如storageproxy等。所以，我懷疑他們會使任務處理同步。我想知道，如果有任何cassandra \ jdk \ os級別設置的建議可以改善一些事情。 –

CAS更新的Cassandra亞毫秒延遲

回答

相關問題