Menaikkan memory_limit Tidak Selalu Mengatasi Error Allowed memory size exhausted

Begitu muncul error Allowed memory size of ... bytes exhausted, saran yang paling sering keluar adalah: naikkan memory_limit. Dari 128M ke 256M, lalu 512M, kadang langsung -1. Sebagian kasus memang selesai di situ. Tapi cukup sering error-nya tetap muncul, cuma angkanya yang ikut naik. Kalau begitu, batasnya bukan masalah utama. Ada sesuatu di kode yang terus memakan memori sampai batas berapa pun akhirnya tercapai.

Apa yang sebenarnya dibatasi memory_limit

memory_limit adalah batas memori untuk satu eksekusi skrip PHP. Batas ini berlaku per request, di dalam satu proses worker, misalnya satu child PHP-FPM atau satu proses LSAPI di LiteSpeed. Angka ini bukan jatah RAM server dan tidak menambah RAM apa pun. Fungsinya pagar pengaman: kalau satu skrip bermasalah, PHP menghentikannya dengan fatal error sebelum skrip itu menghabiskan memori seluruh mesin. Karena itu, menaikkan memory_limit artinya melonggarkan pagar, bukan menyediakan memori baru. Di VPS dengan PHP-FPM, efeknya terasa di skenario terburuk. Contoh ilustrasi: 20 worker dengan limit 512M secara teori bisa memakai sekitar 10 GB. Kalau RAM VPS cuma 4 GB, yang biasanya terjadi bukan error PHP lagi. Kernel kehabisan memori, lalu OOM killer mulai mematikan proses, dan yang sering kena justru MySQL. Nilai -1 lebih berisiko lagi karena pagarnya dicabut sama sekali. Jadi pertanyaan yang lebih berguna bukan berapa limit yang cukup. Pertanyaannya: kenapa request ini butuh memori sebanyak itu?

Membaca pesan error sebelum mengubah angka

Pesan error ini sebenarnya cukup informatif kalau dibaca utuh. Ini contoh format output dari error log, bukan dari kejadian nyata:

TEXT

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /home/user/public_html/wp-includes/class-wpdb.php on line 2200

Ada tiga bagian yang perlu diperhatikan. Pertama, 268435456 bytes adalah limit yang sedang berlaku, yaitu 256M (256 × 1024 × 1024). Dari sini kamu bisa memastikan limit yang terbaca PHP memang nilai yang kamu set. Kalau angkanya masih 134217728 (128M) padahal kamu sudah mengubah konfigurasi, berarti perubahannya tidak dimuat. Itu masalah lain, dan dibahas di artikel tentang memverifikasi php.ini yang dimuat. Kedua, tried to allocate adalah ukuran alokasi terakhir yang gagal, bukan total memori yang dibutuhkan. Kalau angkanya kecil, misalnya beberapa KB, skrip itu sudah memakai hampir seluruh 256M sedikit demi sedikit, dan alokasi kecil ini cuma jadi tetes terakhir. Kalau angkanya besar, misalnya puluhan MB sekaligus, biasanya ada satu objek besar yang dibuat dalam sekali jalan, seperti gambar yang di-decode, string respons API, atau isi file yang dibaca utuh. Ketiga, file dan baris di akhir pesan adalah tempat alokasi terakhir terjadi, belum tentu pelakunya. Sering yang muncul file inti seperti class-wpdb.php, plugin.php, atau fungsi serialize. Itu wajar, karena semua plugin lewat jalur yang sama. Lokasi ini petunjuk awal, bukan vonis. Tes paling sederhana: bandingkan pesan error sebelum dan sesudah limit dinaikkan. Kalau di 512M error-nya muncul di lokasi yang sama, dengan tried to allocate yang kecil lagi, berarti memori terus tumbuh sampai batas apa pun. Itu pola kebocoran atau loop, bukan kekurangan.

Kapan memori memang kurang

Ada pekerjaan yang memang wajar butuh memori besar. Pengolahan gambar contoh paling umum. File JPEG 2 MB di disk bisa jauh lebih besar setelah di-decode ke memori, karena library seperti GD menyimpan setiap pixel tanpa kompresi. Sebagai ilustrasi kasar, gambar 6000 × 4000 pixel dengan sekitar 4 byte per pixel sudah mendekati 96 MB, belum termasuk salinan saat membuat thumbnail. Pekerjaan berat lainnya: impor atau ekspor CSV besar, laporan toko online dengan banyak order, plugin backup yang mengompres file, dan page builder di halaman admin. Cirinya cukup konsisten. Error hanya muncul saat aksi tertentu, bukan di semua halaman. Kenaikan yang masuk akal, misalnya dari 128M ke 256M, membuatnya berhenti dan tetap stabil. Pemakaian memori juga tidak terus naik seiring waktu. Untuk kasus seperti ini, menaikkan limit memang jawaban yang benar. Tapi lebih aman kalau dinaikkan sesempit mungkin. Di WordPress ada WP_MAX_MEMORY_LIMIT yang dipakai untuk proses admin, terpisah dari WP_MEMORY_LIMIT untuk request biasa. Pekerjaan yang sangat berat seperti migrasi atau impor besar lebih baik dijalankan lewat CLI dengan limit khusus, misalnya memakai opsi php -d memory_limit=1G saat menjalankan skrip. Dengan begitu, worker web yang melayani pengunjung tetap memakai pagar yang ketat.

Kapan menaikkan limit hanya menunda error

Pola yang sering muncul di sisi lain cukup mudah dikenali kalau tahu yang dicari. Rekursi tanpa ujung adalah fungsi yang memanggil dirinya sendiri, langsung atau tidak langsung. Contoh klasik di WordPress: callback pada hook save_post yang memanggil wp_update_post. Fungsi itu memicu save_post lagi, dan begitu seterusnya. Setiap putaran menambah memori, jadi limit 128M atau 1G sama-sama akan habis. Yang berbeda cuma berapa lama sampai habis. Query yang menarik semua baris sekaligus juga sering jadi penyebab. Contohnya SELECT tanpa LIMIT di tabel besar, atau posts_per_page bernilai -1 di situs dengan puluhan ribu post. Hasil query ditampung utuh di memori PHP. Situs seperti ini sering aman di awal, lalu mulai error seiring datanya bertambah. Menaikkan limit cuma menunggu data tumbuh lagi. Autoloaded options yang membengkak adalah penyebab yang sering terlewat. WordPress memuat semua opsi bertanda autoload dari tabel wp_options di setiap request. Kalau ada plugin yang menyimpan log, cache, atau data besar di sana dengan autoload aktif, setiap halaman, termasuk homepage yang sederhana, langsung memakai banyak memori sebelum mengerjakan apa pun. Cirinya, error muncul di halaman mana saja, bukan di satu aksi tertentu. Konflik atau bug plugin setelah update juga sering terjadi. Pemicunya biasanya jelas dari waktunya: situs normal, plugin di-update, lalu error mulai muncul. Dari meja support, ini juga yang paling sering membingungkan pemilik situs. Limit sudah dinaikkan dua kali dan error tetap ada, jadi mereka merasa hosting-nya yang kurang. Padahal yang perlu dicari adalah di file mana dan kapan error itu muncul, bukan berapa angka limit-nya.

Melacak penyebabnya dari log

Langkah pertama, temukan error log yang benar. Lokasinya tergantung setup. Di banyak shared hosting dengan cPanel, ada file error_log di folder situs atau subfoldernya. Di VPS, bisa di log PHP-FPM atau log web server. Di WordPress dengan WP_DEBUG_LOG aktif, ada di wp-content/debug.log. Kalau tidak yakin, cek nilai error_log lewat phpinfo dari panel. Hasil php -i di terminal bisa berbeda, karena PHP CLI sering memakai konfigurasi lain dari PHP yang melayani web. Setelah log ketemu, jangan baca satu baris saja. Kelompokkan lokasi error-nya supaya kelihatan polanya:

BASH

# Hitung lokasi error memory exhausted yang paling sering muncul (read-only)
grep 'Allowed memory size' error_log | grep -o 'in /.* on line [0-9]*' | sort | uniq -c | sort -rn | head

Kalau hasilnya didominasi satu file di dalam folder plugin tertentu, kandidatnya sudah jelas. Kalau yang muncul file inti WordPress, cocokkan waktu error dengan access log untuk melihat URL apa yang sedang diakses. Halaman admin plugin tertentu, endpoint AJAX, atau cron sering memberi petunjuk yang lebih tajam daripada nama file. Untuk mencurigai autoload, cek total ukurannya langsung di database. Sesuaikan prefix tabel dengan yang ada di wp-config.php. Daftar nilai autoload juga tergantung versi WordPress:

SQL

-- Total ukuran opsi yang dimuat di setiap request (read-only)
SELECT COUNT(*) AS jumlah, ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS ukuran_mb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

Kalau angkanya terasa besar untuk situs sekecil itu, urutkan per option_name berdasarkan LENGTH(option_value) untuk melihat opsi mana yang paling berat. Biasanya nama opsinya sudah menunjuk ke plugin pemiliknya. Jangan langsung menghapus baris di sana tanpa backup, karena beberapa opsi besar memang dibutuhkan plugin untuk berjalan. Untuk mengisolasi plugin, lakukan di staging kalau ada. Menonaktifkan plugin bisa lewat WP-CLI dengan wp plugin deactivate nama-plugin, atau dengan mengganti nama foldernya di wp-content/plugins kalau dashboard tidak bisa diakses. Nonaktifkan satu per satu, mulai dari yang muncul di log atau yang terakhir di-update, lalu ulangi aksi yang memicu error. Kalau masih buntu, kamu bisa mencatat memory_get_peak_usage(true) sementara di titik tertentu untuk melihat bagian mana yang membuat memori melonjak, atau memakai profiler seperti Xdebug di lingkungan non-produksi. Hapus kode diagnostik itu setelah selesai. Aturan praktisnya begini. Naikkan memory_limit sekali ke angka yang masuk akal untuk pekerjaan yang memang berat, idealnya hanya di konteks yang butuh, lalu pantau. Kalau error-nya pindah ke batas yang lebih tinggi di lokasi yang sama, berhenti menaikkan angka. Baca tried to allocate, kelompokkan lokasi error di log, cek autoload dan query besar, lalu cari plugin atau kode yang membuat memori terus tumbuh. Limit yang rendah tapi stabil jauh lebih sehat daripada limit besar yang cuma membuat server kehabisan RAM pelan-pelan.