Tag: pool

Amazon RDS 推出了 Connection Pool 的產品

Amazon RDS 推出了 Connection Pool 的產品，叫做 Amazon RDS Proxy：「Introducing Amazon RDS Proxy (Preview)」。

目前支援 MySQL (包括了傳統的與 Aurora 版本的)：

Amazon RDS Proxy supports Amazon RDS for MySQL and Amazon Aurora with MySQL compatibility, with support for additional RDS database engines coming soon.

定價策略看起來是依照後端資料庫的 vCPU 計算：

Pricing is simple and predictable: you pay per vCPU of the database instance for which the proxy is enabled.

翻了一下價錢頁是 USD$0.015/vCPU (用 us-east-1 的資料)，而如果是 t2 系列的機器，最低是以 2 vCPUs 計算，不是照使用比例算：

RDS Proxy pricing correlates to the number of vCPUs of the database instance for which it is enabled, with a minimum charge for 2 vCPUs.

這樣一個 vCPU 一個月大約要 USD$21.6，算起來頗貴的... 如果 SLA 允許的話，用基本的方式 failover 也許就 ok 了...

如果 SLA 真的要追求到這麼高的話，可以在這些區域測試：

Amazon RDS Proxy is available in preview for RDS MySQL and Aurora MySQL in US East (N. Virginia), US East (Ohio), US West (Oregon), EU West (Ireland), and Asia Pacific (Tokyo) regions. Support for RDS PostgreSQL and Aurora PostgreSQL is coming soon.

TP-Link 的 NTP 流量

在「TP-Link repeater firmware squanders 715 MB/month」這邊看到 TP-Link 因為 NTP 的關係而狂吃流量的情況：(這邊是用逗點表示小數點，所以是 715.4 MB/month)

You should probably avoid TP-Link products if you’re on a tight bandwidth budget. By design, TP-Link firmware sends six DNS requests and one NTP query every 5 seconds, for a total of 715,4 MB per month.

如果拿 24 小時都開機的 Windows 相比的話，會發現這數字天差地別：

To put this number in context: an always-on Windows device will use around 1,6 KB per month on NTP.

作者抓出韌體上面的設定，發現裡面寫死了不少伺服器... 那個 au 與 nz 的選擇讓人頗好奇，另外直接把幾個大學的 NTP server 放進去不知道是什麼樣的想法：

TP-Link has hardcoded the following non-configurable NTP servers and server pools in their firmware:

  • time.nist.gov, time-a.nist.gov, time-b.nist.gov, time-nw.nist.gov
  • au.pool.ntp.org, nz.pool.ntp.org
  • 133.100.9.2, 128.138.140.44, 192.36.144.22

The first sets of servers are operated by the US National Institute of Standards and Technology (NIST). The second is the Australian and New Zealand public NTP project time server pools. The IP addresses are owned by universities in Japan, Colorado; US, and Sweden respectively.

而從行為可以看到沒有遵守這些 NTP service 的規範：

The NTP Pool project asks device manufacturers and vendors to register (and optionally sponsor) their own pools through the service (e.g. tplink.pool.ntp.org), and emphasize that they “must absolutely not use the default pool.ntp.org zone names”. They also request that vendors don’t check more often than every 5 minutes at the most.

而且因為沒有地方可以修改這些設定，唯一的解法是不要買 TP-Link 的產品：

You can avoid buying TP-Link products to avoid this problem.

You can’t turn this behavior off in TP-Link’s web administration interface nor in their management app for mobile. You can’t change the NTP server addresses it targets either.

Amazon 的 SES 推出 Dedicated IP Pool

Amazon SES 推出了 Dedicated IP Pool：「New – SES Dedicated IP Pools」，也就是發信時可以使用自己專屬的 IP address。

Today we released Dedicated IP Pools for Amazon Simple Email Service (SES). With dedicated IP pools, you can specify which dedicated IP addresses to use for sending different types of email.

價錢其實不算貴？每個 IP 的費用是 USD$24.95/month，對於量夠大的單位可以避免被其他人影響：

Dedicated IPs are $24.95 per address per month at the time of this writing – but you can find out more at the pricing page.

不過 SES 用起來最痛的問題還是在對於收信人不存在時的 bounce rate...

InnoDB 的 buffer pool preload 功能

Percona 的人討論了 InnoDB 提供的 buffer pool preload 功能：「Using the InnoDB Buffer Pool Pre-Load Feature in MySQL 5.7」。

就如同他所講的，因為硬體設備的進步 (主要是 SSD 的興起)，而導致 preload 的需求已經沒以前重要了：

Frankly, time has reduced the need for this feature. Five years ago, we would typically store databases on spinning disks. These disks often took quite a long time to warm up with normal database workloads, which could lead to many hours of poor performance after a restart. With the rise of SSDs, warm up happens faster and reduces the penalty from not having data in the buffer pool.

