Tag: xfs

Dropbox 的 non-ext4 支援回鍋

Dropbox 去年的時候拔掉非 ext4 檔案系統的支援，被罵翻也不鳥 (參考「Linux 版的 Dropbox 在十一月後將只支援 ext4...」)，結果現在又回來支援了：「Dropbox Brings Back Support For ZFS, XFS, Btrfs And eCryptFS On Linux」。

出自 beta 版的說明「Beta Build 77.3.127」這邊：

Add support for zfs (on 64-bit systems only), eCryptFS, xfs (on 64-bit systems only), and btrfs filesystems in Linux.

不過我不是因為這個而搬走 (因為我用 ext4)，反而是在對免費版限制時跳走：「Dropbox 免費版限制三個裝置更新...」。

當初用 X-attrs 當理由，看起來是有人離職了所以就加回來...

MySQL 的 binlog 對效能的影響

Percona 的 CTO Vadim Tkachenko 在比較 InnoDB 與 MyRocks 時意外發現了 binlog 會影響不少效能穩定性，再加上 MySQL 8.0 有改變 binlog 相關的預設值，所以他後續花了不少時間測試，寫了兩篇關於 binlog 對於 MySQL 效能的影響：「How Binary Logs (and Filesystems) Affect MySQL Performance」與「How Binary Logs Affect MySQL 8.0 Performance」。

第一篇是想要知道在 Percona Server 5.7 上開 binlog 的影響，做出來後可以看到明顯的效能波動 (因為 binlog 導致 flush 時效能暴跌)：

而其中的 workaround 就是調整 flush 參數，讓他比較頻繁的小量寫入，而不是突然要寫很多資料。這樣一來對平均效能也許比較差，但對前端應用衝擊會比較小：

在測試可以看到 sync_binlog=1000 是個妥協點。各單位要自己去找出適合的數字：

The strict setting also comes with noted performance penalties. I will also test sync_binlog=1000 and sync_binlog=10000, which means perform synchronous writes of binary logs every 1000 and 10000 transactions, respectively.

另外有測試 ext4 與 XFS 是否有影響，就測試的結果看起來 ext4 比 XFS 好一些，但差距有限：

第二篇則是拿 MySQL 8.0 與 Percona Server 5.7 比較，可以發現在 MySQL 8.0 開啟 binlog 時有時會有不少的效能損失：

It seems that binary logs have quite an effect MySQL 8.0, and we see up to a 30% performance penalty as opposed to the 13% for Percona Server for MySQL 5.7.

雖是推銷一下自家產品在這塊還不錯 XD

Mobile01 的 Ryan 換 InnoDB 的筆記與心得

沒記錯的話，Mobile01 應該是去年暑假左右從 MyISAM 換成 InnoDB 的？一切的起頭應該是蔣大「現在SSD硬碟可以拿來跑資料庫嗎?」這篇。

另外同場加映，使用 Percona 的工具讓管理上更方便：

MyISAM 是 MySQL 5.0 與 5.1 預設的 storage engine (到 5.5+ 預設的 storage engine 改成 InnoDB)，讀取的效能相當好，但總是有些問題。

當時剛好有機會跟蔣大與 Ryan 聊到當時 Mobile01 遇到的問題，問了一些細節後感覺上是 MyISAM 的問題，就提了 MyISAM 與 InnoDB 的優缺點比較，以及幾個 InnoDB 的 High Availability 的解決方案 (晚上就算設備出問題也不用擔心要爬起來救機器)：

  • MyISAM 的讀寫互斥、寫入也是互斥。當有資料在讀取時無法更改資料庫內容，而有寫入時其他人不能讀取。另外同時間只能有一個人寫入。(有少數操作是例外，像是 bulk insert，這邊跳過)
  • MyISAM 不是 crash-safe storage engine。機器總是有機會爛掉，這時候除了重開機的時間外，還需要有修 table 的時間，對於網站的 uptime 比較痛。

這兩點是當時 Mobile01 遇到最痛的問題：用 iostat 看起來 I/O 明明就沒有滿，但就是會卡 SQL query，而當機後修資料庫的時間又很長。

一個是已經在業界驗證很久的解決方案 XFS + DRBD + Heartbeat，當機器發生問題時的 downtime 從 30secs 到五分鐘 (依照資料性質與大小而有差異，在切換上線後有資料庫的熱機問題)。

另外一個是當時還很新的 Percona XtraDB Cluster，可以避免資料庫的熱機問題，不過技術很新。

後來 Mobile01 用 RAID 10 的硬體，軟體的部份用 Debian + XFS + DRBD + Heartbeat 跑 Percona Server 的 XtraDB (InnoDB 的加強版)，先用 VM 做了 PoC (直接砍掉 mysqld，或是直接關掉 VM 之類的，測試整個機制夠不夠自動化)，然後就上線了 :p

記得上線那幾天跟 Ryan 聊，好像效果還不錯吧...

利用 Journal filesystem 與 Double write buffer 改善 InnoDB 寫入效能

Percona 的「How to improve InnoDB performance by 55% for write-bound loads」這篇在討論 Journal filesystem 以及 InnoDB 的 Double write buffer。

先講文章內的結論。

在 ext4 上開啟 Journal filesystem 功能後並且關掉 InnoDB 的 Double write buffer 後，資料的安全性不受影響，但效能上升非常多。而與目前常用的 XFS 比較起來也是領先不少。

要注意的是，這邊的數據是資料大小小於記憶體大小時 tpcc-mysql 的執行數據。

原文還有探討其他的狀況，像是 InnoDB 與 MyISAM 混用的問題，有用到的人應該自己去看看原文。

而目前在公司用 XFS 已經用習慣而且相當穩定，但該來花時間投資在 ext4 了，常常可以看到 ext4 很不錯之類的消息。