Mengira Error 503 di LiteSpeed Berarti Server Down, Padahal Limit Proses Akun Penuh

Situs tiba-tiba menampilkan 503 Service Unavailable, dan reaksi pertama hampir selalu sama: servernya down. Padahal kalau dicek, situs lain di server yang sama jalan normal, cPanel bisa dibuka, email tetap masuk. Di LiteSpeed, 503 jauh lebih sering berarti satu akun kehabisan jatah proses PHP daripada mesin yang benar-benar mati. Asumsi 'server down' ini wajar, karena kode 503 memang terdengar seperti layanan berhenti total. Tapi kalau langsung minta restart server atau upgrade paket, masalahnya biasanya muncul lagi di jam sibuk berikutnya. Yang perlu dipahami dulu adalah bagaimana LiteSpeed menjalankan PHP dan di titik mana request bisa ditolak.

Kenapa 503 bukan tanda server mati

Kalau server benar-benar down, kamu biasanya tidak dapat halaman error apa pun. Browser akan timeout, koneksi ditolak, atau ping tidak dibalas. Halaman 503 justru bukti bahwa web server masih hidup dan masih sanggup menjawab. LiteSpeed menerima request kamu, mencoba meneruskannya ke PHP, gagal mendapat jawaban tepat waktu, lalu mengembalikan 503. Jadi 503 artinya kira-kira begini: web server sehat, tapi aplikasi di belakangnya tidak tersedia untuk request ini. Dan di shared hosting atau reseller, 'aplikasi di belakangnya' itu dibatasi per akun, bukan per server. Ini juga alasan kenapa tes paling cepat sebelum panik adalah membuka situs lain di server yang sama, atau membuka file statis di akun yang bermasalah, misalnya gambar atau file .txt. Kalau file statis tampil normal tapi halaman PHP 503, hampir pasti masalahnya di lapisan PHP akun itu.

Cara LiteSpeed membagi proses PHP per akun

LiteSpeed tidak menjalankan PHP di dalam prosesnya sendiri. Ia mengirim request ke proses terpisah bernama lsphp lewat protokol LSAPI (LiteSpeed Server API, protokol komunikasi antara LiteSpeed dan proses PHP). Di lingkungan hosting, lsphp biasanya berjalan dengan mode suEXEC, artinya proses PHP jalan sebagai user pemilik akun, bukan sebagai user web server. Ini bagus untuk keamanan dan isolasi. Konsekuensinya, setiap akun punya batas berapa proses PHP yang boleh jalan bersamaan. Di LiteSpeed batas ini diatur lewat setting koneksi maksimum untuk PHP suEXEC atau variabel seperti LSAPI_CHILDREN, tergantung versi dan cara konfigurasinya. Kalau server memakai CloudLinux, ada lapisan batas lagi: entry process (EP), yaitu jumlah request dinamis yang boleh masuk ke akun secara bersamaan, dan NPROC, yaitu total proses yang boleh dimiliki user. Alurnya kurang lebih begini:

Request masuk ke LiteSpeed.
LiteSpeed mencari proses lsphp milik akun itu yang sedang kosong.
Kalau semua sedang sibuk dan jumlahnya sudah di batas, request masuk antrean.
Kalau dalam waktu tertentu tidak ada proses yang bebas, LiteSpeed menyerah dan mengembalikan 503.

Perlu dicatat, di server CloudLinux batas EP yang penuh sering muncul sebagai 508 Resource Limit Reached, bukan 503. Bentuknya tergantung konfigurasi server dan batas mana yang tersentuh duluan. Kalau yang kamu lihat 508, penjelasannya ada di artikel Kenapa Muncul Error 508 di cPanel Padahal Trafik Website Normal. Mekanisme dasarnya sama: jatah per akun habis, bukan server yang tumbang.

Kenapa jatah proses bisa habis padahal trafik biasa saja

Ini bagian yang paling sering membingungkan. Pemilik situs melihat statistik pengunjung normal, lalu merasa tidak mungkin limit-nya penuh. Kuncinya ada di durasi, bukan cuma jumlah. Batas proses mengukur berapa request yang sedang diproses pada detik yang sama. Kalau satu halaman biasanya selesai dalam waktu singkat, beberapa proses saja cukup untuk melayani banyak pengunjung karena proses cepat bebas lagi. Tapi kalau setiap request tertahan lama, proses yang sama terkunci dan request berikutnya mengantre. Penyebab request tertahan lama biasanya salah satu dari ini:

Query database lambat, misalnya tabel besar tanpa index yang tepat atau plugin yang menjalankan query berat di setiap halaman.
Panggilan ke layanan eksternal yang timeout, seperti API pembayaran, cek lisensi plugin, atau font dan script dari pihak ketiga yang dipanggil dari sisi server.
Brute force ke wp-login.php atau xmlrpc.php. Setiap percobaan login tetap memakai satu proses PHP, dan bot bisa mengirimnya bersamaan dalam jumlah banyak.
Crawler agresif atau bot yang menjelajah halaman pencarian, filter produk, atau URL dengan parameter yang tidak ter-cache.
WP-Cron yang dipicu setiap kunjungan dan menjalankan tugas berat.

