Category: MySQL

MySQL 的 Thread Pool (Percona 版本) 實測

MySQL Thread Pool 的介紹可以參考 Percona 的文章：，以及 DK 的介紹：MySQL 上的 Thread Pool…

一言以蔽之：資源使用量有減少，但看不出明顯的效能改善，可能是負載還不夠大。

MySQL Thread 數量（開啟 Thread Pool 前）：

MySQL Thread 數量（開啟 Thread Pool 後）：

System Thread 數量（開啟 Thread Pool 前）：

System Thread 數量（開啟 Thread Pool 後）：

可以看到在同樣約 2000 個 MySQL Thread 的情況下，開啟 Thread Pool 的 System Thread 數量只有約 200 個；開啟前約需要 3000 個 Thread。兩張圖是使用配備完全相同的兩台機器測試的。

Galera Cluster 的 gcache.size 設定

gcache.size 的大小會影響 Node 加入 Cluster 時，需不需要完整複製資料。如果資料更動程度過大，在 gcache 裡面已經找不到更動部份的話，就需要完整複製資料；反之則可以直接 apply gcache 裡面的變更。Understanding gcache in Galera 很詳細的說明了 gcache 的用途。

gcache.size 的預設值是 128MB。查了一下資料，是使用 MMAP 的方式來應用 ((http://www.percona.com/files/presentations/percona-live/nyc-2012/PLNY12-galera-cluster-best-practices.pdf))，所以可以盡量設定大一些。雖然 mysqld 看起來會很肥，但實際上是吃不到那麼多記憶體的。我們是設定成 8G。

利用 Percona Playback warm-up MySQL 資料庫…

Percona Playback 是一套可以將事先記錄下來的 SQL Query Log 在指定的 MySQL Server 上重作一次的工具，目前最新的版本是 0.5，支援讀取 slow query log 或是 tcpdump capture file。Percona 標榜可以完全按照 Query Log 的 Pattern （包含 thread concurrency，query 所花的時間等等）來重作一次 Query，不過測試的結果還是有點落差。

首先先在 Production 的 Server 上面紀錄 Query Log。因為 Percona Playback 0.5 的 Slow Query Reader 是爛的（bug 1035217），所以只能用 tcpdump：
tcpdump -w log.dump dst port 3306 and dst ip 192.168.1.1

記錄到足夠長度的 log 之後，把 log 放到要測試的 MySQL 機器上，開始執行 percona playback。要注意的是，所有的 Log （包含 UPDATE, DELETE, INSERT 等等會修改資料庫內容的 Query）都會被執行，如果要在 Slave 上跑的話，記得要事先濾掉，才不會造成 Master Slave 不同步的狀況。
percona-playback --input-plugin=tcpdump --tcpdump-filelog.dump --tcpdump-mode=fast --mysql-host=127.0.0.1 --mysql-username=root --mysql-schema=mydb

官方文件是使用 --tcpdump-mode=accurate，速度慢很多，使用 --tcpdump-mode=fast 會快不少。

Percona 的 MySQL Indexing: Best Practices

連結在這：http://www.percona.com/webinars/2012-08-15-mysql-indexing-best-practices。

裡面除了介紹 MySQL Index 的種類與運作方式以外，也提到了「正確」的下 Index 的方法。由於 Index 會影響寫入的速度，並不是下愈多 Index 就越好的，而是應該視應用的 Performance critical query 的狀況來下適當的 Index。推薦會碰到 Database 的人（包含 netadmin 與 developer）都要去看看。

MySQL 5.1 GA

雖然說已經 Generally Available，PIXNET已經踩到好幾次地雷了……
除了 InnoDB 有用錯Index的情形，甚至還有吃到 signal 11就再起不能的事 Orz

如果你現在有空機器，可以試試看 MySQL 5.1 比 5.0 好的 Performance (尤其是 SMP)
而 5.1 的 MyISAM 的表現跟穩定性也不錯。
但是如果你用的是InnoDB，請以alpha的態度對待5.1.30 GA……

Mtron SSD…

最近事忙，忘了上來寫…

大約一個月之前，PIXNET 買的 Memoright 有一顆發生故障，硬碟直接從 OS 端消失，完全看不到了 XD
重開之後，BIOS也抓不到。懷疑是 SATA 連接線的問題，所以重新插了一次，就 OK 了，用到目前還沒有中地雷。
結果大概一週前， Mtron MSP-SATA70 32G 也掛了一顆 XD
Linux 抱怨寫入會有 Error，於是也重開機，重接線，結果運氣不好，還是會有 Error。現在這顆 SSD 已經飄洋過海回韓國檢查了…

MySQL on SSD 的測試之一

最近 PIXNET 測試了另外三款 SSD（Mtron 3000、Mtron 1000、MemoRight MR25.2-032）跑 MySQL 的效能，並且跟 Mtron 7000 系列做了比較。之前測試的 Mtron 7000 系列資料可以在這裡與這裡找到。

以下的測試環境，除了 Mtron 1000 系列是使用 Intel E5410 的 CPU 以外，其他的環境都是 8-way E5450 CPU、12G RAM 的 Debian Linux，跑 MySQL 5.1 Slave，用 MyISAM 當 backend。最大的 MyISAM Table 大概有 3GB。

  • Mtron 3000 系列：實際使用的時候，感覺的出來上跟 Mtron 7000 系列有差。在測試環境中，對讀取來說，到 CPU Bound 的時候，IO 大概使用了 70%。平均 MySQL 的 QPS (Query Per Second)約 5000~6000。對大量的寫入（同時也有讀取）來說，即使沒到 CPU Bound（大概 在 3000 qps），IO 會滿載。
  • Mtron 1000 系列：需要 slow start。使用上的感覺跟 SCSI 15krpm 兩顆硬碟作成的 RAID 0 差不多，讀取比 SCSI 硬碟快，但是寫入比較慢。在測試環境中，到 IO Bound 的時候大約可以達到 4000 qps。
  • MemoRight MR25.2-032：在測試環境中，到 CPU bound 時，IO usage 約 45%，平均 QPS 大約 6000 上下。iostat 裡面顯示的 iowait% 比較高，大約是 6%，而 Mtron 大概 1%。同時有讀取與寫入的時候，Memoright 的讀取比 Mtron 差。當 Mtron 7000 跟 3000 的 IO Usage 是 10 % 的時候，Memoright 的 IO usage 大概 35%。遇到對大量的寫入（同時也有讀取）來說，
    Memoright 的 IO usage 大概 90%，Mtron 3000 大概 100 %，Mtron 7000 大概 50%。

目前我們正在想辦法取得 STEC 與 Ritek 的 SSD 來測試，如果有推薦的廠商也歡迎留言。

MySQL on Mtron SSD 之二

我們把 E5410 換成 E5450 再做了一次測試，發現這次還是卡在 CPU Bound，但是比起 E5410 來說有效能上的改進（同樣是實際上線，E5410 的 qps 極限是 8000，平均是 4000 左右；E5450 極限也是 8000，但是平均可以到 5000）。接著我們調整了 thread_concurrency 與 thread_cache_size 之後，平均 qps 可以到 6000。

另外，這次發現大概有 40% 的 CPU Time 被 system 吃掉了。有沒有對 Linux 比較熟的長輩可以教一下怎麼看這些 CPU 是被用到哪裡去了？