Setiap sambungan memakan memori, sedang bekerja maupun sedang menunggu. Menaikkan batasnya pada server yang sudah menyentuh langit-langit memorinya mengubah galat basis data menjadi mesin yang bertukar ke cakram - dan itu lebih buruk.

Lihat apa yang tersambung

SHOW PROCESSLIST;
SHOW STATUS LIKE 'Threads_connected';
SHOW VARIABLES LIKE 'max_connections';
  • Banyak baris berstatus Sleep - sambungan yang dibuka dan tak pernah ditutup. Ini masalah aplikasi, bukan masalah basis data.
  • Banyak baris menjalankan kueri yang SAMA - satu kueri lambat yang datang lebih cepat daripada selesainya. Perbaiki kuerinya.
  • Baris Locked yang berkepanjangan - satu transaksi memegang kunci sementara semuanya mengantre di belakangnya.

Sambungan yang tak pernah ditutup

Skrip yang membuka satu sambungan tiap putaran gelung, atau kolam sambungan menetap yang lebih besar dari yang diizinkan server, akan menghabiskan batasnya setinggi apa pun ia disetel.

SHOW VARIABLES LIKE 'wait_timeout';
-- default is often 28800: eight hours of holding a sleeping connection

Menurunkan wait_timeout ke beberapa menit merebut kembali sambungan yang telantar. Itu jaring pengaman di bawah sebuah kebocoran, bukan obatnya.

Kapan menaikkannya MEMANG benar

Kalau semua sambungannya memang mengerjakan pekerjaan sungguhan dan servernya masih punya memori sisa, batasnya memang sungguh terlalu rendah.

SET GLOBAL max_connections = 300;
-- and in my.cnf so it survives a restart
Hitung dulu memori per sambungan. 300 sambungan yang masing-masing 12 MB sudah 3,6 GB sebelum basis datanya menyinggahkan satu baris pun.
Lonjakan sambungan yang tiba-tiba pada jam yang tetap itu tugas terjadwal, bukan lalu lintas. Daftar proses saat lonjakan menyebut namanya dalam satu baris.