Mungkinkah membuat MySQL menggunakan lebih dari satu inti?

Saya telah disajikan dengan beberapa server MySQL khusus yang tidak pernah menggunakan lebih dari satu inti. Saya lebih pengembang daripada DBA untuk MySQL jadi butuh bantuan

Mempersiapkan

Server-servernya lumayan kuat dengan jenis beban OLAP / DataWarehouse (DW):

• Utama: RAM 96GB, 8 core + satu array RAID 10
• Tes: RAM 32GB dengan 4 core
• DB terbesar adalah 540 GB, totalnya sekitar 1.1TB dan sebagian besar tabel InnoDB
• Solaris 10 Intel-64
• MySQL 5.5.x

Catatan: DB terbesar adalah yang direplikasi dari server OLTP DR dan DW dimuat dari ini. Ini bukan DW lengkap: hanya bertahan 6 bulan hingga 6 minggu sehingga lebih kecil dari OLTP DB.

Pengamatan pada server uji

• 3 koneksi terpisah
• masing-masing memiliki bersamaan (dan berbeda) ALTER TABLE...DROP KEY...ADD INDEX
• 3 tabel memiliki baris 2,5, 3,8 dan 4,5 juta
• Penggunaan CPU meningkat hingga 25% (satu inti sudah maksimal) dan tidak lebih tinggi
• 3 ALTER memakan waktu 12-25 menit (satu untuk yang terkecil membutuhkan 4,5)

Pertanyaan

1. Pengaturan atau tambalan apa yang diperlukan untuk memungkinkan lebih dari satu inti digunakan?
   Artinya, mengapa MySQL tidak menggunakan semua core yang tersedia? (seperti RDBMS lainnya)
2. Apakah ini konsekuensi dari replikasi?

Catatan lain

• Saya mengerti perbedaan antara "utas" RDBMS dan "utas" OS
• Saya tidak bertanya tentang segala bentuk paralelisme
• Beberapa variabel sistem untuk InnoDB dan utas bersifat kurang optimal
  (mencari kemenangan cepat)
• Jangka pendek, saya tidak dapat mengubah tata letak disk
• OS dapat di-tweak jika perlu
• Satu ALTER TABLE di meja terkecil membutuhkan waktu 4,5 menit (IMO mengejutkan)

Edit 1

• innodb_thread_concurrency diatur ke 8 pada keduanya. Ya, itu salah tetapi tidak akan membuat MySQL menggunakan banyak core
• innodb_buffer_pool_size adalah 80GB pada primer, 10GB pada tes (contoh lain dimatikan). Ini OK untuk saat ini.
• innodb_file_per_table = ON

Edit 2

