Kami memiliki server MySQL yang dipasang di dua mesin yang berbeda, server pengujian dan server produksi, kedua windows, yang digunakan oleh aplikasi web.

Masalahnya adalah bahwa ada perbedaan kinerja BESAR di antara dua mesin ketika menjalankan beberapa permintaan (server produksi menjadi yang lebih lambat). Versi MySQL di kedua server adalah sama, bahkan file konfigurasi adalah sama (satu-satunya perbedaan adalah jalur data dan fakta bahwa server produksi tidak mencatat apa pun kecuali kesalahan). Perbedaan dalam kinerja yang saya bicarakan adalah 3 atau 4 kali lipat lebih besar (mis. Kueri di server pengujian dijalankan dalam 0,2 detik, sedangkan server produksi dijalankan dalam 84 detik).

Kueri menyinggung menggunakan banyak klausa dengan "DI MANA [...] DI [...]", yang merupakan pemahaman saya bahwa mereka biasanya sangat lambat dan mereka harus diganti dengan BERGABUNG. Namun, versi MySQL yang kami gunakan adalah 5.6.19, yang mengoptimalkan permintaan itu secara otomatis, itu sebabnya mereka bekerja cepat di server pengujian (dan mereka berada di bagian dari program yang tidak dapat kami ubah sehingga kami tidak dapat mengoptimalkannya secara manual bagaimanapun).

Seperti yang saya katakan, instalasi dan konfigurasi MySQL identik, jadi saya sama sekali tidak tahu di mana masalahnya. Di satu sisi, saya menduga bahwa itu pasti masalah konfigurasi karena program dan DB sama, di sisi lain, ini tidak masuk akal karena konfigurasi identik.

Beberapa data di server:
Server pengujian:

• Intel Core 2 Quad Q9400 @ 2.66GHz
• RAM 8GB
• Windows Server 2008 R2 Standard

Server produksi:

• Intel Xeon E5530 @ 2.40GHz
• RAM 5GB
• Windows Server 2012 R2 Standard

Sunting: Saya lupa mengatakan hal penting: ada lebih banyak pertanyaan yang dieksekusi yang menggunakan klausa "WHERE ... IN" yang terpisah untuk yang "menyinggung". Mereka dieksekusi dengan cepat di kedua mesin, yang menyarankan saya bahwa mereka sedang dioptimalkan dengan benar oleh MySQL. Fakta bahwa beberapa pertanyaan dioptimalkan ketika yang lain tidak adalah misteri bagi saya, JIKA ini adalah masalah yang sebenarnya, yang saya tidak yakin.

Sunting # 2: Ini adalah file konfigurasi untuk kedua server: http://pastebin.ca/2834906

Sunting # 3: Berikut adalah EXPLAIN dari salah satu pertanyaan lambat: https://mariadb.org/ea/v36zj EXPLAIN persis sama baik dalam pengujian dan uji. Query itu sendiri ada di sini: http://pastebin.com/VXgBxXmt Ini telah diformat dengan autoformatter, jadi mungkin tidak terlalu jelas. Seperti yang Anda lihat, ini cukup panjang dan kompleks. Itu tidak dihasilkan oleh tangan, mereka moreless secara otomatis dihasilkan oleh perangkat lunak, yang menggunakan dialek SQL standar dengan beberapa fungsi.

Juga, informasi lebih lanjut: Kami telah memperbaiki masalah sementara dengan mengurangi data di server produksi dan menghapus sebagian besar data lama di DB, yang tidak akan digunakan. Ini bukan solusi, tentu saja, karena kita juga membutuhkan data lama, dan itu akan menjadi masalah di masa depan. DB tidak sebesar itu: DB penuh 1308MB, versi yang dikurangi saat ini dalam produksi adalah 332MB.

UPDATE: ASK ??

Saya pikir saya telah memecahkan masalah. Saya belum mengujinya, karena server produksi sebenarnya sedang digunakan, tetapi masalah yang mungkin adalah parameter "innodb_buffer_pool_size", yang ditetapkan ke 182M. Sebenarnya, baris dalam file config menunjukkan: innodb_buffer_pool_size = 321 yang merupakan kesalahan karena tidak memiliki awalan unit, memberikan nilai yang tidak valid (minimumnya adalah 5242880 menurut dokumen), kemudian meletakkannya di nilai sebelumnya . Nilai ini di server pengujian ditetapkan pada 321M yang diinginkan.

Seperti yang saya katakan, saya belum mengujinya sepenuhnya. Apa yang saya lakukan adalah mengurangi nilai dalam pengujian dan mencoba aplikasi. Semuanya berjalan lebih lambat, dan kueri tertentu yang saya posting dijalankan dalam 3 menit.

