Worker Habis, Query Log Kosong
Antrean request menumpuk, worker sibuk semua, tetapi catatan query lambat tidak menunjukkan apa-apa. Ini momen yang membingungkan karena alat diagnosis biasa mendadak bisu; php-fpm slow log wordpress yang bicara setelahnya. Slow query log hanya mendengar SQL, dan request yang macet belum tentu menunggu database.
Request bisa macet di tiga tempat lain: memanggil layanan luar lewat HTTP, berputar di loop plugin, atau antre di kunci file. Ketiganya menghabiskan waktu PHP tanpa pernyataan SQL, sehingga log query tidak punya apa-apa untuk dicatat. Worker tertahan, pengunjung menunggu.
Di sinilah slow log PHP-FPM masuk. Ia mencatat cuplikan tumpukan panggilan PHP pada request yang melewati ambang waktu, apa pun yang dikerjakannya. SQL atau bukan, tercatat. Bagian berikut menunjukkan bentuk catatan itu dan cara membacanya.
Slow Log FPM Mencatat Stack, Bukan Durasi per Fungsi
Ketika sebuah request melewati ambang request_slowlog_timeout, PHP-FPM menulis satu entri ke file slowlog: stempel waktu, nama pool, pid proses, lalu tumpukan panggilan (stack trace) yang sedang berjalan saat itu. Isinya adalah daftar fungsi dari yang paling dalam sampai pemanggilnya, bukan tabel durasi per fungsi.
Anggap entri itu foto bukan film. Satu foto membuktikan fungsi itu sedang berdiri di stack pada detik ambang terlewati, tetapi tidak membuktikan ia yang paling lama. Fungsi yang cepat pun ikut terfoto kalau kebetulan sedang berjalan. Kesimpulan kuat datang dari beberapa foto berurutan pada pid sama yang menunjukkan fungsi sama.
Satu stack hanya menunjukkan fungsi yang sedang berdiri di saat ambang terlewati. Itu bukan bukti bahwa fungsi itu yang paling lama, sebelum ada beberapa foto pada proses yang sama.
Entri slow log bukan profil performa. Ia tidak mencatat durasi tiap fungsi, tidak menjumlahkan waktu CPU, dan tidak mengurutkan biang kelambatan. Tugasnya sempit: memberi nama fungsi yang memegang worker saat itu.
Tiga Ambang yang Bukan Satu Kenop
Tiga direktif pool sering dianggap satu kenop yang sama, padahal kerjanya berbeda. request_slowlog_timeout wordpress hanya mencatat bukan menghentikan: request yang melewatinya tetap jalan, hanya stack-nya ditulis ke log. Nilai 0 berarti mati, tidak ada yang dicatat.
request_terminate_timeout adalah pemutus dari sisi FPM: request yang melewatinya dibunuh prosesnya. max_execution_time menghitung waktu CPU skrip PHP dari sisi PHP sendiri. Keduanya menghentikan, yang pertama hanya mencatat. Mencampur ketiganya membuat orang menaikkan ambang catat sambil berharap request berhenti, atau sebaliknya.
Detail batas waktu CPU dan cara mengukurnya dibahas satu kalimat di artikel max_execution_time WordPress: ia menghitung waktu CPU, sedangkan ambang slow log menghitung waktu dinding sejak request diterima. Dua jam yang berbeda untuk dua keperluan yang berbeda.
Aturannya sederhana: ambang catat berada di bawah ambang pemutus, supaya request sempat meninggalkan jejak sebelum dibunuh. Ambang catat yang lebih besar dari ambang pemutus tidak pernah menulis apa-apa, karena prosesnya mati duluan.
Kapan Pindah ke Slow Query Log
Pertanyaan php-fpm slow log vs slow query log terjawab dari frame teratas stack. Kalau frame teratas berdiri di driver MySQL atau MariaDB, request itu sedang menunggu database, dan slow query log adalah alat lanjutannya. Baca pernyataan SQL yang stempel waktunya berdekatan di artikel Slow Query Log WordPress.
Kalau frame teratas berdiri di klien HTTP, di loop plugin, atau di fungsi kunci file, slow query log tidak akan berisi apa pun tentang request itu. Bukan karena log-nya rusak, melainkan karena tidak ada SQL yang terlibat. Mengejar log query di sini hanya membuang waktu.
| Catatan | Yang masuk ke dalamnya | Yang tidak masuk |
|---|---|---|
| PHP-FPM slow log | Stack PHP saat request melewati request_slowlog_timeout | Durasi tiap query SQL |
| Slow query log MariaDB atau MySQL | Pernyataan SQL yang melewati long_query_time | Fungsi PHP yang memanggil API luar |
WP_DEBUG_LOG | Pesan yang kode sengaja tulis lewat mekanisme debug WordPress | Request yang macet tanpa ada notice atau warning |
Tiga catatan, tiga pertanyaan berbeda. Slow log FPM menjawab fungsi mana, slow query log menjawab SQL mana, debug log menjawab pesan apa. Memakai yang salah untuk pertanyaan yang benar menghasilkan kesimpulan yang salah dengan percaya diri.
Membaca Frame: Plugin, Inti, atau Tunggu
Baca php-fpm slowlog stack trace dari frame teratas ke bawah. Nama file di wp-content/plugins atau tema lebih informatif daripada baris di wp-includes yang hanya sedang memanggil. Inti WordPress hampir selalu ada di setiap stack karena semua request lewat sana, jadi kehadirannya bukan tuduhan.
Pisahkan tiga lapis: frame di plugin atau tema, frame inti WordPress, dan frame yang menunggu driver database. Kalau teratasnya plugin yang memanggil HTTP luar, tersangkanya jaringan luar. Kalau teratasnya driver database, tersangkanya query. Kalau hanya inti berulang di banyak request, pool-nya yang kehabisan slot.
Jangan menuduh plugin tertentu hanya dari satu stack. Satu foto bisa kebetulan. Beberapa entri berurutan pada pid yang sama yang menunjuk fungsi yang sama barulah pola, dan pola itulah yang layak ditindaklanjuti.
Ambang Terlalu Kecil Membuat Disk Ikut Sibuk
Setiap request yang melewati ambang menulis satu stack ke disk. Pada trafik tinggi dengan ambang yang sangat kecil, hampir semua request ikut menulis, file log membengkak, dan disk ikut sibuk melayani tulisan yang tidak ada gunanya. Ambang terlalu kecil mengubah alat diagnosis menjadi beban baru yang ikut memperlambat situs yang sedang didiagnosis.
Ambang nol mematikan pencatatan sama sekali, dan itu pilihan yang sah untuk situs yang tidak bermasalah. Alat ini tidak harus selalu menyala. Nyalakan saat ada keluhan worker tertahan, baca hasilnya, lalu putuskan: biarkan menyala dengan ambang wajar atau matikan lagi sampai dibutuhkan.
Ambang yang masuk akal berada di bawah ambang pemutus tetapi di atas waktu respons normal situs. Angka contoh seperti sepuluh detik hanyalah ilustrasi, bukan anjuran universal: situs dengan respons normal dua detik dan delapan detik butuh ambang berbeda. Sesuaikan dengan kebiasaan situsmu.
Slow Log di Peta Diagnosis Worker
Artikel worker menghitung berapa anak PHP yang boleh sibuk, dan itulah kapasitasnya. Slow log memberi nama pada pengisi kapasitas itu: fungsi mana yang menahan tiap slot. Detail kapasitas anak PHP ada di artikel PHP worker WordPress.
Tick Heartbeat hanya masuk log ini kalau kerja di dalamnya melewati ambang, yang jarang terjadi pada tick kosong. Satu kalimat konteksnya di artikel WordPress Heartbeat API: tick normal tidak meninggalkan jejak di sini, jadi entri dari admin-ajax.php yang berulang patut dibaca serius.
Cara Membaca PHP-FPM Slow Log pada Situs WordPress
Urutannya tetap: pastikan log hidup dan ambangnya waras, tangkap satu stack saat keluhan terjadi, baru putuskan log mana yang dilanjutkan. Jangan melompat ke kesimpulan sebelum ketiga langkah ini selesai.
Pastikan Ambang dan Path-nya
Baca request_slowlog_timeout wordpress dan slowlog pada pool yang melayani situsmu, bukan pada pool contoh. Nama direktif ini dicocokkan ke dokumentasi php.net sebelum artikel ini publish, dan cuplikan berikut hanya ilustrasi bentuknya:
; Ilustrasi: ambang catat di bawah ambang pemutus.
request_slowlog_timeout = 10s
slowlog = /var/log/php-fpm/www-slow.log
; Label ilustrasi: nama direktif dan
; format nilai wajib dicocokkan ke php.net.Kalau timeout-nya 0, log mati. Kalau path-nya tidak bisa ditulis proses PHP, tidak ada entri meski ambangnya benar. Dua cek ini menjawab sebagian besar keluhan log kosong.
Tangkap Stack pada Momen yang Sama dengan Keluhan
Ulangi tindakan yang lambat, simpan tulisan, jalankan cron, impor data, lalu baca entri yang stempel waktunya berdekatan dengan keluhan itu. Entri kemarin tidak menjelaskan kemacetan hari ini, karena proses dan trafiknya sudah berbeda.
Cari beberapa entri pada pid yang sama dalam rentang menit yang sama. Satu entri adalah foto, tiga entri berurutan yang menunjuk fungsi sama adalah pola. Hanya pola yang diteruskan ke langkah keputusan.
Pilih Lanjutan: Plugin, Query, atau Kapasitas
Tiga cabang sesuai tabel berikut. Jangan menaikkan jumlah anak PHP hanya karena ada satu stack: satu foto bukan bukti kapasitas kurang. Kapasitas pool dibahas tanpa rumus di artikel PHP worker WordPress, baca itu sebelum menyentuh konfigurasi pool.
| Frame teratas | Langkah berikut | Bukan langkah pertamanya |
|---|---|---|
File di wp-content/plugins atau tema | Baca apa yang fungsi itu lakukan pada saat itu (HTTP luar, loop, kunci) | Menaikkan jumlah anak PHP |
| Driver atau kelas database | Pindah ke slow query log untuk pernyataan yang sama waktunya | Menganggap SQL tidak terlibat |
Hanya inti wp-includes, berulang pada banyak request | Lihat apakah pool memang kehabisan slot, baru kemudian kapasitas | Mematikan sebuah plugin secara acak |
Cabang yang benar menghemat jam kerja. Cabang yang salah, menaikkan kapasitas untuk masalah plugin atau mematikan plugin untuk masalah kapasitas, membuang jam itu.
Rekomendasi Infrastruktur Saat Worker Lama Tidak Ketahuan
Situs yang macet tanpa jejak di log query paling cocok dikonsultasikan dulu. Cloud Hosting Mordenhost cocok untuk kasus ini: dukungan teknisnya membedakan request yang macet di plugin dari yang macet di database saat kamu melaporkan gejalanya, tanpa klaim akses file pool apa pun. Kamu fokus mengelola toko, tim teknis membaca gejalanya.
Tim yang perlu membaca slow log bersama kapasitas worker butuh akses yang lebih dalam. Managed VPS Mordenhost cocok untuk kasus ini: pool dan file slow log bisa dibaca langsung berdampingan dengan jumlah slot worker. Fondasi cara server bekerja dijelaskan ringkas di artikel memahami cara kerja hosting.
Pertanyaan yang Sering Ditanya
Empat jawaban singkat soal beda kedua log, ambang yang menghentikan, log query yang kosong, dan keamanan membiarkan slow log menyala.
Apakah slow log PHP-FPM sama dengan slow query log?
Tidak. Slow log FPM memotret fungsi PHP yang sedang berjalan. Slow query log mencatat SQL yang melewati ambangnya sendiri. Keduanya bisa kosong pada saat yang tidak sama.
Apakah request_slowlog_timeout menghentikan skrip?
Tidak. Ambang itu hanya menulis stack. Yang menghentikan request adalah batas waktu lain, di PHP maupun di pool, dan keduanya tidak boleh dicampur dengan ambang pencatatan.
Kenapa situs lambat tetapi slow query log kosong?
Karena waktu habis di luar SQL: panggilan ke layanan lain, loop di plugin, atau kunci. Slow log FPM tetap bisa berisi stack pada kasus itu, sedangkan log query memang tidak melihatnya.
Apakah slow log aman dibiarkan menyala terus?
Aman kalau ambangnya cukup tinggi sehingga hanya request yang benar-benar lama yang ditulis. Ambang yang terlalu kecil membuat file log besar dan disk ikut bekerja pada setiap request biasa.
Butuh bantuan membaca stack trace atau memilih paket yang pas? Hubungi WhatsApp Mordenhost dan tim kami membantu memetakan langkah berikutnya.
