Kebocoran memori MySQL dan masalah swap perlu disiasat dari konfigurasi, sumber sistem, tanda kebocoran memori dan faktor luaran. 1. Periksa sama ada konfigurasi innodb_buffer_pool_size, max_connections, dan lain -lain adalah munasabah, dan elakkan terlalu besar atau terlalu kecil. 2. Gunakan perintah percuma -m, vmstat 1, atas dan lain -lain untuk memerhatikan memori sistem dan tingkah laku pertukaran, dan menyesuaikan parameter VM.Swappiness dengan sewajarnya. 3. Menganalisis data skema log dan prestasi ralat, cari modul pertumbuhan berterusan memori, dan tentukan sama ada terdapat kebocoran memori. 4. Kaji semula tingkah laku SQL lapisan aplikasi, mengoptimumkan operasi yang tidak cekap seperti pengimbasan jadual penuh, menyertai, kumpulan_concat, dan lain -lain, dan mengurangkan overhead memori sementara.

Kebocoran memori MySQL dan masalah pertukaran tidak biasa dalam persekitaran pengeluaran, terutamanya dalam senario di mana jumlah data adalah besar dan kesesuaiannya tinggi. Sebaik sahaja ia berlaku, ia boleh menyebabkan pangkalan data bertindak perlahan atau bahkan kemalangan. Apabila menghadapi masalah sedemikian, anda tidak hanya melihat fenomena permukaan, tetapi periksa dari pelbagai perspektif seperti konfigurasi, status operasi, dan sumber sistem.

1. Periksa konfigurasi yang berkaitan dengan memori mysql

Banyak masalah ingatan sebenarnya berpunca daripada konfigurasi yang tidak betul. Beberapa parameter utama MySQL menentukan berapa banyak memori yang boleh digunakan, seperti:

• innodb_buffer_pool_size : Ini adalah kawasan memori yang paling penting dalam enjin InnoDB. Ia biasanya disyorkan untuk menetapkannya kepada 50% ~ 80% daripada memori fizikal, tetapi ia juga harus diselaraskan mengikut beban sebenar.
• max_connections : Lebih banyak sambungan, lebih banyak memori yang digunakan. Setiap sambungan akan memperuntukkan beberapa memori yang berkaitan dengan benang, seperti thread_stack dan sort_buffer_size .
• query_cache_type dan query_cache_size : Walaupun cache query dikeluarkan dalam mysql 8.0, jika didayakan dan ditetapkan terlalu besar dalam versi lama, sisa memori atau pertikaian juga boleh menyebabkan sisa memori atau pertarungan.

Amalan yang dicadangkan:

• Gunakan alat seperti mysqltuner.pl atau tuning-primer.sh untuk menilai sama ada konfigurasi semasa adalah munasabah.
• Jangan membabi buta meningkatkan kolam penampan, menggabungkan pemantauan beban untuk menentukan sama ada ia benar -benar diperlukan.
• Sekiranya anda mendapati bahawa penggunaan memori berubah -ubah, anda boleh mempertimbangkan untuk membolehkan innodb_buffer_pool_instances untuk mengurangkan persaingan kunci.

2. Perhatikan tingkah laku memori dan pertukaran di peringkat sistem

Walaupun konfigurasi MySQL kelihatan OK, tekanan memori peringkat sistem akan mencetuskan pertukaran. Pada masa ini, anda boleh melihatnya melalui arahan berikut:

• free -m : Semak penggunaan memori keseluruhan.
• vmstat 1 : Perhatikan sama ada terdapat swap berterusan dalam dan keluar dalam lajur Si/SO.
• top atau htop : Lihat jika RES (memori pemastautin) dan %mem daripada proses MySQL berkembang tidak normal.
• sar -r (jika sysstat dipasang): Lihat trend memori sejarah.

Fenomena Biasa:

• Walaupun terdapat memori yang cukup, Linux mungkin mula bertukar kerana "memori yang tersedia" yang tidak mencukupi, yang berkaitan dengan mekanisme pengurusan memori Linux.
• Parameter vm.swappiness boleh diselaraskan dengan sewajarnya untuk mengurangkan penggunaan swap yang tidak perlu (contohnya, ditetapkan kepada 10 atau lebih rendah).

3. Menganalisis sama ada terdapat tanda -tanda kebocoran memori

Kebocoran memori biasanya nyata kerana memori yang digunakan oleh MySQL terus berkembang dari masa ke masa dan tidak dapat dikeluarkan. Dalam kes ini, anda boleh bermula dari aspek berikut:

• Lihat log ralat, terutamanya maklumat berkaitan OOM (keluar dari memori).
• Gunakan jadual dalam skema prestasi atau information_schema untuk menganalisis sama ada operasi seperti bergabung, jadual sementara, jenis tidak normal.
• Gunakan pmap -x <pid></pid> untuk melihat peta memori proses MySQL dan sahkan sama ada terdapat segmen pertumbuhan yang tidak diketahui.
• Jika skema prestasi diaktifkan, anda boleh melaksanakan pernyataan yang serupa dengan yang berikut untuk melihat peruntukan memori:

 Pilih event_name, current_number_of_bytes_used 
Dari prestasi_schema.memory_summary_global_by_event_name 
Pesanan oleh current_number_of_bytes_used desc;

Sekiranya anda mendapati bahawa penggunaan memori modul tertentu terus meningkat, seperti memory/sql/String atau memory/innobase , ia mungkin menjadi titik kebocoran yang berpotensi.

4. Pertimbangkan faktor luaran: tingkah laku lapisan aplikasi dan pernyataan SQL

Kadang -kadang masalah ingatan tidak disebabkan oleh MySQL sendiri, tetapi kerana lapisan aplikasi menghantar sejumlah besar SQL yang tidak cekap:

• Menggunakan sejumlah besar imbasan meja penuh dan tiada indeks akan meningkatkan overhead sorting dan jadual sementara.
• Apabila menggunakan fungsi seperti GROUP_CONCAT() dan DISTINCT untuk memproses set data yang besar, jika tiada had pada panjang atau saiz hasil, ia boleh menyebabkan memori untuk meroket.
• Aplikasi sering mewujudkan sambungan seumur hidup, yang bukan sahaja mempengaruhi prestasi, tetapi juga menghasilkan beban memori tambahan.

Cadangan Penyelesaian:

• Kerap menganalisis log pertanyaan perlahan untuk mencari SQL yang menggunakan banyak sumber.
• Gunakan EXPLAIN untuk melihat pelan pelaksanaan dan pastikan indeks digunakan dengan betul.
• Untuk aplikasi dengan menulis serentak yang tinggi, anda boleh mempertimbangkan memisahkan logik perniagaan untuk mengelakkan pemprosesan terlalu banyak data sekaligus.

Pada dasarnya itu sahaja. Masalah memori tidak intuitif seperti CPU. Mereka sering "diringkaskan ke dalam lebih banyak", terutamanya dalam perkhidmatan pangkalan data yang berjalan untuk jangka masa yang panjang. Pemeriksaan konfigurasi yang kerap, perhatikan metrik sistem, dan mengoptimumkan SQL adalah cara asas.

Atas ialah kandungan terperinci Menyelesaikan masalah memori mysql kebocoran dan bertukar. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!