# Allowed memory size exhausted

> A PHP script asked for more memory than your account allows, so it was killed part-way through.

Source: https://cwp.sg/errors/allowed-memory-size-exhausted/  
Author: Ben Johnson  
Last verified: 2026-08-04

**Also seen as:** Fatal error: Allowed memory size of N bytes exhausted, PHP out of memory, memory_limit exceeded

## What it means

PHP gives each request a memory ceiling. When a script asks for more, PHP stops it immediately with a fatal error rather than letting it consume the whole server.

The message names the exact number and the exact line:

```
Fatal error: Allowed memory size of 268435456 bytes exhausted
(tried to allocate 20480 bytes) in /home/u1234/htdocs/wp-includes/functions.php on line 812
```

**That line number is rarely the culprit.** It's simply where the last small allocation happened to fall. Something earlier consumed the memory; this line was just unlucky. Look at what the request was doing, not at the line named.

If PHP is configured to hide errors you get a blank page instead — the [white screen of death](/errors/white-screen-of-death/) is very often this error with display turned off.

## Why it happens

### Loading a whole result set into an array

`SELECT * FROM orders` into an array works fine over 500 rows and dies over 500,000. The query didn't change; the table grew.

This is the most common cause on any site that has been running for a while.

### Image processing

A 4000×3000 JPEG is a couple of megabytes on disk and roughly **48 MB in memory** once decoded — width × height × 4 bytes per pixel. Resize two at once and you're near a 256 MB ceiling before your code does anything else.

Phone photos are routinely this big, so a user upload form hits it long before your test images do.

### A plugin doing too much at once

Backup, migration and image-optimisation plugins load large amounts of data in one pass. They usually work on a small site and fail as it grows.

### An accidental infinite loop or recursion

A loop that appends to an array without terminating will exhaust memory quickly. If the error appeared right after a code change, look there first.

## How to fix it

### 1. Find what actually used the memory

Log usage at a few points rather than guessing:

```php
error_log('before import: ' . round(memory_get_usage(true) / 1048576) . ' MB');
// ... the suspect code ...
error_log('after import: '  . round(memory_get_usage(true) / 1048576) . ' MB');
error_log('peak: '          . round(memory_get_peak_usage(true) / 1048576) . ' MB');
```

`memory_get_peak_usage()` is the number that matters — it's what PHP compares against the limit.

### 2. Process rows in batches instead of all at once

The fix for most memory errors is to stop holding everything in memory:

```php
// Dies on a large table
$rows = $db->fetchAll('SELECT * FROM orders');
foreach ($rows as $row) { process($row); }

// Constant memory, any table size
$stmt = $pdo->prepare('SELECT * FROM orders');
$stmt->execute();
while ($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
    process($row);
}
```

Fetching one row at a time keeps usage flat no matter how many rows there are.

### 3. Free large variables as you go

PHP releases memory when nothing references a value any more, but a long-running loop can hold references longer than you expect:

```php
foreach ($files as $file) {
    $image = imagecreatefromjpeg($file);
    // ... work ...
    imagedestroy($image);   // GD memory is not freed by unset() alone
    unset($image);
}
```

For images specifically, `imagedestroy()` matters — the underlying buffer isn't PHP-managed.

### 4. Raise the limit, if you genuinely need it

This is a last resort, not a first move. If the code needs 300 MB because it's badly written, raising the limit just moves the failure.

Where it's legitimate — a one-off import, a large legitimate dataset — try `php.ini` in your web root:

```ini
memory_limit = 256M
```

Or for WordPress, in `wp-config.php` above the "stop editing" line:

```php
define('WP_MEMORY_LIMIT', '256M');
```

On shared hosting the account ceiling is enforced above PHP, so you cannot raise it past what your plan allows — the setting will silently cap.

### 5. Shrink images before processing them

If you accept uploads, resize on the way in rather than holding full-resolution files in memory later. Cap the accepted dimensions, and reject anything absurd at the door rather than trying to process it.

## On CWP hosting specifically

Free CWP accounts have a 256 MB memory ceiling per account, enforced above PHP — so raising `memory_limit` beyond it has no effect.

The exact fatal error, with the script and line, appears in your control panel's **Error Log**. If you're seeing a blank page instead of a message, the error is still in the log.

## When this means you have outgrown free hosting

If your work genuinely needs more than 256 MB per request — large dataset processing, video, high-resolution image pipelines — that's beyond what shared hosting allocates, and batching won't always help.

Before upgrading, check it really is a legitimate need. In our experience most memory errors are a `fetchAll()` that should be a `fetch()` loop, and that fix costs nothing.

---

Content Website Platform (cwp.sg) operates the free hosting it writes about; see https://cwp.sg/about/ for the methodology and the commercial disclosure.