innodb_flush_method=O_DIRECT vs O_DSYNC 對帶有 LVM 磁碟分區的 ext3 的性能影響

在我的一個生產環境中，我們有兩個實例在 RedHat 集群上執行，其中一個生產實例與集群關聯。

我們有 125G 主記憶體，instance1 佔用 24G InnoDB 緩衝池，instance2 佔用 12G，與 RedHat 集群無關。數據和事務日誌都位於帶有 ext3 文件系統的 LVM 磁碟分區上。

為了提高性能和更好的 I/O 吞吐量，我決定更改innodb_flush_method為O_DIRECT.

參考 MySQL 文件：

當 InnoDB 數據和日誌文件位於 SAN 上時，已發現設置innodb_flush_method為可將簡單語句的O_DIRECT性能降低三倍。SELECT

關於高性能 MySQL 版本 2 和 3，它指出 InnoDB 開發人員發現使用innodb_flush_method=O_DSYNC. O_SYNCandO_DSYNC類似於fsync()and fdatasync()：O_SYNC同步數據和元數據，而O_DSYNC只同步數據。

如果這一切看起來像是很多沒有建議的解釋，這裡是建議：

如果您使用類 Unix 作業系統並且您的 RAID 控制器具有電池供電的寫入記憶體，我們建議您使用O_DIRECT. 如果沒有，根據您的應用程序，預設或O_DIRECT可能是最佳選擇。

通過Google搜尋，我得到了這個基準報告：on O_DSYNCvsO_DIRECT

基準報告：
===================
1B 行複雜事務測試，64 個執行緒

* SAN O_DIRECT：讀/寫請求：31560140（每秒 8766.61）
* SAN O_DSYNC：讀/寫請求：5179457（每秒 1438.52）
* SAN fdatasync：讀/寫請求：9445774（每秒 2623.66）
* 本地磁碟 O_DIRECT：讀/寫請求：3258595（每秒 905.06）
* 本地磁碟 O_DSYNC：讀/寫請求：3494632（每秒 970.65）
*本地磁碟fdatasync：讀/寫請求：4223757（每秒1173.04。

但是，O_DIRECT禁用作業系統級別的記憶體，可以禁用雙重記憶體，這顯示了更好的 I/O 吞吐量。

O_DIRECT與而不是一起去O_DSYNC好嗎？這兩個選項有點令人困惑。哪個選項可以顯示更好的 I/O 吞吐量和性能增強，而不會對數據、讀/寫產生任何影響，尤其是在生產中？根據您的個人經驗有什麼更好的建議嗎？

我可以在文章中看到 Rolando 更新：

這兩個參數仍然存在輕微的混淆。在哪裡我可以看到大多數使用的生產配置模板O_DIRECT，我還沒有看到任何推薦的地方O_DSYNC。

系統

• MySQL 5.1.51-企業-gpl-pro-log
• 紅帽企業 Linux 伺服器 5.5 版
• 帶有 Raid 控制器的 DELL DRAC 具有電池回寫記憶體 512MB
• 帶電池備份單元 (BBU) 的戴爾 PERC 控制器 H700。

附加資訊

mysql> 顯示變數，如“innodb_thread_concurrency”；

+---------------------------+-------+
| 變數名 | 價值 |
+---------------------------+-------+
| innodb_thread_concurrency | 96 |
+---------------------------+-------+
一組中的 1 行（0.00 秒）

mysql> 顯示變數，如“innodb_read_io_threads”；
空集（0.00 秒）

mysql> 顯示變數，如“innodb_write_io_threads”；
空集（0.00 秒）

我們使用的是預設外掛，所以我發布了來自 InnoDB 狀態的資訊：

mysql> SELECT * FROM Plugins WHERE PLUGIN_NAME LIKE '%innodb%' AND PLUGIN_TYPE LIKE 'STORAGE ENGINE'\G
****************************** 1. 行 ************************ *******
PLUGIN_NAME：InnoDB
外掛版本：1.0
外掛狀態：活動
PLUGIN_TYPE：儲存引擎
PLUGIN_TYPE_VERSION: 50151.0
外掛庫：空
PLUGIN_LIBRARY_VERSION：空
PLUGIN_AUTHOR：Innobase OY
PLUGIN_DESCRIPTION：支持事務、行級鎖定和外鍵
PLUGIN_LICENSE：GPL
一組中的 1 行（0.00 秒）

早在 2009 年 1 月 21 日，Peter Zaitsev 在mysqlperformanceblog.com上發表了以下聲明

作為行動呼籲——我當然希望有人看看 EXT3 是否可以在這方面得到修復，因為它是迄今為止 Linux 最常見的文件系統。還值得研究是否可以在 MySQL 端做某事——如果不使用 fsync 會有所幫助，可能會打開帶有O_DSYNC標誌的 binlog 嗎？sync_binlog=1或者可能是 binlog 預分配會是一個很好的解決方案。

到目前為止，我知道沒有人接觸過這個問題。O_DSYNC預設情況下，這不是一個吸引人的前景，但確實可以容納未經真正驗證的更快寫入。這就是為什麼周圍有這麼多炒作O_DIRECT。

我可以告訴你沒有安裝 InnoDB 外掛。使用 InnoDB 外掛，應該存在幾個變數。

您應該通過以下兩種方式之一升級 InnoDB：

• 升級到 MySQL 5.5（所有 InnoDB 外掛增強都是 MySQL 5.5 的一部分）
• 升級 InnoDB 外掛

完成此操作後，您可以增強 InnoDB 以

• 訪問更多 CPU 和核心
• 增加讀寫I/O執行緒
• 擴展 I/O 容量（這對於不同的儲存介質尤其需要）

以下是我過去發布的有關您可以為此更改的設置的文章：

• Sep 12, 2011:可以讓 MySQL 使用多個核心嗎？
• Sep 20, 2011:多核和 MySQL 性能
• Apr 26, 2012: CPU 性能與數據庫伺服器有關嗎？
• Mar 16, 2012:在 Debian 上使用多個核心進行單個 MySQL 查詢

我一直認為O_DIRECT性能更好，因為它可以防止雙重緩衝。此外，前提是您擁有帶電池支持的寫入記憶體的硬體 RAID。當然，這也取決於工作量，無論您是 READ 還是 WRITE 繁重。

另外，專家的問題是：額外的呼叫fsync()會O_DIRECT導致整體性能明顯下降，還是可以忽略不計？我還沒有看到基準顯示這一點。

另外請注意，Percona 啟用了 set 的功能innodb_flush_method=ALL_O_DIRECT，它不僅在 InnoDB 數據文件上提供直接 I/O，而且同時在 InnoDB 事務日誌上提供直接 I/O。

引用自：https://dba.stackexchange.com/questions/23943