Pola yang sering terlihat: semuanya normal sampai satu komponen melambat, lalu dalam waktu singkat semua proses akun terisi request yang menunggu komponen itu. Dari luar terlihat seperti situs mati mendadak. Dari dalam, PHP sebenarnya sibuk, hanya sibuk menunggu. Menaikkan memory_limit juga tidak membantu di kasus ini, karena itu batas memori per proses, bukan jumlah proses. Soal itu sudah dibahas di Mengira Naikkan memory_limit PHP Bikin Website Lebih Cepat.

Cara mengecek sebelum menyimpulkan

Urutan pengecekan yang biasanya paling efisien di meja support: pastikan situs lain di server normal, pastikan file statis di akun itu normal, lalu baru lihat log. Kalau kamu punya akses root, error log LiteSpeed adalah tempat pertama. Di banyak instalasi lokasinya /usr/local/lsws/logs/error.log, tapi bisa berbeda tergantung setup.

BASH

# Cari pesan terkait batas proses PHP di error log LiteSpeed (read-only)
grep -iE 'max children|max connections|503' /usr/local/lsws/logs/error.log | tail -n 50

Pesan yang perlu dicari kira-kira berbentuk seperti ini. Teks persisnya bisa berbeda antar versi.

TEXT

# contoh format output, bukan dari insiden nyata
[UID:1001][PID:12345] Reached max children process limit: 10, extra: 0, current: 10, busy: 10, please increase LSAPI_CHILDREN.

Bagian yang penting adalah busy yang sama dengan batasnya. Artinya semua proses akun sedang terpakai, dan request baru tidak kebagian. Kalau ingin melihat kondisi saat itu juga, hitung proses lsphp milik user tersebut. Ganti namauser dengan username akun.

BASH

# Hitung proses lsphp yang sedang berjalan untuk satu user (read-only)
ps -u namauser -o comm= | grep -c lsphp

Jalankan beberapa kali dengan jeda. Kalau angkanya terus mentok di nilai yang sama saat 503 muncul, itu konfirmasi bahwa batas proses yang jadi masalah. Untuk server CloudLinux, cek juga riwayat fault di menu Resource Usage cPanel atau di LVE Manager WHM. Fault EP atau NPROC yang sering tercatat di jam yang sama dengan laporan 503 sudah menjawab sebagian besar pertanyaan. Ketersediaan menu ini tergantung apakah server memakai CloudLinux. Langkah berikutnya adalah mencari request apa yang memenuhi proses tadi. Lihat access log domain di sekitar waktu kejadian. Di cPanel biasanya ada di folder domlogs, tapi lokasinya berbeda antar versi. Yang dicari adalah pola: banyak POST ke wp-login.php atau xmlrpc.php, satu IP yang meminta ratusan URL, atau satu endpoint yang selalu muncul tepat sebelum 503 mulai. Kalau ada akses ke MySQL slow query log atau slow log PHP, cocokkan juga waktunya.

Kenapa upgrade server jarang jadi jawaban

Permintaan yang paling umum setelah 503 adalah upgrade ke server yang lebih besar. Masalahnya, batas proses itu melekat ke akun, bukan ke ukuran mesin. Server dengan CPU dan RAM dua kali lipat tidak akan menambah jatah proses akunmu kalau limit-nya tetap sama. Bahkan kalau limit dinaikkan, misalnya pindah ke paket dengan EP lebih besar, hasilnya tergantung penyebabnya. Kalau penyebabnya query lambat atau API eksternal yang timeout, menambah proses hanya berarti lebih banyak proses yang ikut menunggu. Situs bertahan sedikit lebih lama sebelum 503 muncul lagi, dan beban ke database ikut naik. Kalau penyebabnya bot, tambahan proses akan ikut dihabiskan bot juga. Pola yang lebih tahan di produksi biasanya seperti ini. Pertama, kurangi jumlah request yang perlu masuk ke PHP sama sekali. Page cache seperti LSCache membuat halaman yang sama dilayani langsung oleh LiteSpeed tanpa menyentuh lsphp, jadi proses PHP hanya dipakai untuk yang benar-benar dinamis. Kedua, potong request yang tidak perlu: batasi akses xmlrpc.php kalau tidak dipakai, lindungi halaman login, dan blokir crawler yang tidak membawa manfaat. Ketiga, perbaiki bagian yang lambat, entah query, plugin, atau panggilan eksternal yang perlu timeout lebih pendek. Baru setelah itu, kalau trafik sah memang butuh lebih banyak proses bersamaan, menaikkan limit atau upgrade paket jadi keputusan yang masuk akal dan terukur. Aku biasanya menganggap permintaan upgrade sebagai pertanyaan terakhir, bukan pertama. Kalau log menunjukkan proses penuh karena request lambat, upgrade cuma menunda. Kalau log menunjukkan proses penuh karena pengunjung sah yang memang ramai dan halaman sudah ter-cache, upgrade memang jawabannya. Jadi lain kali 503 muncul di LiteSpeed, jangan langsung minta restart atau upgrade. Cek dulu apakah situs lain dan file statis masih normal, lihat error log untuk pesan batas proses, hitung proses lsphp akun, lalu cari request apa yang menahan proses itu. Dalam banyak kasus, jawabannya ada di satu plugin, satu query, atau satu bot, dan memperbaikinya jauh lebih murah daripada pindah server.