innodb_flush_method = O_DIRECT vs dampak kinerja O_DSYNC pada ext3 dengan partisi disk LVM

Di salah satu lingkungan produksi saya, kami memiliki dua instance yang berjalan di cluster RedHat, dengan satu instance produksi yang terkait dengan cluster.

Kami memiliki memori utama 125G dengan kolam buffer InnoDB 24G ditempati oleh instance1 & 12G ditempati oleh instance2, yang tidak terkait dengan cluster RedHat. Log data dan transaksi terletak di partisi disk LVM dengan sistem file ext3.

Untuk meningkatkan kinerja dan lebih baik I / O throughput yang saya telah memutuskan untuk perubahan innodb_flush_methoduntuk O_DIRECT.

Dengan mengacu pada dokumentasi MySQL:

Di mana data InnoDB dan file log berada di SAN, telah ditemukan bahwa pengaturan innodb_flush_methoduntuk O_DIRECTdapat menurunkan kinerja SELECTpernyataan sederhana dengan faktor tiga.

Mengacu pada kinerja tinggi MySQL Ver 2 dan 3, itu menyatakan bahwa pengembang InnoDB menemukan bug dengan menggunakan innodb_flush_method=O_DSYNC. O_SYNCdan O_DSYNCmirip dengan fsync()dan fdatasync(): O_SYNCmenyinkronkan data dan metadata, sedangkan O_DSYNCmenyinkronkan data saja.

Jika itu semua tampak seperti banyak penjelasan tanpa saran, inilah sarannya:

jika Anda menggunakan sistem operasi mirip Unix dan pengontrol RAID Anda memiliki writecache yang didukung baterai, kami sarankan Anda menggunakannya O_DIRECT. Jika tidak, apakah default atau O_DIRECTmungkin akan menjadi pilihan terbaik, tergantung pada aplikasi Anda.

Dengan googling, saya mendapat laporan benchmark ini : di O_DSYNCvs.O_DIRECT

