Tag: read

Linux 下 RAID1 的 SSD 會有讀取不平均問題

在「Unbalanced reads from SSDs in software RAID mirrors in Linux」這邊看到作者看 S.M.A.R.T. 數據時發現兩顆 SSD 硬碟組成的 RAID1 有很明顯的讀取不平均的問題：

242 Total_LBAs_Read [...] 16838224623
242 Total_LBAs_Read [...] 1698394290

原因是因為 Linux 對 RAID1 的 SSD 有不一樣的演算法：

The current state of RAID1 read balancing is kind of complex, but the important thing here in all kernels since 2012 is that if you have SSDs and at least one disk is idle, the first idle disk will be chosen.

2016 時演算法就更激進了，變成非 SSD 會：

In kernels with the late 2016 change, this widens to if at least one disk is idle, the first idle disk will be chosen, even if all mirrors are HDs.

加上 SSD 很快，這造成 loading 幾乎都在第一顆上... 這對 SSD 應該是還好啦 (理論上 SSD 的讀取不傷壽命)，不過還是有點怪就是了。

MySQL 上不同 Isolation Level 對效能的影響

目前看到的結論都是：MySQL (InnoDB) 上因為高度對 RR (REPEATABLE-READ) 最佳化，使得 RR 的效能反而比 RC (READ-COMMITTED) 以及 RU (READ-UNCOMMITTED) 都好。

不清楚 RR/RC/RU 差異的可以參考維基百科上「Isolation (database systems)」的解釋...

從 2010 年在測 5.0 的「Repeatable read versus read committed for InnoDB」到 2015 年測 5.7 的「MySQL Performance : Impact of InnoDB Transaction Isolation Modes in MySQL 5.7」都測出 RR 的效能比 RC/RU 好... 三段分別是 RR/RC/RU：

所以在 MySQL 上沒有使用 RC/RU 的必要... (抱頭)

一篇教你怎麼讀論文的論文...

在 Hacker News Daily 上看到的，這是一篇教你怎麼讀論文的論文：「How to Read a Paper」，標注的版本是 Version of February 17, 2016。

不是惡搞的那種文章，整篇只有兩頁，真的給一種建議方式讓還在迷惘的人可以試著用用看...

如果你已經有自己的方法，就未必要用這篇的方法了...

Amazon DynamoDB Accelerator (DAX)

DynamoDB 推出的新架構，在系統上幫忙處理 cache：「Amazon DynamoDB Accelerator (DAX) – In-Memory Caching for Read-Intensive Workloads」。

DAX 跟現有的 DynamoDB API 相容：

DAX is a fully managed caching service that sits (logically) in front of your DynamoDB tables. It operates in write-through mode, and is API-compatible with DynamoDB.

因為 cache 的緣故，會是 eventually-consistent 架構：

Responses are returned from the cache in microseconds, making DAX a great fit for eventually-consistent read-intensive workloads.

然後是 r3 系列的機器組成的，限制在十台 (冒出大大的問號)：

Each DAX cluster can contain 1 to 10 nodes; you can add nodes in order to increase overall read throughput. The cache size (also known as the working set) is based on the node size (dax.r3.large to dax.r3.8xlarge) that you choose when you create the cluster. Clusters run within a VPC, with nodes spread across Availability Zones.

不是很清楚這樣的好處 (比起自己用 memcached 或是其他類似的 cache 架構)，也許過幾天想通了會開竅... :o

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 還是痛點...

InnoDB 的 Isolation Level 以及 Performance Schema 對效能的影響

雖然 Mark Callaghan 現在的主力都在 MyRocks 上，但他還是對 InnoDB 上的效能頗關注 (畢竟是個成熟而且競爭的產品)。而這篇「Sysbench, InnoDB, transaction isolation and the performance schema」講到 MySQL 5.6.26 裡的 InnoDB，了解 isolation level 與 performance schema 對效能的差異。結果可以在這邊翻到。

關掉 performance schema 會讓效能變好是預期的，不過看起來比預期小很多。另外某些情況下 RR (REPEATABLE-READ) 的效能會比 RC (READ-COMMITTED) 好倒是頗意外，這邊也有給出原因：

Using repeatable-read boosts performance because it reduces the mutex contention from getting a consistent read snapshot as that is done once per transaction rather than once per statement.

不過看了看數據，純粹讀取的部份 RC 會在某些地方快一些，不過整體來說在 MySQL 5.6.26 上的 RR 與 RC 差異真的不算太明顯了...

Amazon Aurora 支援 Reader Endpoint

Amazon Aurora 支援 Reader Endpoint，讓讀的部份可以打散掉：「New Reader Endpoint for Amazon Aurora – Load Balancing & Higher Availability」。

讀的部份比較容易 scale (常見的方式是透過 replication 做到)，而現在很多 database framework (包括各類的 ORM framework) 都支援讀寫分離，這個支援對於系統的 scale 來說幫忙頗大。

不過不知道會不會有 replication lag 的問題，我猜是會有...

Amazon Aurora 支援跨區域 Read Replica

傳統的作法 (自己擁有機房時) 就是在兩個機房中間建立 site-to-site VPN (通常是 IPsec)，然後再用 MySQL 的 replication 接起來，而現在 Amazon Aurora 直接在界面上支援這件事情，可以在網頁上點一點開起來：「New – Cross-Region Read Replicas for Amazon Aurora」。

不過好像沒講到跨區的 VPC 對接設定問題？所以是透過他們自己的 network 接起來？這樣的話流量費用要怎麼算？

MariaDB 讀寫分離的工具：MaxScale

MariaDB 的 MaxScale 軟體提供 MySQL 相容的 proxy interface，可以將後端一群 MySQL server 架構隱藏起來，讓應用程式不需要處理這部份。

而 Percona 的人則介紹 MaxScale 作為讀寫分離的工具：「High availability with asynchronous replication… and transparent R/W split」。

如果你是用有支援讀寫分離的 ORM (像是 Laravel 中的 Illuminate::Database)，由於 ORM library 幫你處理好了，你可以省掉這個工作。

但在其他的情況，像是應用程式沒有原始程式碼，或是只能設一組 server，你就必須透過像 MaxScale 這種軟體來幫你打散負荷量。

Percona 給的範例提供了很多設定檔，應該是改一改就可以動 (當然效能調校是另外要花功夫的事情了)，對於有興趣的人應該可以丟人研究？

PCIe 的 SSD 與 SATA 的比較

LogicMonitor 的人比較了 PCIe SSD 與 SATA SSD，他們在意的重點是 read/write latency 非單純的 throughput：「Device Utilization of PCIe and SATA SSDs」。

文章裡講得很長，把他們找原因的過程寫出來，從 latency 的影響改變到 queue service 的變化：

後來換成 PCIe SSD 後 write latency 從 1.8ms 掉到 0.02ms 左右，大約是兩個零的差距。

另外文章裡也提到了 fio 這個測試工具，找時間來測試看看，熟悉一下...