Rumah > Artikel > pangkalan data > Bagaimana untuk menyelesaikan masalah peningkatan memori yang tidak normal dalam pangkalan data pengeluaran MySQL
Oleh kerana persekitaran pengeluaran syarikat menggunakan Alibaba Cloud RDS, adalah agak mudah untuk mengubah suai parameter Performance_schema lalai ialah 0, dan kali ini ia diubah suai kepada 1. Serahkan parameter selepas pengubahsuaian, dan pangkalan data akan dimulakan semula Adalah disyorkan untuk melakukan ini semasa puncak perniagaan rendah.
Log masuk ke pangkalan data MySQL dan laksanakan SQL berikut untuk menghidupkan pemantauan memori.
update performance_schema.setup_instruments set enabled = 'yes' where name like 'memory%';
Sahkan selepas membukanya.
select * from performance_schema.setup_instruments where name like 'memory%innodb%' limit 5;
**Nota: **Arahan ini adalah untuk membuka statistik memori dalam talian, jadi hanya objek memori yang baru ditambah selepas dibuka akan dikira objek memori sebelum dibuka tidak akan dikira beberapa ketika selepas dibuka. Lakukan langkah seterusnya untuk mengenal pasti benang dengan penggunaan memori yang tinggi.
select event_name, SUM_NUMBER_OF_BYTES_ALLOC from performance_schema.memory_summary_global_by_event_name order by SUM_NUMBER_OF_BYTES_ALLOC desc LIMIT 10; +---------------------------------------+-------------------------------------+ | event_name | SUM_NUMBER_OF_BYTES_ALLOC | +---------------------------------------+-------------------------------------+ | memory/sql/Filesort_buffer::sort_keys | 763523904056 | | memory/memory/HP_PTRS | 118017336096 | | memory/sql/thd::main_mem_root | 114026214600 | | memory/mysys/IO_CACHE | 59723548888 | | memory/sql/QUICK_RANGE_SELECT::alloc | 14381459680 | | memory/sql/test_quick_select | 12859304736 | | memory/innodb/mem0mem | 7607681148 | | memory/sql/String::value | 1405409537 | | memory/sql/TABLE | 1117918354 | | memory/innodb/btr0sea | 984013872 | +---------------------------------------+-------------------------------------+
Anda boleh melihat bahawa acara dengan penggunaan memori tertinggi ialah Filesort_buffer Menurut pengalaman, ini harus berkaitan dengan pengisihan .
select thread_id, event_name, SUM_NUMBER_OF_BYTES_ALLOC from performance_schema.memory_summary_by_thread_by_event_name order by SUM_NUMBER_OF_BYTES_ALLOC desc limit 10; +---------------------+---------------------------------------+-------------------------------------+ | thread_id | event_name | SUM_NUMBER_OF_BYTES_ALLOC | +---------------------+---------------------------------------+-------------------------------------+ | 105 | memory/memory/HP_PTRS | 69680198792 | | 183 | memory/sql/Filesort_buffer::sort_keys | 49210098808 | | 154 | memory/sql/Filesort_buffer::sort_keys | 43304339072 | | 217 | memory/sql/Filesort_buffer::sort_keys | 37752275360 | | 2773 | memory/sql/Filesort_buffer::sort_keys | 31460644712 | | 218 | memory/sql/Filesort_buffer::sort_keys | 31128994280 | | 2331 | memory/sql/Filesort_buffer::sort_keys | 28763981248 | | 106 | memory/memory/HP_PTRS | 27938197584 | | 191 | memory/sql/Filesort_buffer::sort_keys | 27701610224 | | 179 | memory/sql/Filesort_buffer::sort_keys | 25624723968 | +---------------------+---------------------------------------+-------------------------------------+
Anda dapat melihat bahawa utas yang menggunakan banyak memori adalah berkaitan dengan Filesort_buffer
.
Menurut thread_id
yang kami dapati sebelum ini, pergi ke log untuk mencari log audit SQL Alibaba Cloud RDS yang agak berkuasa. Kami mendapatkan semula secara langsung berdasarkan thread_id.
Kami melihat sejumlah besar SQL sedemikian dalam log, dan bilangan baris yang diimbas berjulat dari ribuan hingga puluhan ribu. Walaupun masa bagi setiap pertanyaan tidak lama, biasanya antara puluhan dan ratusan milisaat, bilangan permintaan serentak adalah besar.
Atas ialah kandungan terperinci Bagaimana untuk menyelesaikan masalah peningkatan memori yang tidak normal dalam pangkalan data pengeluaran MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!