Layar putih muncul tepat saat kamu menyimpan halaman Elementor besar, atau email Fatal error Allowed memory size of bytes exhausted masuk saat plugin backup berjalan. Forum menyuruh edit wp-config.php, sudah dicoba, Site Health tidak berubah sama sekali. Di titik inilah wp memory limit wordpress perlu dibedah dari akarnya: dua lapis batas yang saling mengunci, cara membaca diagnosis yang benar, dan rumus RAM agar keputusan menaikkan limit tidak menjadi bom waktu. Panduan ini menjelaskan perbedaan konstanta dan limit PHP, cara diagnosis bertahap, lalu rumus aman agar RAM server tetap hidup berdampingan.
Apa Itu WP Memory Limit dan Kenapa WordPress Punya Batas Sendiri?
WP_MEMORY_LIMIT adalah konstanta di wp-config.php yang menjadi permintaan bukan kunci pas dari WordPress kepada PHP. Nilainya menentukan berapa memori yang diminta WordPress untuk request normal. Nilai default menurut dokumentasi resmi WordPress adalah 40 MB untuk single site dan 64 MB untuk multisite.
Pendampingnya adalah WP_MAX_MEMORY_LIMIT yang berlaku khusus context admin untuk tugas berat di dashboard, misalnya update massal dan olah media. Nilai default menurut dokumentasi resmi WordPress adalah 256 MB. Kedua konstanta ini diterapkan WordPress lewat runtime memakai fungsi ini_set saat proses berjalan, bukan lewat restart layanan.
Kunci pemahamannya: konstanta hanya meminta, keputusan akhir ada di lapisan PHP dan server. Jika lapisan bawah lebih kecil, permintaan besar otomatis dipangkas.
Dua Lapis Batas Memori: WP_MEMORY_LIMIT, memory_limit, dan Hard Limit PHP-FPM
Pembahasan wp_memory_limit vs memory_limit selalu kembali ke urutan eksekusi. WordPress memanggil ini_set untuk menaikkan batas saat proses dimulai. Panggilan itu berhasil hanya bila nilai yang diminta masih berada di bawah memory_limit PHP yang dibaca dari php.ini atau .user.ini.
Lapisan ketiga adalah php_admin_value di konfigurasi pool PHP-FPM, misalnya berkas www.conf. Saat admin server mengunci memory_limit lewat direktif ini, seluruh panggilan ini_set dari aplikasi diabaikan total tanpa peringatan. Inilah akar kasus klasik define 512M tidak mengubah Site Health sama sekali.
Nilai efektif akhirnya adalah hasil interaksi semua lapisan yang dirangkum diagram berikut. Permintaan tidak pernah bisa menembus lapisan di bawahnya, hanya bisa bergerak di dalam ruang yang diizinkan lapisan bawah.
Fatal Error Allowed Memory Size Exhausted: Penyebab dan Mitos Edit wp-config.php
Frasa pencarian allowed memory size exhausted wordpress hampir selalu muncul setelah operasi berat. Elementor me-render template besar dengan banyak widget, WooCommerce memproses checkout dengan varian banyak, plugin backup menjalankan dump database penuh, atau import CSV ribuan baris. Request normal hanya memakai sebagian kecil alokasi, sedangkan operasi ini mendekati langit langit sekaligus dalam satu proses.
Mitosnya berbunyi tambah satu baris define maka semua beres. Kenyataannya ada dua titik gagal. Pertama, baris define ditulis di posisi baris konstanta salah sehingga tidak pernah dibaca sebelum WordPress memuat pengaturan. Kedua, server mengunci batas keras di level pool sehingga permintaan WordPress ditolak diam diam.
Sejak WordPress 5.2 ada konteks tambahan berupa fatal error protection dan recovery mode yang mencoba menangkap error fatal dan memberi tautan pemulihan ke dashboard. Fitur ini membantu masuk kembali, tetapi tidak menambah memori.
Tabel Arsitektur Memori: Hirarki Limit dari Konstanta sampai RAM Fisik
Lima lapisan berikut menentukan limit efektif dan siapa yang berkuasa di tiap lapisan. Pemilik situs menguasai dua lapis teratas, admin server menguasai dua lapis tengah. Pengguna shared hosting hanya bisa bermain di lapis konstanta.
| Lapisan | Diatur di Mana | Siapa yang Bisa Mengubah | Perilaku dan Interaksi |
|---|---|---|---|
WP_MEMORY_LIMIT | wp-config.php | Pemilik situs | Permintaan WordPress ke PHP; default 40 MB single site dan 64 MB multisite menurut dokumentasi resmi; diterapkan lewat ini_set saat runtime |
WP_MAX_MEMORY_LIMIT | wp-config.php | Pemilik situs | Langit langit context admin untuk tugas berat dashboard; default 256 MB menurut dokumentasi resmi; berdiri di atas WP_MEMORY_LIMIT tetapi tunduk ke lapisan bawah |
memory_limit PHP | php.ini, .user.ini | Admin server; pemilik situs bila diizinkan | Langit langit runtime tiap proses PHP; bisa dinaikkan lewat ini_set hanya bila policy server mengizinkan |
php_admin_value pool PHP-FPM | Konfigurasi pool seperti www.conf | Admin server saja | Hard limit yang membuat ini_set diabaikan total; penyebab konstanta dinaikkan tetapi tidak berefek |
| RAM fisik server | Perangkat keras | Tidak bisa diubah dari aplikasi | Batas akhir seluruh proses; pelanggaran tidak memberi error PHP melainkan OOM Killer mematikan proses paksa |
Setelah peta jelas, langkah berikutnya bukan menaikkan angka, melainkan membaca nilai aktif dan kebutuhan nyata.
Cara Mendiagnosis dan Mengatur Batas Memori WordPress dengan Aman
Diagnosis selalu mendahului perubahan agar keputusan berbasis angka aktual bukan firasat. Alurnya tiga tahap: cek nilai aktif, nilai kebutuhan nyata, lalu terapkan dengan hormat pada rumus RAM.
Mengecek Limit Aktif via Site Health, php -i, dan WP-CLI
Buka Tools lalu Site Health lalu Info lalu Server untuk membaca WordPress memory limit dan PHP memory limit berdampingan. Selisih keduanya menunjukkan lapisan mana yang membatasi saat ini.
Verifikasi dari sisi server memakai dua perintah berikut. Perintah pertama membaca konfigurasi PHP global, perintah kedua membaca konstanta yang dikenali WordPress saat runtime berjalan.
php -i | grep memory_limit
wp eval 'echo WP_MEMORY_LIMIT;'
wp eval 'echo WP_MAX_MEMORY_LIMIT;'Menilai Kebutuhan Nyata Situs Berdasarkan Plugin dan Operasi Berat
Catat momen error: halaman apa yang disimpan, plugin apa yang aktif, dan apakah error hilang saat tema default dipakai dengan plugin dimatikan.
Situs katalog kecil jarang butuh lebih dari default dokumentasi resmi. Situs Elementor plus WooCommerce wajar menuntut langit langit lebih tinggi pada momen puncak. Naik limit hanya menjawab kebutuhan puncak yang terukur, bukan mempercepat request normal.
Menerapkan Limit Baru Tanpa Melanggar Rumus RAM Server
Urutannya: konstanta dulu, lalu konfigurasi PHP bila diizinkan, lalu minta penyedia hosting untuk lapisan yang dikunci. Setiap kenaikan wajib dihitung terhadap rumus kapasitas server tersedia sebelum disimpan.
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );Setelah menyimpan, muat ulang Site Health dan pastikan angka baru terbaca. Jika angka tidak berubah, kembali ke diagnosis lapisan: kemungkinan besar server mengunci batas keras sehingga permintaan aplikasi ditolak diam diam.
Rumus Aman RAM Server: pm.max_children x memory_limit dan Bahaya OOM Killer
Rumusnya satu baris: total potensi pemakaian PHP-FPM harus tetap di bawah RAM tersedia setelah porsi sistem, MariaDB, dan Redis.
pm.max_children x memory_limit + overhead < RAM tersediaContoh ilustrasi perkiraan pada server 4 GB: porsi sistem plus MariaDB plus Redis sekitar 1,6 GB sehingga sisa untuk PHP-FPM sekitar 2,4 GB. Konfigurasi 40 worker dengan memory_limit 256M berpotensi meminta 10,24 GB sekaligus sehingga total melebihi RAM fisik. Konfigurasi 9 worker dengan 256M hanya meminta sekitar 2,3 GB sehingga muat di sisa 2,4 GB.
Pelanggaran rumus tidak menampilkan error PHP sama sekali. Kernel Linux memanggil OOM Killer yang memilih proses berjejak memori terbesar lalu mematikannya paksa tanpa peringatan, dan korbannya sering kali MariaDB. Mekanisme antrean worker yang menjadi korban tekanan ini dibahas di artikel PHP Worker WordPress sebagai fondasi konkurensi dinamis.
| RAM Server | Perkiraan Porsi OS plus MariaDB plus Redis | Sisa untuk PHP-FPM | max_children pada 128M | max_children pada 256M |
|---|---|---|---|---|
| 2 GB | sekitar 0,8 sampai 1 GB | sekitar 1 GB | 8 worker | 4 worker |
| 4 GB | sekitar 1,6 GB | sekitar 2,4 GB | 18 worker | 9 worker |
| 8 GB | sekitar 3 GB | sekitar 5 GB | 39 worker | 19 worker |
| 16 GB | sekitar 5,5 GB | sekitar 10,5 GB | 82 worker | 41 worker |
Seluruh angka tabel di atas adalah ilustrasi perkiraan efek penggandaan limit terhadap jumlah worker, bukan hasil pengukuran server Mordenhost. Porsi MariaDB mengikuti penjelasan InnoDB Buffer Pool WordPress di sisi database.
Menaikkan limit memori bukanlah akselerator, melainkan langit-langit yang lebih tinggi. Ia mencegah pekerja berat tersandung, tetapi tagihan RAM-nya harus dibayar oleh jumlah pekerja yang bisa hidup berdampingan di server yang sama.
WP Memory Limit dalam Peta Klaster Performa: PHP Worker, Autoload, dan OPcache
Limit hanyalah satu variabel dalam sistem memori. Jumlah worker menentukan berapa proses hidup berdampingan, muatan baseline tiap proses datang dari autoload wp_options, kecepatan eksekusi ditentukan OPcache, dan porsi database ditentukan Buffer Pool. Langit langit yang sama menampung lebih banyak bila baseline autoload ramping terukur sejak awal.
Urutkan optimasi dari yang murah: rampingkan autoload lewat Autoload Options WordPress, aktifkan bytecode lewat OPcache WordPress, percepat bacaan data lewat InnoDB Buffer Pool WordPress, lalu layani query berulang lewat Redis Object Cache WordPress.
Rekomendasi Hosting untuk Website dengan Beban Memori Berat
Mayoritas website Elementor dan WooCommerce tidak perlu menghitung rumus tiap pekan. Cloud Hosting Mordenhost memberi batas memori wajar terkelola yang dikonfigurasi sysadmin internal, plus dukungan teknis yang membantu membaca Site Health saat fatal error muncul.
Beban ekstrem dengan database besar butuh ruang hitung sendiri. Managed VPS Mordenhost memberi tuning enterprise alokasi memori dan bantuan menghitung pm.max_children serta porsi database. Gejala lanjutan seperti jeda respons dinamis bisa dipantau lewat TTFB WordPress sebelum naik kelas.
Kesimpulan
Limit memori adalah langit langit yang harus dihitung, bukan angka yang dinaikkan dengan keberanian. Diagnosis dulu, rumus kedua, limit terakhir.
Audit ulang setiap kali menambah plugin berat karena tiap plugin menambah baseline dan menggeser hasil rumus. Kalau fondasi server masih kabur, baca dulu memahami cara kerja hosting sebelum mengutak atik parameter lanjutan.
Pertanyaan yang Sering Ditanya
Empat jawaban singkat untuk pertanyaan paling umum soal nilai aman, konstanta macet, limit unlimited, dan mitos kecepatan.
Berapa nilai WP_MEMORY_LIMIT yang disarankan untuk WordPress?
Mayoritas situs Elementor dan WooCommerce nyaman di 256M untuk operasional harian normal. Nilai 512M hanya untuk kasus terukur seperti import besar atau backup dalam dashboard. Nilai efektif tetap dibatasi memory_limit PHP server.
Kenapa WP_MEMORY_LIMIT sudah dinaikkan tapi Site Health tidak berubah?
Dua penyebab: baris define berada di posisi salah sehingga tidak pernah dibaca, atau server mengunci memory_limit di level pool PHP-FPM sehingga permintaan WordPress diabaikan. Verifikasi selisih WordPress memory limit dan PHP memory limit di Site Health.
Apakah aman memakai memory_limit -1 alias unlimited di produksi?
Tidak aman untuk produksi karena satu proses boleh memakan seluruh RAM server. Saat kebocoran kecil terjadi berulang, OOM Killer mematikan proses terbesar tanpa peringatan, dan korbannya biasanya adalah MariaDB yang melayani semua query.
Apakah menaikkan memory limit membuat WordPress lebih cepat?
Tidak, karena limit adalah langit-langit bukan akselerator kecepatan eksekusi. Request normal hanya memakai sebagian kecil alokasi yang tersedia. Kecepatan datang dari cache: OPcache bytecode, Redis objek, dan Buffer Pool data.
Butuh bantuan membaca hasil diagnosis memori situsmu? Hubungi WhatsApp Mordenhost atau portal tiket dan tim kami membantu memetakan kebutuhan limit serta paket yang pas.
