it-swarm.asia

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

Mendirikan

Servernya lumayan kuat dengan jenis beban OLAP/DataWarehouse (DW):

  • Utama: RAM 96GB, 8 core + satu array RAID 10
  • Tes: 32GB RAM 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 sini. Ini bukan DW lengkap: hanya bertahan 6 bulan hingga 6 minggu sehingga lebih kecil daripada 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?
    Yaitu, mengapa MySQL tidak menggunakan semua core yang tersedia? (seperti RDBMS lainnya)
  2. Apakah itu 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 diubah jika diperlukan
  • 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 primary, 10GB pada tes (instance lain dimatikan). Ini OK untuk saat ini.
  • innodb_file_per_table = ON

Edit 2

Untuk mengetes

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

Beri tahu saya jika saya melewatkan sesuatu yang penting

Bersulang

Memperbarui

Mengubah innodb_flush_method + 3 x pengaturan thread dalam jawaban RolandoMySQLDBA
Hasil:> 1 inti yang digunakan untuk tes = hasil positif

136
gbn

Saya benar-benar mendiskusikan 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 pergi innodb_thread_concurrency pada 0 (konkurensi tak terbatas). Dengan begitu, InnoDB memutuskan jumlah terbaik innodb_concurrency_tickets untuk membuka untuk pengaturan instance MySQL yang diberikan.

Setelah Anda mengatur innodb_thread_concurrency hingga 0, Anda dapat mengatur innodb_read_io_threads dan innodb_write_io_threads (keduanya sejak MySQL 5.1.38) hingga nilai maksimum 64. Ini harus melibatkan lebih banyak core.

130
RolandoMySQLDBA

MySQL akan secara otomatis menggunakan banyak core, sehingga beban Anda sebesar 25% adalah kebetulan1 atau potensi kesalahan konfigurasi pada Solaris. Saya tidak akan berpura-pura tahu cara menyetel solaris, tapi inilah artikel yang membahas beberapa informasi tuning khusus-solaris .

Halaman tuning InnoDB telah diberi perbaikan di MySQL 5.5, jadi ada beberapa info bagus di sana. Dari disk InnoDB IO kiat :

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 terlalu banyak melakukan transaksi, atau buffer pool terlalu kecil. Membuat kumpulan buffer lebih besar dapat membantu, tetapi jangan atur sama dengan lebih dari 80% memori fisik.

Beberapa hal lain yang perlu diperiksa:

  • Mengganti innodb_flush_method ke O_DIRECT patut diuji. Jika ini membantu, Anda mungkin perlu me-mount sistem file dengan opsi forcedirectio

  • 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 pada 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 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 .

1Secara kebetulan, maksud saya ada bottleneck yang mencegah beban Anda meningkat di atas 25%, tetapi tidak harus menjadi masalah inti tunggal yang dipaksakan.

31
Derek Downey

Catatan: Jawaban ini adalah tentang koneksi tunggal menggunakan beberapa inti. Pertanyaan OP itu ambigu; itu salah berasumsi bahwa MySQL secara keseluruhan tidak dapat menggunakan lebih dari satu inti. Jawaban lain dengan benar menunjukkan bahwa 3-Alter test case benar-benar terikat I/O, karenanya gagal membuktikan pertanyaan Judul.

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, beberapa 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.

(Pembaruan pada tahun 2015 :) Beberapa koneksi dengan 5,6 maxes sekitar 48 core. 5.7 berjanji untuk menjadi lebih baik. (Demikian kata tolok ukur Oracle.) Tetapi masih tidak menggunakan beberapa core untuk satu koneksi.

Pembaruan (setelah pergi ke OpenWorld Oracle): versi baru 8.x tidak akan memiliki paralelisme.

Pembaruan lebih lanjut - 8.0.17 memiliki kasus di mana ia akan menggunakan banyak inti pada beberapa kueri yang dipilih. (Yaitu, jangan bersemangat.)

17
Rick James

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

10
jfg956

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

Selain pengaturan disarankan oleh @RolandoMySQLDBA , saya juga mengatur noatime mount pengaturan di /etc/fstab untuk partisi yang menyimpan direktori data mysql saya (/data01/mysql dalam kasus saya, dengan /dev/sdb1 dipasang ke /data01).

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

Untuk menonaktifkan ini, tambahkan opsi noatime mount di /etc/fstab untuk titik pemasangan 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.

9
OkezieE