• innodb_flush_log_at_trx_commit = 2
• innodb_use_sys_malloc = ON
• innodb_flush_method harus O_DIRECT (tetapi SHOW VARIABLES tidak menunjukkan ini)
• innodb_doublewrite = OFF
• Sistem file = ZFS (Dan sysadmin saya menemukan ini: http://blogs.oracle.com/realneel/entry/mysql_innodb_zfs_best_practices )

Untuk menguji

• innodb_flush_method tidak ditampilkan sebagai O_DIRECT kapan seharusnya
• akan mengikuti pengaturan RolandoMySQLDBA

Beri tahu saya jika saya melewatkan sesuatu yang penting

Tepuk tangan

Memperbarui

Mengubah innodb_flush_method + 3 x pengaturan ulir dalam jawaban RolandoMySQLDBA
Hasil:> 1 inti digunakan untuk pengujian = hasil positif

Saya benar-benar membahas innodb_thread_concurrency dengan Ahli MySQL di konferensi NYC Percona Live pada Mei 2011 .

Saya belajar sesuatu yang mengejutkan: Terlepas dari dokumentasinya, yang terbaik adalah meninggalkan innodb_thread_concurrencypada 0 (infinite concurrency). Dengan begitu, InnoDB memutuskan jumlah terbaik innodb_concurrency_ticketsuntuk membuka untuk pengaturan instance MySQL yang diberikan.

Setelah Anda menetapkan innodb_thread_concurrencyke 0, Anda dapat mengatur innodb_read_io_threadsdan innodb_write_io_threads(keduanya sejak MySQL 5.1.38) ke nilai maksimum 64. Ini harus melibatkan lebih banyak core.

MySQL akan secara otomatis menggunakan banyak inti, sehingga beban Anda sebesar 25% adalah kebetulan ¹ atau kemungkinan kesalahan konfigurasi pada Solaris. Saya tidak akan berpura-pura tahu cara menyetem solaris, tapi di sini ada artikel yang membahas beberapa informasi penyetelan khusus solaris .

Halaman tuning InnoDB telah dirombak di MySQL 5.5, jadi ada beberapa info bagus di sana. Dari tips IO disk InnoDB :

Jika alat teratas Unix atau Windows Task Manager menunjukkan bahwa persentase penggunaan CPU dengan beban kerja Anda kurang dari 70%, beban kerja Anda mungkin terikat dengan disk. Mungkin Anda membuat terlalu banyak komitmen transaksi, atau buffer pool terlalu kecil. Membuat kolam penyangga lebih besar dapat membantu, tetapi jangan atur sama dengan lebih dari 80% memori fisik.

Beberapa hal lain yang perlu diperiksa:

• Mengalihkan innodb_flush_method ke O_DIRECT layak untuk diuji. Jika ini membantu, Anda mungkin perlu me-mount sistem file dengan forcedirectioopsi

• Ubah innodb_flush_log_at_trx_commit dari 1 menjadi 0 (jika Anda tidak keberatan kehilangan detik terakhir pada mysql crash) atau 2 (jika Anda tidak keberatan kehilangan detik terakhir pada OS crash).

• Periksa nilai innodb_use_sys_malloc . Artikel ini memiliki informasi lebih lanjut tentang variabel.

  Pada saat itu, tidak ada perpustakaan pengalokasi memori yang disetel untuk CPU multi-core. Oleh karena itu, InnoDB mengimplementasikan pengalokasi memorinya sendiri dalam subsistem mem. Pengalokasi ini dijaga oleh satu mutex, yang dapat menjadi hambatan.

  Tetapi ada beberapa peringatan di akhir bagian tentang apa artinya menghidupkan variabel (diaktifkan secara default di 5.5).

  Perhatikan bahwa ketika pengalokasi memori InnoDB dinonaktifkan, InnoDB akan mengabaikan nilai parameter innodb_additional_mem_pool_size.

• Ada kemungkinan bahwa replikasi menyebabkan beberapa masalah. Saya menyadari Anda tidak tertarik dengan paralelisme, tetapi dari deskripsi worklog ini :

  Saat ini, replikasi tidak skala dengan baik pada mesin multi-core. Single slave thread mengeksekusi peristiwa replikasi satu per satu dan mungkin tidak mengatasi beban yang dihasilkan oleh beberapa koneksi klien bersamaan yang dilayani oleh CPU server master terpisah.

Pada akhirnya, InnoDB mungkin bukan mesin terbaik untuk penyimpanan dataware, karena operasi berbasis disk yang terjadi. Anda dapat mempertimbangkan mengubah tabel datawarehouse menjadi Compressed MyISAM .

¹ _{Secara kebetulan, maksud saya ada bottleneck yang mencegah beban Anda meningkat di atas 25%, tetapi tidak selalu merupakan masalah inti tunggal yang dipaksakan.}

Koneksi tunggal hanya akan menggunakan inti tunggal. (Oke, InnoDB menggunakan utas lain, karenanya inti, untuk beberapa pemrosesan I / O, tetapi itu tidak signifikan.)

Anda memiliki 3 ALTER, jadi Anda tidak menggunakan nilai lebih dari 3 inti.

Sayangnya, bahkan PARTISI tidak menggunakan banyak core.

Sampai saat ini, banyak koneksi akan maksimal setelah 4-8 core. Xtradb Percona (termasuk dalam MariaDB) lebih baik menggunakan banyak core, tetapi masih hanya satu per thread. Mereka maksimal sekitar 32 core.

IMHO dan dalam use case yang dijelaskan, Anda tidak akan pernah menggunakan lebih dari satu inti. Alasannya adalah bahwa beban kerja Anda terikat IO, bukan terikat CPU. Karena 3 koneksi Anda membuat Indeks baru, masing-masing dari mereka perlu membaca seluruh tabel dari disk: inilah yang memerlukan waktu, bukan menghitung Indeks.

Pertimbangkan bahwa bottleneck Anda bisa menjadi kinerja IO sistem file Anda.

Selain pengaturan yang disarankan oleh @RandooMySQLDBA , saya juga mengatur noatimepengaturan mount /etc/fstabuntuk partisi yang menyimpan direktori data mysql saya ( /data01/mysqldalam kasus saya, dengan /dev/sdb1mount ke /data01).

Secara default linux mencatat waktu akses untuk SETIAP disk membaca atau menulis yang secara negatif mempengaruhi kinerja IO, terutama untuk aplikasi IO tinggi seperti database. Ini berarti bahwa bahkan membaca data dari file memicu penulisan ke disk ... WAT!

Untuk menonaktifkan ini, tambahkan noatimeopsi mount /etc/fstabuntuk titik mount yang diinginkan sebagai berikut (contoh dalam kasus saya):

/dev/sdb1  /data01  ext4  defaults,noatime  0  2

Kemudian pasang kembali partisi:

mount -o,remount /data01

Ini harus meningkatkan kinerja aplikasi baca / tulis menggunakan partisi itu. TAPI ... tidak ada yang mengalahkan semua data Anda dalam memori.