Penggunaan CPU yang tinggi MySQL [ditutup]

191

Baru-baru ini CPU server saya berjalan sangat tinggi.

Rata-rata beban CPU 13,91 (1 mnt) 11,72 (5 mnt) 8,01 (15 mnt) dan situs saya hanya mengalami sedikit peningkatan traffic.

Setelah menjalankan perintah teratas, saya melihat MySQL menggunakan CPU 160%!

Baru-baru ini saya telah mengoptimalkan tabel dan saya telah beralih ke koneksi persisten. Mungkinkah ini yang menyebabkan MySQL menggunakan CPU dalam jumlah tinggi?

mysql cpu-usage

— Menilai
sumber

Koneksi gigih hampir selalu bukan hal yang tepat untuk digunakan.

— jason

saya akan melepasnya sekarang dan melihat perbedaan karena saya tidak pernah ingat cpu berada di atas 2 sebulan yang lalu!

— Juddling

Server cenderung memiliki lebih dari satu inti. Persen penggunaan CPU dihitung relatif terhadap satu inti, kata lain proses yang menggunakan dua core sepenuhnya akan memiliki penggunaan CPU 200%. Di sini, MySQL menggunakan hingga 100% dari satu inti dan 60% dari inti lainnya. Itu tidak berarti semua CPU habis, kemungkinan besar ia masih memiliki setidaknya dua CPU gratis.

— xaav

CPU yang tinggi hampir selalu berarti pertanyaan yang tidak efisien. Tersebut biasanya diselesaikan melalui pengindeksan yang lebih baik (terutama 'komposit') dan / atau memformulasi ulang kueri.

— Rick James

Jawaban:

265

Pertama, saya katakan Anda mungkin ingin mematikan koneksi yang terus-menerus karena mereka hampir selalu lebih berbahaya daripada baik.

Kedua, saya katakan Anda ingin memeriksa ulang pengguna MySQL Anda, hanya untuk memastikan tidak ada orang yang bisa terhubung dari server jauh. Ini juga merupakan hal keamanan utama untuk diperiksa.

Ketiga saya katakan Anda ingin mengaktifkan MySQL Slow Query Log untuk mengawasi pertanyaan yang membutuhkan waktu lama, dan menggunakannya untuk memastikan Anda tidak memiliki pertanyaan yang mengunci tabel kunci terlalu lama.

Beberapa hal lain yang dapat Anda periksa adalah menjalankan kueri berikut saat beban CPU tinggi:

SHOW PROCESSLIST;

Ini akan menunjukkan kepada Anda setiap kueri yang sedang berjalan atau dalam antrian untuk menjalankan, apa kueri itu dan apa yang dilakukannya (perintah ini akan memotong kueri jika terlalu panjang, Anda dapat menggunakan SHOW FULL PROCESSLIST untuk melihat teks kueri lengkap) .

Anda juga ingin mengawasi hal-hal seperti ukuran buffer, cache tabel , cache kueri , dan innodb_buffer_pool_size (jika Anda menggunakan tabel innodb) karena semua alokasi memori ini dapat memengaruhi kinerja kueri yang dapat menyebabkan MySQL menjadi makan CPU.

Anda mungkin juga ingin memberikan bacaan berikut karena mengandung beberapa informasi yang baik.

Ini juga merupakan ide yang sangat bagus untuk menggunakan profiler. Sesuatu yang dapat Anda aktifkan saat Anda inginkan yang akan menunjukkan kepada Anda apa permintaan aplikasi Anda berjalan, jika ada permintaan duplikat, berapa lama mereka mengambil, dll, dll. Contoh dari sesuatu seperti ini adalah yang saya sedang mengerjakan disebut PHP Profiler tetapi ada banyak di luar sana. Jika Anda menggunakan perangkat lunak seperti Drupal, Joomla atau Wordpress Anda akan ingin bertanya-tanya di dalam komunitas karena mungkin ada modul yang tersedia untuk mereka yang memungkinkan Anda untuk mendapatkan informasi ini tanpa perlu mengintegrasikan apa pun secara manual.

— Steven Surowiec
sumber

terima kasih banyak untuk ini, saya menghapus koneksi persisten dan kemudian mengatur log permintaan lambat. saya membaca log dan sebagian besar pertanyaan berasal dari dua tabel dan tabel tidak diindeks dengan benar! ini hanya sekitar 10 menit tapi inilah hasilnya: Rata-rata beban CPU 0,48 (1 mnt) 0,95 (5 mnt) 2,42 (15 mnt) terima kasih banyak

— Juddling

masalah yang sama, diselesaikan dengan mengindeks tabel yang memperlambat proses, terima kasih Steven dan Juddling

— gabrielem

