The Munich location is our third location in Germany (joining Frankfurt and Berlin), and our 7th edge location in Germany bringing the total number of worldwide edge locations to 69.
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.
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).
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.
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.