由於 SSD 的 random read 很快，反而可以直接推上線讓他邊跑服務邊 warm up。不過相對的，傳統硬碟的 InnoDB database 還是可以規劃需求，畢竟 random read 還是痛點...

MySQL 5.6 到 5.7 改變的預設值

Percona 整理了一份 MySQL 5.6 到 5.7 改變的預設值，對於評估與轉移的人都很有用：「MySQL Default Configuration Changes between 5.6 and 5.7」。

sync_binlog 居然從 0 改成 1 了，這對效能的影響應該不少。

performance_schema_* 有不少改成自動調整了，可以省下不少功夫。

innodb_buffer_pool_dump_at_shutdown 與 innodb_buffer_pool_load_at_startup 都打開了，這避免了正常重啟時的 warm up 問題，不過在存在有效的手段可以手動 warm up 的時，應該還是會關掉吧。(參考 2013 的文章「熱 MySQL InnoDB 的方式...」)

另外介紹了 InnoDB 預設格式的改變，這點到是因為使用 COMPRESSED，反而不太受到影響。

巴黎廢棄的地鐵站的游泳池計畫...

在 Imgur 上看到「Paris is reusing some abandoned subways as swimming pools.」：

但下面第一個 comment 的連結：

We did the same thing in New York http://imgur.com/qGd3QLw

點進去：

笑噴 XDDD

PS：可以參考「巴黎廢棄地鐵站 “Ghost Stations” 再利用計劃，月台變身餐廳、劇院、游泳池」這篇文章。

Facebook 因為 Connection Pool 選擇機制，加上系統的複雜性而導致的慘案...

Facebook 的 engineer 寫了一篇文章，說明他們花了超過兩年的時間找到一個 bug：「Solving the Mystery of Link Imbalance: A Metastable Failure State at Scale」。

整個故事是個通靈的故事...

Facebook 在底層的架構使用了 Link Aggregation 的規劃，多條線路 channel bonding 在一起連到骨幹上。但發現有時候會卡在某一條線路壅塞而導致 system failure。

於是就一路追下去，從 switch 本身開始懷疑，最後去組織跨部門的研究小組跳下去分析 (通靈)。後來才觀察到是因為 connection pool 的機制本身用的演算法在 Facebook 這個複雜的系統架構下造成的慘案...

當 query burst 發生時，Facebook 的系統會同時到 50～100 組資料庫撈資料出來寫入 cache，而 connection pool 的機制用的是 MRU (Most Recently Used)，從 congestion link 回來的 connection 會在 pool 裡面的最上方，於是就愈來愈塞...

知道問題後，解決的方法就簡單多了。只是把 connection 選擇演算法從 MRU 換成 LRU 後就解決了，但中間用了超過兩年的時間，以及至少 30 個人的努力才把問題找出來並且解決。

可以看到最後銘謝的對象一卡車：

Thanks to all of the engineers who helped us manage and then fix this bug, including James Paussa, Ernesto Ovcharenko, Mark Drayton, Peter Hoose, Ankur Agrawal, Alexey Andreyev, Billy Choe, Brendan Cleary, JJ Crawford, Rodrigo Curado, Tim Eberhard, Kevin Federation, Hans Fugal, Mayuresh Gaitonde, CJ Infantino, Mark Marchukov, Chinmay Mehta, Murat Mugan, Austin Myzk, Gaya Nagarajan, Dmitri Petrov, Marco Rizzi, Rafael Rodriguez, Steve Shaw, Adam Simpkins, David Swafford, Wendy Tobagus, Thomas Tobin, TJ Trask, Diego Veca, Kaushik Veeraraghavan, Callahan Warlick, Jason Wilbanks, Jimmy Williams, and Keith Wright.

最後附上 Facebook 解釋的圖：

MySQL 上的 Thread Pool...

Percona 的人寫了一篇「Percona Server: Improve Scalability with Percona Thread Pool」，提到關於 MySQL 在連線數很多時的效能。

傳統的作法是一個連線使用一個 thread，這種方法實做起來很簡單，但當連線數超過一定程度時就會因為共用資源的限制而變慢。

其中一種解決方法是引入 Thread Pool 架構，也就是 M 個 thread 處理 N 個連線。

Oracle 有提供商用版本叫做 Thread Pool Plugin，就如同名字，是以 plugin 形式存在。這個功能在 5.5 與 5.6 都有。

MariaDB 也有 open source 實做的 Thread pool。

而 Percona 則是使用 MariaDB 的版本。(原文是說有改善，不過 benchmark 並沒有列出來，我「猜」其實沒什麼改善...)

可以看到在多連線數時的效果相當好。在 MariaDB 的文件裡有提到會有改善的時機：

Threadpools are most efficient in situations where queries are relatively short and the load is CPU bound (OLTP workloads). If the workload is not CPU bound, you might still want to limit the number of threads to save memory for the database memory buffers.

query 相對短，而且是 CPU bound。

回頭看的時候發現 Percona Server 5.5 就有支援 Thread Pool 了，應該來測試看看效果如何...