EC2 的 Spot Instance 可以「接關」

Amazon EC2Spot Instance 可以「接關」了:「New – Stop & Resume Workloads on EC2 Spot Instances」。

當 Spot Instance 的競價不足以標到機器時,他會先關起來 (Stop),等到價錢低於競價後就會再打開機器,這時候的狀態就會恢復。另外也提到了必須是使用 EBS 的機器才支援:

Amazon EC2 Spot now allows Amazon EBS-backed instances to be stopped in the event of interruption, instead of being terminated when capacity is no longer available at your preferred price. Spot can then fulfill your request by restarting instances from a stopped state when capacity is available within your price and time requirements.

用法是把 Spot Instance 的關機設定設為 Stop:

To use this new feature, choose “stop” instead of “terminate” as the interruption behavior when submitting a persistent Spot request. When you choose “stop”, Spot will shut down your instance upon interruption.

恢復的時候就會儘量保持一樣地開回來 (連 instance id 都相同):

When capacity is available again within your price and time requirements, Spot will restart your instance. Upon restart, the EBS root device is restored from its prior state, previously attached data volumes are reattached, and the instance retains its instance ID.

是個接關的感覺 XD

Go 1.9 的 GC 改善

Update:被提醒後仔細看了一下,是 1.8 預設生效 (但保留選項切回來 debug),如果沒問題的話 1.9 把舊的方式拔乾淨:

Assuming things go smoothly, we will remove stack re-scanning support when the tree opens for Go 1.9 development.

標題就不改了... 以下原文。

在「Sub-millisecond GC pauses」這邊看到的。Golang 想辦法將 GC 造成的影響降低:「Proposal: Eliminate STW stack re-scanning」。

目標是解決最大的 GC pause 來源:

As of Go 1.7, the one remaining source of unbounded and potentially non-trivial stop-the-world (STW) time is stack re-scanning.

然後拿新的解法來戰,目前初步的測試看起來可以降到 50µs (== 0.05ms):

We propose to eliminate the need for stack re-scanning by switching to a hybrid write barrier that combines a Yuasa-style deletion write barrier [Yuasa '90] and a Dijkstra-style insertion write barrier [Dijkstra '78]. Preliminary experiments show that this can reduce worst-case STW time to under 50µs, and this approach may make it practical to eliminate STW mark termination altogether.

在「runtime: eliminate stack rescanning · Issue #17503 · golang/go」這邊可以看到進度,現在已經在 master branch 上了,看起來會在 1.9 的時候被放出來... 不過 worst case 的時間上修了 XDDD

The high level summary is that this reduces worst-case STW time to about 100 µs and typical 95%ile STW time to 50 µs (assuming, of course, that the OS doesn't get in the way and that the system isn't otherwise overloaded).

但看起來應該還是很大的效能改善,尤其是 CPU bound 的應用?

Google Chrome 停用平滑捲動

因為把 JavaScript 開回來了,所以有這個困擾... :(

Google Chrome 的平滑捲動可以透過 chrome://flags 裡面的設定關閉 (OS X 上則是透過系統設定關閉),但就是有不少網站會很雞婆,用 JavaScript 模擬平滑捲動,所以就花了時間把 extension 寫出來:「Stop Smooth Scrolling」。

由於大多數平滑捲動的作法都是透過對 document 或是 window 上掛上與平滑捲動相關事件做到的,所以我是透過 addEventListener()useCapture flags,然後再用 preventDefault() 擋下後續的處理。

這樣做會有一些問題,其中比較明顯的是地圖類功能的滾輪會失效,這個部分我先放進預設的白名單了,如果有其他的問題,除了可以自己加以外,也可以開 ticket 讓我加進預設清單 :o

實際運作起來大概是這樣:

Anyway,寫這個還蠻有趣的,玩了不少新東西: