Situs Gagal ke Database Setelah Worker PHP Ditambah
Kamu menambah PHP worker karena antrean request menumpuk, lalu halaman depan menampilkan Error establishing a database connection. Panduan mysql max_connections wordpress ini memetakan pertukaran itu: request yang tadinya antre di pool PHP kini ditolak di gerbang database karena slot koneksi habis.
Artikel ini memberi tiga hal. Pertama, pesan WordPress itu payung banyak sebab, bukan vonis pagu penuh. Kedua, anggaran koneksi mengikuti worker yang sibuk, bukan total worker terdaftar. Ketiga, menaikkan pagu tanpa sisa RAM hanya memindahkan antrean dari pool PHP ke memori database.
Urutannya penting. Memvonis pagu sebelum membaca status dan membandingkannya dengan anak PHP yang sibuk melahirkan dua salah sekaligus: pagu longgar ikut dinaikkan, atau pool kebesaran dibiarkan menekan database. Mulai dari pesan, lalu anggaran, lalu keputusan.
Apa yang Dihitung oleh max_connections
Kata connection berarti satu soket klien yang terbuka ke server database, bukan jumlah query per detik dan bukan ukuran database. Selama soket terbuka, ia memakan satu slot pagu, dari mana pun asalnya.
Satu koneksi bisa berasal dari request PHP yang berjalan, sesi WP-CLI, cron terjadwal, proses backup, atau agen monitoring. Pagu max_connections wordpress bersifat global untuk semuanya sekaligus, bukan jatah per situs atau per akun.
Pagu kecil menolak koneksi baru dengan error, bukan memperlambat query yang berjalan. Pagu besar tidak mempercepat apa pun, ia hanya mengizinkan lebih banyak soket terbuka bersamaan. Menaikkan pagu tanpa kebutuhan nyata menambah slot tak terpakai yang memakan RAM pada jam sibuk.
Memahami pagu sebagai jumlah soket, bukan kecepatan, membuat keputusan berikutnya jernih.
Pesan WordPress yang Sama untuk Sebab yang Berbeda
Kalimat Error establishing a database connection adalah payung, bukan diagnosis. WordPress memakainya untuk password salah, server yang mati, batas global yang penuh, dan batas akun yang penuh. Dari halaman, semua sebab itu terlihat sama.
Di log database, gejala ini dikenal dengan nama too many connections wordpress. Nomornya menentukan pagu mana yang habis. Kode error 1040 berarti batas global penuh, sedangkan error 1203 berarti batas satu akun lewat max_user_connections yang penuh. WordPress menampilkan kalimat yang sama untuk keduanya, juga untuk password salah dan server yang mati.
Pesan Error establishing a database connection tidak mengatakan batas mana yang penuh. Tanpa nomor error dari database, menaikkan max_connections hanya tebakan.
Karena itu pemeriksaan selalu mulai dari nomor error dan status server, bukan dari menaikkan batas. Kredensial salah dibetulkan di berkas konfigurasi, server mati dinyalakan, dan batas penuh dihitung ulang. Menebak tanpa nomor mengubah satu masalah menjadi dua.
Berapa Koneksi yang Pool PHP-FPM Benar-Benar Membuka
Pada inti WordPress, satu request yang berjalan membuka satu koneksi dan menutupnya saat request selesai. Tidak ada koneksi yang ditahan antar request, dan tidak ada pool koneksi bawaan di dalam PHP. Pola mysql max_connections php-fpm karena itu sederhana: kebutuhan sesaat sama dengan jumlah request yang sedang dieksekusi.
Langit-langit satu pool adalah nilai pm.max_children, angka atap satu pool itu hanya tercapai bila semua anak sibuk bersamaan. Situs yang rata-rata memakai empat anak tidak membuka empat koneksi terus-menerus, ia membuka empat hanya pada detik tersibuk. Arti angka anak dijelaskan artikel PHP Worker WordPress, tidak dihitung ulang di sini.
Di luar pool web, tambahkan klien yang tidak terlihat di dasbor: cron terjadwal, proses backup, sesi WP-CLI, dan pool kedua bila ada. Semuanya memakai gerbang batas global yang sama. Anggaran yang benar menjumlahkan anak sibuk plus klien ini yang sudah dikenal.
RAM Koneksi dan Buffer Pool Berebut Tempat yang Sama
Menaikkan batas koneksi tidak mempercepat query, ia menaikkan RAM terburuk untuk thread-thread baru. Buffer per sesi teralokasi saat dipakai, sehingga bebannya muncul pada jam tersibuk. Angka tabel di bawah ilustrasi.
Dua anggaran lain memakai memori yang sama. Buffer pool InnoDB menampung halaman data dan indeks, rinciannya di artikel InnoDB Buffer Pool WordPress. Nilai memory_limit membatasi RAM satu proses PHP, rinciannya di artikel WP Memory Limit WordPress. Menaikkan satu anggaran tanpa melihat sisanya hanya memindahkan sempit dari satu tempat ke tempat lain.
| Anggaran | Yang dibatasi | Bukan urusannya |
|---|---|---|
max_connections | Jumlah klien database sekaligus, dan RAM terburuk thread-nya | Ukuran halaman data di memori |
| Buffer pool InnoDB | Halaman data dan indeks yang tinggal di RAM | Jumlah proses PHP |
memory_limit PHP | RAM satu proses PHP | Thread di dalam MariaDB atau MySQL |
Koneksi Sleep yang Menumpuk Bukan dari Request Biasa
Inti WordPress lewat kelas wpdb memakai mysqli non-persisten: koneksi dibuka saat request berjalan dan koneksi ditutup di akhir request. Pengecualiannya adalah drop-in db.php dari plugin database yang bisa menahan koneksi, tetapi itu bukan perilaku bawaan. Karena itu tumpukan baris Sleep yang berumur panjang jarang berasal dari kunjungan biasa.
Tersangkanya biasanya klien yang memegang soket: backup yang berjalan lama, agen monitoring, cron yang macet, atau skrip yang lupa memutus koneksi. Nilai wait_timeout yang panjang membuat baris itu bertahan, jadi baca nilai yang berlaku langsung di server.
Jangan menjadikan pengubahan timeout sebagai obat pertama. Menutup paksa koneksi yang masih dipakai tugas terjadwal bisa merusak backup dan cron, sementara akar masalahnya tetap ada. Temukan dulu pemilik baris Sleep lewat daftar proses, lalu putuskan di pemiliknya, bukan di kenop global.
Menaikkan max_connections Tanpa Menurunkan Konkurensi
Kesalahan pertama: worker dinaikkan sampai menembus pagu database, lalu semua request gagal sekaligus. Kesalahan kedua, kebalikannya: pagu database dinaikkan sampai RAM habis dan buffer pool menyusut, lalu query melambat semua. Dari luar keduanya terlihat sama, situs tetap lambat walau angkanya sudah diubah.
Gejala melambatnya terbaca pada waktu respons server, yang dibahas artikel TTFB WordPress tanpa diulang cara mengukurnya di sini. Bedakan juga dari keep-alive: koneksi HTTP yang ditahan ke server web bukan thread di dalam MySQL, pembahasannya ada di artikel Keep-Alive WordPress.
Aturannya satu kalimat: sesuaikan sisi yang kelebihan, bukan membesarkan semua sisi. Bila antrean ada di pool PHP, yang dikecilkan poolnya. Bila pagu database yang sempit tetapi RAM masih longgar, barulah batasnya yang ditinjau.
Cara Memeriksa max_connections dan Menyelaraskannya dengan PHP-FPM
Pola mysql max_connections php-fpm yang sehat selalu mulai dari membaca status, bukan dari mengubah angka. Baca dulu batas dan pemakaian yang berlaku, bandingkan dengan anak PHP yang benar-benar sibuk plus klien non-web yang diketahui, lalu putuskan: kecilkan pool, atau naikkan batas bila RAM masih ada. Tiga langkah di bawah menjalankan urutan itu.
Baca Status dan Variabel yang Sedang Berlaku
Dua perintah membaca pagu yang berlaku: SHOW GLOBAL VARIABLES untuk max_connections dan max_user_connections. Angka bawaan instalasi hulu sering 151, tetapi paket hosting menimpanya, jadi baca nilai yang hidup di server, bukan menghafal angka bawaan.
Tiga status membaca pemakaian: Threads_connected untuk soket yang terbuka saat ini, Max_used_connections untuk puncak sejak server jalan, dan Connection_errors_max_connections untuk penolakan karena pagu. Bila puncak sudah menyentuh pagu, anggaran itu memang pernah penuh. Satu slot admin biasanya masih bisa masuk saat pagu penuh, sehingga daftar proses tetap bisa dibaca.
Kuerinya pendek dan semua angka pada contoh adalah ilustrasi:
SHOW GLOBAL VARIABLES LIKE 'max_connections';
SHOW GLOBAL VARIABLES LIKE 'max_user_connections';
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';
SHOW GLOBAL STATUS LIKE 'Connection_errors_max_connections';Bandingkan dengan Anak PHP yang Benar-Benar Sibuk
Ambil nilai pm.max_children dari pool yang melayani situs, lalu tambahkan klien non-web: cron, backup, dan sesi manual. Arti angka anak dijelaskan artikel PHP Worker WordPress dan tidak dihitung ulang di sini. Jumlahkan keduanya sebagai kebutuhan puncak, bukan kebutuhan rata-rata.
Bandingkan kebutuhan puncak itu dengan Max_used_connections dan pagu global. Bila puncak tercatat sudah menyentuh pagu, anggarannya memang pernah penuh. Bila puncak masih jauh di bawah pagu, penyebabnya di tempat lain dan menaikkan batas tidak mengubah apa pun. Catat ketiga angka sebelum mengubah apa pun.
Putuskan: Kecilkan Pool, atau Naikkan Batas Kalau RAM Masih Ada
Pada shared dan cloud hosting, pagu global sering tidak bisa diubah pelanggan. Yang bisa diatur adalah sisi permintaan: jangan meminta worker lebih banyak daripada slot database yang tersedia.
Pada VPS, menaikkan max_connections sah setelah RAM terburuk masih menyisakan buffer pool. Ulangi pembacaan status setelah perubahan dan pastikan puncak baru berada di bawah pagu dengan jarak aman.
| Yang terlihat | Yang diperiksa lebih dulu | Bukan kesimpulan pertamanya |
|---|---|---|
| Log menyebut error 1040 atau too many connections | Max_used_connections terhadap max_connections, lalu jumlah anak PHP yang sibuk | Langsung gandakan max_connections |
| Hanya satu situs yang gagal, situs lain di server yang sama normal | max_user_connections akun itu, dan apakah ada skrip yang tidak menutup koneksi | Batas global server yang terlalu kecil |
| Batas sudah dinaikkan, situs tetap lambat dan RAM penuh | Sisa RAM untuk buffer pool setelah thread baru | Batas koneksi masih kurang tinggi |
Rekomendasi Infrastruktur Saat Batas Koneksi Mudah Terbentur
Situs yang tidak memegang berkas konfigurasi database cocok di Cloud Hosting Mordenhost: lingkungan terpantau dengan dukungan teknis yang membantu memisahkan penyebab plugin dari penyebab server. Bila fondasi server masih kabur, baca dulu memahami cara kerja hosting sebelum mengubah apa pun.
Situs yang perlu menyelaraskan pool PHP-FPM dengan max_connections cocok di Managed VPS Mordenhost: akses konfigurasi pool dan database, eksekusi perintah langsung, serta bantuan membaca status sebelum dan sesudah perubahan, mulai Rp950.000 per bulan. Verifikasi harga di halaman produk sebelum memesan.
Yang menentukan bukan besarnya angka, melainkan selarasnya tiga sisi: anak yang sibuk, pagu koneksi, dan memori yang tersisa. Bangun anggaran itu sekali, lalu ulangi pembacaan tiap kali trafik naik kelas.
Pertanyaan yang Sering Ditanya
Empat jawaban singkat soal batas penuh, koneksi worker, menaikkan batas, dan beda dua pagu.
Apakah Error establishing a database connection selalu berarti max_connections penuh?
Tidak. WordPress memakai kalimat yang sama untuk password salah, server mati, dan batas akun. Error 1040 baru pasti bila status atau log database menyebut too many connections wordpress, bukan dari teks di halaman saja.
Apakah setiap PHP worker memegang koneksi database terus-menerus?
Tidak pada inti WordPress. Koneksi dibuka saat request berjalan dan ditutup sesudahnya. Yang menahan koneksi saat worker menganggur biasanya klien lain, backup, atau drop-in database, bukan request halaman dari pengunjung.
Apakah menaikkan max_connections selalu membuat situs lebih tahan trafik?
Tidak. Angka yang lebih tinggi hanya menolong kalau RAM masih cukup untuk thread baru tanpa menyusutkan buffer pool. Kalau tidak, server hanya menukar error koneksi dengan query yang lebih lambat dari sebelumnya.
Apa beda max_connections dengan max_user_connections?
max_connections adalah batas seluruh server. max_user_connections adalah batas satu akun database. Akun WordPress bisa penuh lebih dulu meski batas global masih longgar, dan gejala di halaman tetap pesan koneksi yang sama.
Butuh bantuan membaca status database atau memilih paket yang pas? Hubungi WhatsApp Mordenhost dan tim kami membantu memetakan langkah berikutnya.
