Home » 2017 » January (Page 2)

AWS 正式進入 IPv6 的世界

AWS 總算是進入全面支援 IPv6 了:「AWS IPv6 Update – Global Support Spanning 15 Regions & Multiple AWS Services」。

之前不少服務都支援了,主要是差 EC2 與新出的 ALB,這一次大量服務都上了 IPv6 (但還不是全部),算是讓 AWS 正式進入 IPv6 的世界:

Today I am happy to share the news that IPv6 support for EC2 instances in VPCs is now available in a total of fifteen regions, along with Application Load Balancer support for IPv6 in nine of those regions.

EC2 的 r4 系列機器開出來了...

Amazon EC2 的 r4.* 總算是開出來了:「Amazon EC2 R4 instances are now available in new regions」。

Amazon EC2 R4 instances are now available in the following regions: Asia Pacific (Tokyo), Asia Pacific (Singapore), South America (São Paulo), Asia Pacific (Seoul), Asia Pacific (Mumbai), Canada (Central), and EU (London).

r4.16xlarge (488GB) 算是補上中間的 r3.8xlarge (244GB) 與 x1.16xlarge (976GB) 中間的一塊洞了,不然之前得開 p2.8xlarge (488GB),但也不是每一區都有,而且用不到 GPU 就浪費了...

瀏覽器 UI 的死亡線

作者 Eric Lawrence 現在在 Google Chrome team 裡,寫了一篇文章講到瀏覽器上 UI 設計與安全性的問題:「The Line of Death」。

從一開始會假設紅線以上是可信任的:

後來有些操作跨過這條線 (左邊),於是就開始有很 tricky 的方法 (右邊):

甚至反過來利用 icon 讓使用者誤會是表示有訊息要通知使用者:

另外是直接惡搞,假裝是另外一個視窗:

最新的方法是利用 HTML5 的 Fullscreen API 直接搞定所有事情:

花樣愈來愈多了...

Facebook 機房內的 IPv6 架構

Facebook 在「Legacy support on IPv6-only infra」這邊提到機房內主要的流量幾乎都是 IPv6 了:

Today, 99 percent of our internal traffic is IPv6 and half of our clusters are IPv6-only.

不過只有一半的機器是 IPv6-only,這個比例看起來還有不少服務在 dual-stack 轉移階段... 然後從外部只有 15% 的流量是 IPv6:

Globally, however, only 15 percent of people who use Facebook have IPv6 support.

所以從外部連進來的時候必須轉換成 IPv6 資訊:

這張圖也解釋了 shiv 的角色,在 traceroute 的時候會看到他...

MyRocks 與 InnoDB 在 INSERT 效能的比較

MyRocksMark Callaghan 對 INSERT 效率整理出來的比較:「Insert benchmark, MyRocks and InnoDB」。

當資料比記憶體小的時候,InnoDB 效能比較好。但超過記憶體大小時就是 MyRocks 效能比較好。另外 InnoDB 在 MySQL 5.7 的效率比 5.6 好不少。

兩張圖來自相同資料,只是 x 軸不太一樣。

是從 16 台 client 裡面抽一台的量出來,這樣就可以解釋後面那段爬上來... (其他台跑完了,所以這台的 insert 速度變快了)

This is for data from one of the 16 clients rather than the global rate because my test script forgot to collect that.

While it is odd that the throughput rate for InnoDB 5.7 picks up at test end, that can occur if the thread I monitored ran longer than other threads and had less competition for HW resources near test end.

Swap 對 InnoDB 的影響

Percona 的老大拿 5.7 版做實驗,確認 swap 對 InnoDB 的影響:「The Impact of Swapping on MySQL Performance」。

測試的機器是 32GB RAM,作業系統 (以及 swap) 裝在已經有點年紀的 Intel 520 SSD 上,而 MySQL 則是裝在 Intel 750 NVMe 上。透過對 innodb_buffer_pool 的調整來看情況。

可以看到設為 24GB (記憶體 75% 的量) 時很穩定的在 44K QPS 與 3.5ms (95%):

This gives us about 44K QPS. The 95% query response time (reported by sysbench) is about 3.5ms.

而當設成 32GB 的時候開始可以觀察到 swap i/o,掉到 20K QPS 與 9ms (95%):

We can see that performance stabilizes after a bit at around 20K QPS, with some 380MB/sec disk IO and 125MB/sec swap IO. The 95% query response time has grown to around 9ms.

當拉到 48GB 的時候就更掉更多,6K QPS 與 35ms (95%):

Now we have around 6K QPS. Disk IO has dropped to 250MB/sec, and swap IO is up to 190MB/sec. The 95% query response time is around 35ms.

作者發現掉的比率沒有想像中大:

When I started, I expected severe performance drop even with very minor swapping. I surprised myself by getting swap activity to more than 100MB/sec, with performance “only” halved.

這邊測試用的是 SSD,如果是傳統用磁頭的硬碟,對 random access 應該會很敏感而掉更多:

This assumes your swap space is on an SSD, of course! SSDs handle random IO (which is what paging activity usually is) much better than HDDs.

基本上還是要避免碰到 swap 啦,另外 comment 的地方剛好有提到前陣子在猜測的 best practice,測試時的 vm.swappiness 是設成 1,這應該是作者的 best practice:

Swappiness was set to 1 in this case. I was not expecting this to cause significant impact as swapping is caused by genuine (intended) missconfiguration with more memory required than available.

Archives