Laporan Bench Mark:
===================
Tes Transaksional Kompleks 1B Baris, 64 utas

 * SAN O_DIRECT: permintaan baca / tulis: 31560140 (8766,61 per detik)
 * SAN O_DSYNC: permintaan baca / tulis: 5179457 (1438,52 per detik)
 * SAN fdatasync: permintaan baca / tulis: 9445774 (2623,66 per detik)
 * Local-disk O_DIRECT: permintaan baca / tulis: 3258595 (905,06 per detik)
 * O_DSYNC disk lokal: permintaan baca / tulis: 3494632 (970,65 per detik)
 * Local-disk fdatasync: permintaan baca / tulis: 4223757 (1173,04 per detik.

Namun, O_DIRECTmenonaktifkan cache level OS, di mana cache ganda dapat dinonaktifkan yang menunjukkan beberapa throughput I / O yang lebih baik.

Apakah lebih baik pergi dengan O_DIRECTdaripada O_DSYNC? Kedua opsi ini agak membingungkan. Opsi mana yang dapat menunjukkan throughput I / O yang lebih baik dan peningkatan kinerja tanpa berdampak pada data, baca / tulis terutama dalam produksi? Adakah saran yang lebih baik berdasarkan pengalaman pribadi Anda?

Saya dapat melihat Rolando Update di pos :

Masih ada sedikit kebingungan pada kedua parameter ini. Di mana saya bisa melihat sebagian besar templat konfigurasi produksi menggunakan O_DIRECT, saya belum melihat ada rekomendasi O_DSYNC.

Sistem

• MySQL 5.1.51-enterprise-gpl-pro-log
• Server Red Hat Enterprise Linux merilis 5.5
• DELL DRAC dengan Raid Controller memiliki baterai untuk menulis cache kembali 512MB
• Dell PERC mengendalikan H700 dengan unit cadangan baterai (BBU).

Informasi tambahan

mysql> tampilkan variabel seperti 'innodb_thread_concurrency'; 

+ --------------------------- + ------- +
| Variable_name | Nilai |
+ --------------------------- + ------- + 
| innodb_thread_concurrency | 96 |
+ --------------------------- + ------- + 
1 baris dalam set (0,00 dtk) 

mysql> tampilkan variabel seperti 'innodb_read_io_threads'; 
Set kosong (0,00 dtk) 

mysql> tampilkan variabel seperti 'innodb_write_io_threads'; 
Set kosong (0,00 dtk)

Kami menggunakan plugin default, jadi saya telah memposting info dari status InnoDB:

mysql> PILIH * DARI Plugin DI MANA PLUGIN_NAME SEPERTI '% innodb%' DAN PLUGIN_TYPE SEPERTI 'STORAGE ENGINE' \ G
**************************** 1. baris ******************** *******
           PLUGIN_NAME: InnoDB
        PLUGIN_VERSION: 1.0
         PLUGIN_STATUS: ACTIVE
           PLUGIN_TYPE: STORAGE ENGINE
   PLUGIN_TYPE_VERSION: 50151.0
        PLUGIN_LIBRARY: NULL
PLUGIN_LIBRARY_VERSION: NULL
         PLUGIN_AUTHOR: Innobase OY
    PLUGIN_DESCRIPTION: Mendukung transaksi, penguncian level baris, dan kunci asing
        PLUGIN_LICENSE: GPL
1 baris dalam set (0,00 dtk)

Kembali pada 21 Januari 2009, Peter Zaitsev menyatakan yang berikut di mysqlperformanceblog.com

Sebagai ajakan untuk bertindak - saya pasti ingin seseorang untuk melihat apakah EXT3 dapat diperbaiki dalam hal ini karena sejauh ini sistem file yang paling umum untuk Linux. Penting juga untuk menyelidiki apakah sesuatu dapat dilakukan di sisi MySQL - mungkin membuka binlog dengan O_DSYNCflag jika sync_binlog=1alih-alih menggunakan fsync akan membantu? Atau mungkin pra-alokasi binlog akan menjadi solusi yang baik.

Sampai sekarang, saya tahu tidak ada yang menyentuh masalah ini. O_DSYNCsebagai default bukan prospek yang menarik tetapi mengakomodasi penulisan lebih cepat yang tidak benar-benar diverifikasi. Itu sebabnya ada begitu banyak hype di sekitar O_DIRECT.

Saya dapat memberitahu Anda bahwa Plugin InnoDB tidak diinstal. Dengan Plugin InnoDB, beberapa variabel harus ada.

Anda harus meningkatkan InnoDB dengan salah satu dari dua cara:

• Tingkatkan ke MySQL 5.5 (Semua peningkatan Plugin InnoDB adalah bagian dari MySQL 5.5)
• Mutakhirkan Plugin InnoDB

Setelah melakukannya, Anda dapat meningkatkan InnoDB menjadi

• akses lebih banyak CPU dan Core
• tingkatkan membaca dan menulis utas I / O
• skala kapasitas I / O (ini terutama diperlukan untuk media penyimpanan yang berbeda)

Berikut ini tulisan lama saya tentang pengaturan yang dapat Anda ubah untuk ini:

• Sep 12, 2011: Kemungkinan untuk menggunakan MySQL lebih dari satu inti?
• Sep 20, 2011: Multi core dan Kinerja MySQL
• Apr 26, 2012: Apakah kinerja CPU relevan untuk server basis data?
• Mar 16, 2012: Menggunakan beberapa core untuk satu permintaan MySQL di Debian

Saya selalu mendapat kesan bahwa O_DIRECTkinerja lebih baik karena mencegah buffering ganda. Juga, asalkan Anda memiliki perangkat keras RAID dengan cache tulis yang didukung baterai. Tentu saja, itu juga tergantung pada beban kerja, apakah Anda BACA atau MENULIS berat.

Juga, pertanyaan untuk para ahli: apakah panggilan tambahan fsync()untuk O_DIRECTmenyebabkan penurunan nyata dalam kinerja keseluruhan, atau apakah diabaikan? Saya belum melihat benchmark menunjukkan ini.

Juga, perhatikan bahwa Percona telah mengaktifkan kemampuan untuk mengatur innodb_flush_method=ALL_O_DIRECT, yang menyediakan I / O langsung tidak hanya pada file data InnoDB, tetapi juga pada log transaksi InnoDB pada saat yang sama.