Saya telah menguji nilai 3Gb yang lebih waras, yang saya tidak tahu apakah itu ide yang bagus, jadi jika seseorang memiliki komentar tentang nilai ini, saya akan menghargainya.

Kesimpulan saya, "nilai waras" dari 3Gb dan info yang saya gunakan untuk ini berasal dari dua posting ini, terutama yang kedua:

Permintaan MySQL, 2 server serupa, perbedaan waktu eksekusi 2 menit

Seberapa besar seharusnya mysql innodb_buffer_pool_size?

Saya akan memposting hasil "nyata" ketika kami memperbarui nilai-nilai di server produksi.

Terimakasih semuanya.

TERPECAHKAN

Jadi, kami akhirnya menguji ini di prod, dan itu adalah masalah yang saya komentari sebelumnya. Saya meletakkan nilai innodb_buffer_pool_size dalam 321M, yang merupakan nilai yang direkomendasikan oleh vendor SDK yang kami gunakan, meskipun menurut tautan sebelumnya itu harus sekitar 3G untuk DB ukuran dan penggunaan ini.

Namun saya masih ragu: nilai 321 adalah nilai yang tidak valid (terlalu kecil), jadi MySQL mengambil nilai lain. Kecurigaan saya adalah bahwa ia mengambil angka valid sebelumnya, 321M dalam tes, dan 182M dalam produk, karenanya perbedaan kecepatan. Itu hanya karena penasaran, tetapi saya ingin tahu apakah ini benar.

Sekali lagi terima kasih atas bantuannya.

Saya mungkin terbang buta pada yang satu ini, tapi ini dia ...

Dalam pertanyaan dan komentar Anda, Anda menyatakan yang berikut:

Versi MySQL di kedua server adalah sama, bahkan file konfigurasi sama (satu-satunya perbedaan adalah jalur data dan fakta bahwa server produksi tidak mencatat apa pun kecuali kesalahan)

Ya, DB itu sama (sebenarnya dump DB produksi ke dalam DB pengujian).

Hasil serupa: 2.31Gb dengan cara yang stabil

Anda harus memberikan paket EXPLAIN untuk kueri. Karena datanya identik, mungkin tidak perlu.

Ada beberapa hal yang mungkin berbeda

PROSESOR ANDA

Saya mencari Intel Core 2 Quad Q9400 @ 2.66GHz (TEST) dan Intel Xeon E5530 @ 2.40GHz (PROD) dan menemukan perbedaan.

• CPU untuk TEST memiliki 4 utas
• CPU untuk PROD memiliki 8 utas

Anda akan berpikir PROD harus lebih cepat.

Kecepatan bus internal mungkin menjadi hambatan. Saya menduga ini karena TEST memiliki kecepatan bus yang lebih tinggi dan pengganda bus 8. Apa itu pengganda bus ?

Frekuensi internal mikroprosesor biasanya didasarkan pada frekuensi Front Side Bus. Untuk menghitung frekuensi internal, CPU mengalikan frekuensi bus dengan angka tertentu, yang disebut clock multiplier. Penting untuk dicatat bahwa untuk perhitungan CPU menggunakan frekuensi bus aktual, dan frekuensi bus tidak efektif. Untuk menentukan frekuensi bus aktual aktual untuk prosesor yang menggunakan bus laju data ganda (AMD Athlon dan Duron) dan bus laju data empat (semua mikroprosesor Intel mulai dari Pentium 4) kecepatan bus yang efektif harus dibagi 2 untuk AMD atau 4 untuk Intel.

Berdasarkan ini, kecepatan bus internal untuk AMD (TEST) setidaknya 2 kali lebih tinggi dari Intel (PROD).

STATISTIK INDEKS ANDA

Karena Anda memuat TEST dengan data yang sama, satu hal mungkin telah diabaikan. Saya sedang memikirkan statistik indeks. Untuk TEST, statistik indeks akan cukup baru. Untuk PROD, mungkin basi jika tabel yang diindeks telah mengalami banyak INSERT, UPDATE, dan HAPUS.

Menjalankan SELECT pada dua mesin yang berbeda dengan versi mysql identik, konfigurasi mysql identik, dataset identik, dan bahkan perangkat keras identik, dapat dipengaruhi oleh statistik indeks pada tabel yang terlibat.

Saya akan menjalankan ANALYZE TABLE di semua tabel pada PROD dan TEST dan kemudian mencoba membandingkan kinerja.