Cara Mengatasi MySQL Too Many Connections di VPS WordPress

The Last Digital
Update: ... minutes read

Di tengah trafik yang sedang naik, WordPress tiba-tiba menampilkan error database. Di log, pesannya jelas: Too many connections. Artinya bukan database Anda rusak — melainkan semua slot koneksi MySQL sedang terpakai, sehingga koneksi baru ditolak.

Jawaban Singkat

Menurut dokumentasi MySQL, jumlah koneksi yang diizinkan dikendalikan variabel max_connections. Server bahkan mengizinkan max_connections + 1 koneksi, dengan satu slot cadangan untuk akun berhak CONNECTION_ADMIN (atau SUPER). Jadi langkah daruratnya: masuk dengan akun admin lewat slot cadangan, lihat SHOW PROCESSLIST, hentikan koneksi yang menggantung, lalu perbaiki penyebabnya — bukan sekadar menaikkan angka membabi buta.

Kenapa Slot Koneksi Bisa Habis?

PenyebabPenjelasan
Koneksi tidak ditutup (unclosed)Skrip selesai tanpa menutup koneksi, atau memakai koneksi persisten yang menumpuk
Kueri lambat menumpukSetiap kueri lambat menahan satu koneksi; antrean tumbuh saat trafik naik
Lonjakan trafik mendadakWorker PHP baru masing-masing membuka koneksi baru
Koneksi idle (Sleep) menumpukKoneksi menganggur tidak dilepas karena timeout terlalu panjang

Persiapan

  • Akses SSH ke VPS dan kredensial admin MySQL (root atau akun setara).
  • Jangan membagikan kredensial ini ke siapa pun dan jangan menuliskannya di artikel publik.
  • Backup database sebelum mengubah konfigurasi permanen.

Langkah 1: Masuk Lewat Slot Cadangan Admin

Karena satu slot dicadangkan untuk admin, Anda biasanya masih bisa masuk meski pengguna biasa ditolak:

mysql -u root -p

Setelah masuk, periksa kondisi saat ini:

SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Threads_connected';
SHOW PROCESSLIST;

SHOW PROCESSLIST menampilkan siapa yang memegang koneksi, sejak kapan, dan sedang menjalankan perintah apa. Fokus pada baris berstatus Sleep dengan waktu (Time) sangat besar, dan baris yang menjalankan kueri yang sama berulang-ulang.

Langkah 2: Hentikan Koneksi Bermasalah

Untuk koneksi yang jelas menggantung (idle sangat lama atau kueri macet), hentikan dengan ID-nya:

KILL 12345;

Ganti 12345 dengan ID dari SHOW PROCESSLIST. Lakukan satu per satu dan amati: bila situs langsung pulih setelah beberapa koneksi dihentikan, Anda menemukan sumber penumpukannya. Jangan menghentikan semua koneksi sekaligus tanpa memilah — Anda bisa memutus transaksi pengguna yang sah.

Langkah 3: Pereda Darurat Tanpa Restart

Bila perlu membuka akses segera, naikkan batas sementara tanpa restart:

SET GLOBAL max_connections = 300;

Perubahan ini berlaku sampai server di-restart. Gunakan sebagai pereda, bukan solusi permanen — dan ingat, setiap koneksi memakan RAM. Menaikkan batas tanpa RAM yang cukup hanya memindahkan masalah dari “koneksi ditolak” menjadi “server kehabisan memori”.

Langkah 4: Buat Perubahan Permanen dengan Hati-Hati

Untuk perubahan yang bertahan setelah restart, tambahkan di bawah [mysqld] pada file konfigurasi MySQL (biasanya /etc/mysql/my.cnf atau file yang di-include dari sana):

[mysqld]
max_connections = 300

Lalu restart layanan:

sudo systemctl restart mysql

Nilai yang tepat bergantung pada RAM server, ukuran buffer global, dan memori per koneksi — tidak ada angka universal yang aman untuk semua VPS. Mulailah dari kenaikan moderat, pantau Threads_connected selama beberapa hari, dan sesuaikan berdasarkan data, bukan tebakan.

Langkah 5: Perbaiki Penyebabnya

  • Perpendek idle timeout bila koneksi Sleep menumpuk (misalnya tinjau wait_timeout), agar koneksi menganggur dilepas lebih cepat.
  • Perbaiki kueri lambat yang menahan koneksi: indeks yang hilang dan kueri tanpa batas adalah penyebab klasik antrean.
  • Tutup koneksi secara eksplisit di skrip kustom dan pastikan tidak ada koneksi persisten yang dibiarkan menumpuk.
  • Batasi pool koneksi aplikasi agar satu aplikasi tidak membanjiri MySQL dengan ratusan koneksi baru.

Verifikasi Hasil

Perbaikan berhasil bila WordPress kembali memuat normal, Threads_connected stabil jauh di bawah max_connections saat trafik normal, dan tidak ada lagi lonjakan koneksi Sleep. Pantau selama 24 jam pertama, terutama pada jam trafik puncak.

Troubleshooting Lanjutan

SituasiLangkah berikutnya
Error kembali beberapa jam setelah batas dinaikkanPenyebabnya kebocoran koneksi, bukan batasnya — audit skrip/plugin yang membuka koneksi
Admin pun tidak bisa masukPeriksa apakah MySQL berjalan dan disk tidak penuh; restart layanan bila perlu
Koneksi Sleep menumpuk dari satu host sajaTelusuri aplikasi di host itu; kemungkinan pool-nya tidak menutup koneksi
RAM melonjak setelah batas dinaikkanTurunkan kembali batasnya dan optimalkan kueri; kapasitas RAM adalah batas nyata

FAQ

Berapa nilai max_connections yang ideal?

Tidak ada angka universal. Dokumentasi MySQL menegaskan batas itu dikendalikan max_connections, tetapi nilai yang aman bergantung pada RAM dan beban tiap koneksi di server Anda. Ukur dulu, baru tetapkan.

Apakah SET GLOBAL cukup, tanpa edit file konfigurasi?

Cukup untuk pereda darurat, tetapi hilang setelah restart. Untuk permanen, edit file konfigurasi di bawah [mysqld] dan restart layanan.

Apakah membunuh koneksi (KILL) berbahaya?

Bisa, bila koneksi itu sedang menjalankan transaksi penting. Pilah dari PROCESSLIST dan hentikan hanya koneksi yang jelas menggantung atau idle sangat lama.

Kesimpulan

Too many connections adalah masalah kapasitas koneksi, bukan vonis atas database Anda. Masuk lewat slot admin, baca PROCESSLIST, hentikan yang menggantung, reda darurat dengan SET GLOBAL bila perlu, lalu tetapkan batas permanen berdasarkan RAM dan pantauan nyata. Yang paling penting: temukan kenapa koneksi menumpuk — karena batas yang dinaikkan tanpa memperbaiki kebocoran hanya menunda error berikutnya.

Referensi

Tags:

Related Posts

Memuat…
Cookie Consent