@Juddling Bisakah Anda menguraikan bagaimana cara mengindeks tabel? Mungkin beberapa tautan? Saya tahu ini sudah lama, tapi saya benar-benar baru dalam hal ini. Maaf dari pertanyaan

— noobish

Mencatat permintaan yang lambat membantu saya menemukan masalah khusus tentang pemanfaatan CPU yang tinggi. Dalam kasus saya, itu adalah plugin Wordpress (ultimate-tag-cloud-widget) yang melakukan kueri mengerikan dengan setiap klik hanya untuk menampilkan tag populer. Ini adalah plugin yang bagus, tetapi perlu ditingkatkan dengan caching dari beberapa jenis (akhirnya saya mengubahnya untuk menyelesaikan masalah saya).

— jkincali

Hal lain yang membantu masalah yang berbeda adalah memodifikasi parameter innodb_buffer_pool_size yang disebutkan di atas. Ketika mencoba mencari penyebab pemanfaatan CPU yang tinggi, saya membaca di suatu tempat bahwa innodb_buffer_pool_size harus setidaknya berukuran file ibdata1, yang terletak di / var / lib / mysql. Tampaknya InnoDB bekerja jauh lebih efisien bila dapat disimpan dalam memori. Ini mungkin sulit dilakukan dalam beberapa situasi karena ibdata1 bisa sangat besar! Itu juga disarankan di suatu tempat untuk memastikan innodb_log_buffer_size adalah 25% dari ukuran innodb_buffer_pool_size.

— jkincali

167

Karena ini adalah pos teratas jika Anda menggunakan atau menggunakan beban CPU MySQL tinggi, saya akan menambahkan jawaban tambahan:

Pada tanggal 1 Juli 2012, lompatan kedua ditambahkan ke waktu UTC saat ini untuk mengkompensasi rotasi bumi yang melambat akibat pasang surut. Saat menjalankan ntp (atau ntpd) detik ini ditambahkan ke jam komputer / server Anda. MySQLd sepertinya tidak menyukai detik tambahan ini pada beberapa OS, dan menghasilkan beban CPU yang tinggi. Perbaikan cepat adalah (sebagai root):

$ /etc/init.d/ntpd stop
$ date -s "`date`"
$ /etc/init.d/ntpd start

— RedPixel
sumber

Karena posting asli sekitar 3 tahun yang lalu, saya ragu itu penyebab masalah poster asli. Tapi itu adalah penyebab masalah saya, dan menyelamatkan saya sekarang - jadi terima kasih! Info lebih lanjut: blog.mozilla.org/it/2012/06/30/…

— Russell G

Masalah & solusi yang sama untuk saya di Ubuntu 12.04. Langkah-langkah untuk menyelesaikan sedikit berbeda: service ntp stop && date -s " date" && service ntp mulai penggunaan CPU MySQL langsung turun dari 50 - 100% ke 0 - 1%

— David Laing

Bisakah ini dieksekusi hanya untuk memastikan? Maksud saya, apakah aman untuk menjalankannya meskipun itu bukan alasannya?

— Muhammad Gelbana

1 Juli 2015 - Saya baru saja mengalami lompatan bug kedua ini pada server AWS EC2 saat ini yang menjalankan Amazon Linux. Gunakan sudo service ntpd stoppada konfigurasi ini.

— Matt van Andel

+1 untuk solusi ini. MySQL saya berjalan pada 50-60% selama berbulan-bulan tanpa alasan, setelah menerapkan solusi ini turun menjadi sekarang semua 0,0-0,3% seperti yang seharusnya. Terima kasih banyak.

— zeeshan

Jika server ini dapat dilihat oleh dunia luar, ada baiknya memeriksa apakah ada banyak permintaan untuk terhubung dari dunia luar (yaitu orang yang mencoba menerobos ke dalamnya)

— Rowland Shaw
sumber

Tidak yakin mengapa ini menarik downvote anonim, mengingat ini telah menjadi penyebab di masa lalu untuk beberapa sistem.

— Rowland Shaw

Saya pikir suara turun adalah karena memiliki MySQL yang dapat dilihat oleh dunia luar bukanlah ide yang baik.

— MikeKulls

@MikeKulls Tidak, ini bukan ide yang baik, karena akan bertindak sebagai target bagi banyak orang untuk mencoba dan mendapatkan entri, yang akan memberikan beban CPU yang tinggi - maka jawaban saya sebagai salah satu alasan yang memungkinkan.

— Rowland Shaw

Aku benci ketika seseorang hanya memilih dan pergi!

— Muhammad Gelbana

1 karena ini benar-benar alasan yang sah untuk MySQL memiliki penggunaan CPU yang tinggi, dan siapa pun yang jawabannya benar-benar membutuhkan informasi ini!

— Chris Browne