memory_limit in your php.ini.”
But that’s not always the right thing to do. In fact, it can actively hurt your site’s uptime if you’re not careful.
What does PHP memory_limit actually do?
The PHP memory limit (memory_limit in php.ini) is not about allocating resources to your application. It’s a per-request safety cutoff. It kills individual requests that try to use too much memory.
On Upsun, the default is 128MB. That means if a single PHP request tries to use more than 128MB, PHP stops executing the script and logs that error you saw above.
This is a feature, not a bug.
The PHP memory limit: quality of service, not a resource
Imagine you have 10 PHP-FPM workers running at 25-35MB each. Then a page comes in with a bug - someone wrote a loop that doesn’t clear memory properly. That request starts consuming 200MB, 300MB, 500MB. Without a memory limit, that single request could consume all available container memory, causing the Out Of Memory killer to randomly terminate processes. Data gets corrupted. Things don’t shut down cleanly. Your site crashes unpredictably. With a memory limit, that single buggy request gets killed. The other 9 workers keep running fine. You see an error in your logs telling you exactly which page caused the problem. That’s when you can fix it.Why you shouldn’t be setting PHP memory_limit to 60G
When you see that memory exhausted error, your instinct should not be to increase the limit, but to dig into the underlying code using that much memory. There are use cases where it’s justified to increasememory_limit - image processing, report generation, large data exports. But generally speaking, you don’t want to run them on the web thread. And don’t blindly increase it. Especially not beyond the container size.
Setting the memory limit higher than your container memory doesn’t give you more memory. It removes the protection mechanism that prevents runaway requests from crashing your entire application.
If someone sets memory_limit: 60G on a container with only 512MB of RAM, they’ve removed the guardrail. Now a single buggy request can consume all 512MB of container memory, crash the entire container, and take the site down. The Out Of Memory killer will terminate random processes to try to reclaim memory, causing unpredictable failures and data corruption.
Side note: crons and workers
Cron runs do not have a memory_limit by default. But if your crons are using a lot of memory, they are probably going to run a lot better as a worker. See the workers documentation for more details.Best practices for memory-intensive tasks
Sometimes you legitimately need more memory for a specific operation - image resizing, report generation, large data exports. Don’t do this on the web thread. Use workers. Workers (separate background processes):- Spin up a dedicated worker for heavy tasks
- Set a higher memory limit on that specific worker
- Use a queue system (RabbitMQ, Redis, or even database-backed queues)
- Process tasks sequentially, not all at once
- Predictable memory usage, no spiky traffic
Keep your memory limit reasonable
The PHPmemory_limit setting is a safety mechanism, not a resource allocation. It protects your application from catastrophic failures caused by runaway requests.
When you see a memory exhausted error, resist the temptation to just bump up the limit. Instead:
- Investigate the code that’s consuming excessive memory
- Fix the underlying issue if it’s a bug
- Move legitimate memory-intensive operations to workers
- Only increase the limit if absolutely necessary, and keep it well below your container’s total memory
memory_limit should be set based on what a typical request reasonably needs - not the theoretical maximum your container can provide. A good rule of thumb: keep it under half your container’s total memory to leave room for multiple concurrent requests.
And whatever you do, don’t set your memory limit to 60GB.