Open kylemocode opened 2 years ago
GC 是造成節點停止響應的一個可能因素,文章中提到一個作法
一個新興的想法是將 GC 暫停視為一個節點的短暫計劃中斷,並在這個節點收集其垃圾的同時,讓其他節點處理來自客戶端的請求。如果執行時可以警告應用程式一個節點很快需要 GC 暫停,那麼應用程式可以停止向該節點發送新的請求,等待它完成處理未完成的請求,然後在沒有請求正在進行時執行 GC。這個技巧向客戶端隱藏了 GC 暫停,並降低了響應時間的高百分比。一些對延遲敏感的金融交易系統使用這種方法。
看起來像是說開發者對於 GC 流程有一定的掌控權,不過以自己比較熟悉的 JavaScript 來說,開發者沒有辦法決定 GC 的執行時機,也無從得知 GC 什麼時候會執行,基本上掌控權可以說是 0,因為 JS single threaded 的特性,可能只能透過 Incremental Marking 來避免stop the world 的狀況(ref)
所以想問文中提的這個方式是不是蠻看程式語言特性的?文中附上的參考連結看起來 Java 似乎可以去調整 GC 的參數,go 語言似乎也可以,想問有人有這方面的經驗或是看過類似的資源嗎?
順便分享 Discord 因為 GC 影響效能從 Go 換到 Rust 的文章
Python 的gc可以關閉並手動控制 https://zhuanlan.zhihu.com/p/295062531
GC 是造成節點停止響應的一個可能因素,文章中提到一個作法
一個新興的想法是將 GC 暫停視為一個節點的短暫計劃中斷,並在這個節點收集其垃圾的同時,讓其他節點處理來自客戶端的請求。如果執行時可以警告應用程式一個節點很快需要 GC 暫停,那麼應用程式可以停止向該節點發送新的請求,等待它完成處理未完成的請求,然後在沒有請求正在進行時執行 GC。這個技巧向客戶端隱藏了 GC 暫停,並降低了響應時間的高百分比。一些對延遲敏感的金融交易系統使用這種方法。
看起來像是說開發者對於 GC 流程有一定的掌控權,不過以自己比較熟悉的 JavaScript 來說,開發者沒有辦法決定 GC 的執行時機,也無從得知 GC 什麼時候會執行,基本上掌控權可以說是 0,因為 JS single threaded 的特性,可能只能透過 Incremental Marking 來避免stop the world 的狀況(ref)
所以想問文中提的這個方式是不是蠻看程式語言特性的?文中附上的參考連結看起來 Java 似乎可以去調整 GC 的參數,go 語言似乎也可以,想問有人有這方面的經驗或是看過類似的資源嗎?
順便分享 Discord 因為 GC 影響效能從 Go 換到 Rust 的文章