Koneksi Menganggur yang Menghabiskan Kuota Database
Administrator yang membuka daftar proses database lalu menemukan galat kehabisan koneksi sering bingung: server tidak sedang diserbu query berat, tetapi slot koneksi penuh. Panduan mysql wait_timeout wordpress ini menjelaskan penyebabnya: banyak thread berstatus Sleep yang bertahan berjam-jam karena batas menganggur default terlalu longgar untuk siklus hidup web.
Setiap request WordPress membuka koneksi ke MariaDB, mengeksekusi query dalam hitungan milidetik, lalu sering membiarkan socket tetap terbuka. Selama skrip PHP belum selesai atau koneksi belum ditutup eksplisit, thread itu tercatat sebagai idle connection yang tetap memakan satu slot.
Artikel ini membahas tiga hal: mengapa status tidur bisa bertahan berjam-jam, bagaimana membedakan koneksi web dari sesi konsol interaktif, dan berapa nilai batas yang aman tanpa merusak transaksi toko yang sedang berjalan.
Default 28800 Detik: Warisan Arsitektur Klien Desktop
Dokumentasi MariaDB menetapkan wait_timeout default 28800 detik, setara 8 jam. Angka ini bukan kesalahan ketik: ia diwarisi dari era aplikasi desktop dan kasir yang membuka satu koneksi di pagi hari lalu membiarkannya terbuka seharian.
Pola itu runtuh di server web WordPress yang melayani ribuan request per menit. Setiap request yang meninggalkan koneksi tidur selama 8 jam menahan slot yang seharusnya dipakai request berikutnya. Pada jam sibuk, tumpukan koneksi menganggur ini lebih dulu menghabiskan kuota.
Karena itu default dokumentasi bukan rekomendasi untuk web dinamis. Ia titik awal yang aman bagi instalasi umum, tetapi administrator situs ramai hampir selalu menurunkannya ke rentang puluhan detik. Bagian berikut menjelaskan knop mana yang benar diturunkan, karena ada dua variabel yang namanya mirip.
Beda wait_timeout dan interactive_timeout
Frasa wait_timeout vs interactive_timeout wordpress sering dicari karena dokumentasi menaruh keduanya berdampingan dengan default sama. Mekanismenya berbeda pada inisialisasi sesi: saat klien menyambung, server memeriksa flag koneksi. Klien yang mengirim flag CLIENT_INTERACTIVE mewarisi @@global.interactive_timeout, sedangkan sisanya mewarisi @@global.wait_timeout.
| Parameter | Jenis Klien | Sumber Nilai Sesi | Default MariaDB | Dampak ke WordPress |
|---|---|---|---|---|
wait_timeout | Non-interaktif: skrip PHP, mysqli, PDO | @@global.wait_timeout | 28800 detik (8 jam) | Menutup paksa koneksi web yang menganggur |
interactive_timeout | Interaktif flag CLIENT_INTERACTIVE: CLI mysql, shell admin | @@global.interactive_timeout | 28800 detik (8 jam) | Batas idle sesi konsol administrator |
Klien terminal seperti program CLI mysql mengirim flag interaktif, sehingga sesi konsol membaca interactive_timeout. Skrip web PHP tidak pernah mengirim flag itu, sehingga seluruh koneksi non-interaktif WordPress tunduk pada wait_timeout. Mengubah nilai di terminal tidak menyentuh apa pun di sisi web.
Koneksi web PHP tidak pernah membaca interactive_timeout. Menurunkan batas timeout interaktif di terminal tidak akan pernah menutup baris koneksi web yang sedang tidur di database.
Inilah jebakan diagnosis paling umum: administrator menguji timeout dari konsol lalu heran mengapa daftar Sleep tidak berkurang. Yang diuji dan yang dipakai aplikasi adalah dua variabel berbeda.
Mengapa Koneksi Sleep Menumpuk di WordPress
Pola mysql sleep connections wait_timeout wordpress muncul ketika daftar proses penuh baris berstatus Sleep dengan kolom waktu yang terus membesar. Status itu berarti query sudah selesai dieksekusi: thread tidak memproses apa pun, socket hanya terbuka menunggu PHP mengirim instruksi berikutnya.
Pemicu klasiknya ada di sisi PHP, bukan di database. Skrip yang menunggu respons API eksternal, cURL gateway pembayaran yang lama menjawab, cron background yang terhenti di tengah tugas, atau koneksi persisten yang memang tidak ditutup: semuanya menahan socket dalam keadaan tidur.
Kesalahpahaman umum mengira Sleep sama dengan query lambat. Padahal query lambat masih mengeksekusi dan tercatat di log query, sedangkan Sleep berarti eksekusi sudah selesai. Menyalahkan database sebelum memeriksa skrip hanya memindahkan masalah, bukan menyelesaikannya.
Hubungan Erat dengan max_connections dan PHP Worker
Setiap koneksi tidur tetap memakan satu slot dari kapasitas maksimal database, seperti dijelaskan satu kalimat di artikel max_connections WordPress: kuota yang dimakan Sleep tidak tersedia untuk request baru.
Di sisi aplikasi, jumlah worker PHP-FPM yang aktif ikut menentukan berapa koneksi yang dipegang ke database, sebagaimana dibahas di artikel PHP worker WordPress. Jika worker lambat melepas socket karena skripnya menunggu API, koneksi Sleep membengkak mengikuti jumlah worker yang sibuk.
Worker yang menumpuk dikali koneksi tidur yang lama dilepas sama dengan tekanan ke batas maksimal. Menurunkan timeout tanpa mengaudit skrip hanya mengobati gejala.
Risiko Menurunkan Nilai Timeout Terlalu Agresif
Godaan terbesar setelah melihat tumpukan Sleep adalah memotong wait_timeout ke angka ekstrem seperti 5 atau 10 detik. Sekilas logis: koneksi tidur cepat dibersihkan, slot cepat bebas. Tetapi jeda antar-query yang sah ikut terpotong oleh aturan yang sama.
Plugin WooCommerce atau skrip backup sering berkalkulasi di sisi PHP sebelum menulis hasil ke database. Jika jeda itu melampaui timeout, database memutus koneksi dan PHP menerima galat koneksi terputus berupa MySQL server has gone away (Error 2006).
Timeout agresif menukar satu galat dengan galat lain: kehabisan koneksi hilang, koneksi terputus muncul. Nilai yang terlalu kecil menghukum proses sah yang butuh jeda, terutama sinkronisasi stok dan import katalog yang menunggu respons bertahap.
Bukan Batas Eksekusi Query, Bukan Buffer Pool
wait_timeout adalah batas waktu menganggur, bukan batas durasi query berjalan. Durasi eksekusi pernyataan diatur oleh max_statement_time, seperti dibedakan satu kalimat di artikel max_execution_time WordPress. Query yang sudah berjalan tidak diputus oleh timeout ini.
Menutup koneksi menganggur melepaskan buffer sesi milik thread itu, bukan mengecilkan pool data. Bedanya satu kalimat di artikel InnoDB Buffer Pool WordPress: pool menyimpan halaman data untuk dibaca ulang, sedangkan timeout ini hanya menutup socket yang diam.
Singkatnya: query lama menunjuk ke batas eksekusi, halaman lambat dibaca menunjuk ke pool, dan tumpukan Sleep menunjuk ke timeout menganggur. Tiga gejala, tiga knop berbeda.
Cara Mengaudit Koneksi Sleep dan Menyesuaikan Timeout
Alurnya tiga langkah berurutan: periksa proses yang hidup di database, cari skrip yang menahan koneksi, lalu tetapkan nilai timeout yang seimbang. Jangan melompat ke angka sebelum dua langkah pertama selesai, karena angka tanpa diagnosis hanya tebakan.
Periksa Baris Sleep di Processlist
Jalankan SHOW FULL PROCESSLIST; atau baca tabel processlist untuk melihat pola mysql sleep connections wait_timeout wordpress secara langsung. Kolom Command bernilai Sleep menandai thread menganggur, dan kolom Time menunjukkan sudah berapa detik ia diam.
-- Ilustrasi: melihat baris Sleep dan lama diamnya.
SHOW FULL PROCESSLIST;
-- atau dari information_schema:
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE
FROM information_schema.PROCESSLIST
WHERE COMMAND = 'Sleep' ORDER BY TIME DESC;Urutkan berdasarkan kolom waktu menurun untuk menemukan koneksi tidur tertua. Jika banyak baris Sleep berumur ratusan detik dari pengguna aplikasi yang sama, timeout global yang longgar membiarkan mereka menumpuk.
Identifikasi Sumber Script yang Menahan Koneksi
Jangan terburu-buru menyalahkan database. Periksa apakah ada panggilan API pihak ketiga yang menggantung di skrip PHP, worker cron yang terhenti di tengah tugas, atau webhook pembayaran yang menunggu callback. Koneksi tidur adalah gejala, skrip yang menahannya adalah penyakit.
Pantau log error PHP pada rentang waktu tumpukan Sleep muncul untuk menemukan skrip yang timeout ke layanan luar. Perbaiki skripnya dulu: batasi waktu tunggu HTTP, tutup koneksi database yang tidak dipakai, dan pecah proses panjang menjadi batch kecil.
Tentukan Nilai Timeout yang Seimbang
Untuk web WordPress dinamis, rentang 30 sampai 60 detik biasanya cukup: cepat membebaskan slot yang ditinggalkan skrip selesai, longgar untuk jeda antar-query yang wajar. Toko dengan cron berat dapat naik ke 60 sampai 120 detik. Tabel berikut merangkum pilihannya.
| Skenario Beban Kerja | Rentang wait_timeout yang Disarankan | Alasan Pemilihan Nilai | Risiko yang Perlu Diwaspadai |
|---|---|---|---|
| Situs Blog dan Toko Standar | 30-60 detik | Cepat membebaskan slot koneksi yang ditinggalkan skrip web selesai | Aman untuk hampir semua alur kerja normal WordPress |
| Toko WooCommerce dengan Cron Berat | 60-120 detik | Memberi kelonggaran bagi sinkronisasi katalog atau export data | Slot koneksi bertahan sedikit lebih lama di memori |
| Nilai Ekstrem (< 15 detik) | Dihindari | Menutup koneksi terlalu cepat sebelum skrip selesai memproses data | Memicu error MySQL server has gone away pada transaksi |
Pada server yang kamu kelola sendiri, terapkan dinamis dengan SET GLOBAL wait_timeout = 60; lalu simpan permanen di berkas my.cnf pada grup mysqld agar bertahan setelah restart. Nilai global baru hanya berlaku untuk koneksi yang dibuka sesudahnya, bukan koneksi yang sudah tidur.
Pengelolaan Timeout di Cloud Hosting dan Managed VPS
Di Cloud Hosting Mordenhost, parameter ini dikelola terpusat oleh sistem hosting untuk melindungi seluruh pengguna server bersama. Tidak ada akses berkas my.cnf maupun perintah SET GLOBAL di sini, jadi knop timeout bukan sesuatu yang bisa diubah dari paket ini.
Tim yang butuh menyetel timeout sesuai arsitektur aplikasinya memerlukan akses server penuh. Managed VPS Mordenhost cocok untuk kasus ini, mulai Rp950.000 per bulan: processlist dan variabel global dapat dibaca dan diubah langsung. Fondasi cara server bekerja dijelaskan ringkas di artikel memahami cara kerja hosting.
Bagi situs profil dan toko standar, nilai bawaan Cloud Hosting sudah dioptimalkan otomatis. Jika traffic dinamis tinggi dan butuh fleksibilitas penuh atas konfigurasi database, Managed VPS adalah jalannya.
Pertanyaan yang Sering Ditanya
Empat jawaban singkat soal Sleep, perbedaan timeout, risiko nilai ekstrem, dan akses di Cloud Hosting.
Apakah koneksi berstatus Sleep memakan beban CPU server?
Tidak. Status Sleep berarti koneksi database sedang menganggur menunggu instruksi berikutnya dari PHP. Koneksi ini tidak memakai beban CPU query, tetapi tetap menyita satu slot koneksi aktif dan alokasi memori buffer sesi.
Mengapa mengubah interactive_timeout tidak berpengaruh pada WordPress?
Karena klien web seperti PHP-FPM tidak memakai opsi koneksi interaktif saat menyambung ke database. Koneksi PHP membaca batas wait_timeout, sedangkan interactive_timeout hanya berlaku untuk sesi terminal atau aplikasi manajemen konsol interaktif.
Apa bahaya jika wait_timeout disetel terlalu rendah di WordPress?
Terlalu rendah memicu galat MySQL server has gone away pada query laporan WooCommerce atau proses backup yang butuh jeda waktu tunggu antar query. Sebaliknya, terlalu tinggi membiarkan koneksi zombie menumpuk dan menghabiskan batas max_connections.
Bisakah saya mengubah nilai wait_timeout di paket Cloud Hosting?
Tidak lewat berkas konfigurasi database. Server Cloud Hosting mengelola batas timeout terpusat demi stabilitas bersama. Pengguna yang memerlukan penyesuaian khusus atau optimasi aplikasi intensif dapat mengelolanya secara mandiri di Managed VPS.
Butuh bantuan membaca processlist atau memilih paket yang pas? Hubungi WhatsApp Mordenhost dan tim kami membantu memetakan langkah berikutnya.
