MySQL: Bagaimana cara saya menurunkan “Penggunaan memori semaksimal mungkin”?

Saya baru-baru ini mengalami masalah dengan meronta-ronta karena kehabisan memori. (VPS saya memiliki total 256 juta)

Saya mencoba untuk menyetel MySQL menggunakan mysqltuner.pl, dan mendapatkan hasil berikut:

-------- Statistik Umum ---------------------------------------- ----------
[-] Periksa versi lompatan untuk skrip MySQLTuner
[OK] Saat ini sedang berjalan didukung versi MySQL 5.0.51a-3ubuntu5.4-log
[OK] Beroperasi pada arsitektur 64-bit

-------- Statistik Mesin Penyimpanan --------------------------------------- ----
[-] Status: + Arsip -BDB -Federated -InnoDB -ISAM -NDBCluster 
[-] Data dalam tabel MyISAM: 114M (Tabel: 454)
[!!] Total tabel terfragmentasi: 34

-------- Metrik Kinerja ---------------------------------------- ---------
[-] Naik untuk: 40-an (570 q [14.250 qps], 23 conn, TX: 154K, RX: 23K)
[-] Baca / Tulis: 100% / 0%
[-] Total buffer: 338.0M global + 2.7M per utas (20 utas maksimum)
[!!] Penggunaan memori maksimum: 392.9M (153% RAM terpasang)
[OK] Permintaan lambat: 0% (5/570)
[Oke] Penggunaan tertinggi koneksi yang tersedia: 15% (3/20)
[!!] Ukuran buffer kunci / total indeks MyISAM: 8.0M / 9.4M
[!!] Tingkat hit buffer kunci: 57.1% (7 cache / 3 kali dibaca)
[OK] Efisiensi cache kueri: 21,9% (7 cache / 32 pilihan)
[OK] Kueri cache permintaan per hari: 0
[OK] Mengurutkan yang membutuhkan tabel sementara: 0% (0 macam temp / 1 macam)
[OK] Tabel sementara dibuat di disk: 0% (0 pada disk / 32 total)
[OK] Tingkat hit cache cache: 86% (3 dibuat / 23 koneksi)
[OK] Tingkat hit cache cache: 26% (128 terbuka / 484 dibuka)
[OK] Batas file terbuka yang digunakan: 25% (259 / 1K)
[OK] Kunci meja diperoleh dengan segera: 100% (492 langsung / 492 kunci)

-------- Rekomendasi ----------------------------------------- ------------
Rekomendasi umum:
    Jalankan OPTIMIZE TABLE ke tabel defragment untuk kinerja yang lebih baik
    MySQL dimulai dalam 24 jam terakhir - rekomendasi mungkin tidak akurat
    Kurangi keseluruhan jejak memori MySQL Anda untuk stabilitas sistem
Variabel yang akan disesuaikan:
  *** Penggunaan memori maksimum MySQL sangat tinggi ***
  *** Tambahkan RAM sebelum meningkatkan variabel buffer MySQL ***
    key_buffer_size (> 9,4M)

Tapi saya agak bingung bagaimana cara menurunkan penggunaan memori maksimum? Tampaknya didasarkan pada key_buffer dan max_connections, tetapi harus ada sesuatu yang lain yang terlibat?

my.cnf:

key_buffer = 8M
max_allowed_packet = 12M
thread_stack = 128K
thread_cache_size = 8
max_connections = 20
table_cache = 128
tmp_table_size = 256 juta
max_heap_table_size = 256 juta
join_buffer_size = 256 ribu
query_cache_limit = 8M
query_cache_size = 64M

Saya sudah mencoba membaca melalui artikel tuning MySQL, tetapi mereka tampaknya diarahkan pada orang-orang yang sudah tahu apa yang mereka lakukan! Bantuan apa pun akan dihargai. Terima kasih!

Anda memiliki server dengan 256 juta, tetapi Anda tidak dapat menggunakan semua itu - ingat ada beberapa overhead OS. Tambahkan ke bahwa dengan fakta Anda lebih dari melakukan seperti yang orang lain katakan dan Anda pasti akan puas di sini. 256M hanya cukup untuk DB kecil, 20 koneksi banyak dengan apa yang telah Anda konfigurasikan.

1) kurangi koneksi maks Anda menjadi 4 (Anda menggunakan 3 dari 20)

2) mengoptimalkan cache permintaan Anda lebih baik; 8M sangat besar, dan total 64M banyak berdasarkan pada hit / plum Anda; coba combo 4/32 dan lihat bagaimana hasilnya. Sungguh saya pikir 2/24 kombo akan bekerja untuk Anda.

3) Anda tidak memiliki jenis yang membutuhkan tabel temp, mengapa itu kata kerja max_heap_table_size di sana? Berkomentarlah, gunakan default

4) apakah Anda benar-benar memiliki 128 tabel? Cobalah memotong table_cache menjadi setengah menjadi 64 atau 48

5) kurangi thread_cache_size menjadi 4

6) optimalkan tabel tersebut untuk mengurangi fragmentasi

Itu adalah beberapa hal untuk memulai. Sepertinya Anda melemparkan banyak angka dalam konfigurasi tanpa profil sebenarnya untuk mengetahui apa yang Anda butuhkan dan telah membuat kekacauan; jika semuanya gagal kembali ke default dan singkirkan pengaturan kustom Anda dan mulai lagi menggunakan beberapa panduan penyesuaian kinerja yang dapat Anda temukan di Google. Dapatkan output dari SHOW VARIABLES dan SHOW STATUS, temukan salah satu dari panduan tuning bajillion dan masukkan bilangan real Anda yang sebenarnya ke dalam persamaan mereka dan itu akan memberi tahu Anda angka pasti yang perlu Anda masukkan ke dalam file konfigurasi Anda.

Saya bukan guru MySQL dan saya tidak dapat mendiagnosis masalah dengan informasi ini, tetapi saya mencoba mencari rumus dalam kode sumber. Ini dia:

server_buffers + total_per_thread_buffers * max_connections

Dimana:

server_buffers = key_buffer_size + innodb_buffer_pool_size + innodb_additional_mem_pool_size + innodb_log_buffer_size + query_cache_size

dan:

total_per_thread_buffers = read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + max_allowed_packet + join_buffer_size

Sekarang Anda harus memeriksa masing-masing nilai-nilai ini dan mencari tahu mana yang bertanggung jawab untuk jumlah besar ini. Dan jangan percaya skrip ini tanpa syarat - saya mencoba menjalankannya di salah satu server DB saya dan menghitung bahwa memori maksimum adalah 140% dari jumlah total memori fisik, tetapi sistem telah berjalan selama bertahun-tahun tanpa masalah stabilitas.

Semoga berhasil!

Jika saya ingat dengan benar, MySQL Tuner menggunakan rumus berikut untuk memperkirakan penggunaan maksimum:

read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + join_buffer_size

Perlu diingat bahwa ini tidak 100% benar, dan sebenarnya hanya perkiraan, karena pengaturan tertentu di MySQL tidak memiliki batas yang ditentukan.

Anda dapat mulai mengurangi beberapa pengaturan dalam file konfigurasi Anda dan menjalankan tuner lagi, tetapi saya akan menyarankan untuk mendapatkan bantuan ahli jika Anda tidak punya waktu untuk mengubah my.cnf, memulai kembali dan menjalankan tuner.

Penggunaan perangkat lunak mysqlcalculator.com dapat menghemat banyak waktu.