Fatal error allowed memory size of 1073741824 bytes exhausted

Как ясно из названия файла, default-constants.php отвечает за элементарные параметры веб-ресурса, что называется, «по умолчанию«. Разумеется, что это касается и значения величины WP_MEMORY_LIMIT.

Открываем следующий файл на хостинге:

или файл на Денвере:

Находим условия выделения памяти по ключевому сочетанию WP_MEMORY_LIMIT. В файле этот параметр встречается несколько раз в связи с изменением его величины в зависимости от различных условий. Нас интересует последнее жёстко присвоенное параметру значение в цепочке кода. Вот как это примерно должно выглядеть:

Увеличение memory_limit в прочих конфигурационных файлах

Теперь разберём варианты устранения ошибки Allowed memory size exhausted через редактирование двух других файлов, которые используются не только при настройке CMS WordPress.

memory_limit в php.ini

Файл php.ini позволяет настраивать большое количество переменных, значение объёма выделенной памяти входит в их число. Для начала необходимо выяснить, где именно находится php.ini на нашем сервере, это зависит от операционной системы (разумеется, речь идёт об ОС сервера).

Любым текстовым редактором создаём php-файл со следующим содержим:

Сохраняем файл с произвольным именем, например, phpinfo.php. Готовый файл можно скачать в прикреплённом к статье архиве: phpinfo.
Теперь извлекаем из архива файл и помещаем его в корневую директорию сайта, то есть в каталог /public_html/ или /www/
Далее в адресной строке набираем адрес нашего сайта и через слеш имя файла phpinfo.php, например:

Переходим по адресу и получаем в ответ примерно такую страницу:

В первую очередь смотрим на значение строчки Loaded Configuration File , если путь до php.ini там не прописан, то обращаем внимание на параметр Configuration File (php.ini) Path . Путь может быть указан разный. Вот только несколько возможных примеров:

• /public_html/wp-admin/php.ini
• /etc/php/php.ini
• WebServersusrlocalphp5php.ini

Теперь приступаем к увеличению выделенной памяти:

1. Переходим в каталог, где хранится файл php.ini и открываем сам файл для редактирования. Если такого файла в каталоге нет, создаём его любым текстовым редактором.
2. Добавляем в файл следующий код (всё, что указано после символа точки с запятой, является комментарием и не обязательно к добавлению):

Готовый файл можно скачать из прикреплённого к статье архива: php

memory_limit в .htacess

Заключительный в рамках данной статьи способ увеличения выделяемой памяти для выполнения скрипта — использование файла .htacess.
В упомянутой выше статье о настройке работы Денвер в локальной сети мы уже касались данного файла, поэтому здесь не будем уделять ему лишнего внимания. Отметим только то, что нас интересует для текущих действий, а именно то, что файл .htacess хранится в корневой директории сайта . Приступим к его редактированию:

1. Переходим в корневую директорию сайта и открываем файл .htacess любым удобным текстовым редактором.
2. Добавляем в файл самой верхней строчкой следующий код:
3. Сохраняем изменения в файле и проверяем работу сайта.

На этом всё. Мы рассмотрели 4 способа исправления ошибки Fatal error: Allowed memory size of * bytes exhausted.

Источник

Ошибка — Fatal error: Allowed memory size

Ошибка Fatal error: Allowed memory size гласит о том, что вы достигли ограничения по памяти, которые у вас установлены в настройках web-сервера.

Например, текст ошибки:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 71 bytes) in . говорит, что 128 Мб не достаточно (число выше указано в байтах) и его нужно увеличить, либо в указанном месте решить проблему с утечкой памяти.

Решение проблемы с ограничением памяти

Есть два варианта как завершить операцию:

Увеличить лимит по памяти.

Первый вариант сложен и не всегда возможен. Поэтому рассматривать его не будем.

Хотя, зачастую бывает так, что сайт, например, пытается сжать очень большую картинку в другой размер (например, фото в оригинале весит 20 Мб). В этом случае просто используйте оригинальные картинки меньшего размера.

Второй вариант проще и подойдет как временное решение, до тех пор пока не найдется основной корень зла. Существует несколько способов увеличить лимит.

Файл php.ini

Это рекомендуемый способ, если вы имеете доступ к файлу php.ini. Данный способ не сработает на многих платных хостингах провайдер, т.к. там закрывают доступ к этому файлу, в целях безопасности. Внимание! Данный способ затронет все ваши сайты и скрипты, находящиеся на сервере.

Откройте файл php.ini и найдите там строку memory_limit:

Через .htaccess в корне сайта

Добавьте в самом начале строку php_value memory_limit 256M. Во время выполнения PHP, запишите перед тяжелыми операциями в php-файл следующую строчку

Как посмотреть, сработало ли?

Откройте в панели управления Joomla информацию о системе

И найдите строку memory_limit

Тоже самое можно сделать через команду .

Если не получилось.

В случае, если рекомендации из статьи не помогли вам (возможно хостинг не дает таких прав), то обратитесь с этим вопросом к техподдержке вашего хостинга. Если хостер отказал, то рассмотрите вариант с выполнением тяжелых операций на локальной машине. Затем результат работы перенесите на ваш продуктивный сайт в интернете.

Альтернатива

Также оптимизации по памяти можно добиться установкой APC. Он уменьшает потребление памяти в

1,5-2 раза и ускоряет работу всего сайта в целом. Для нормальной работы Joomla + JBZoo обычно хватает 64 Мб (с серьезным запасом на будущее).

Источник

Fixing PHP Fatal Error: Allowed Memory Size Exhausted

Table of Contents

1 Introduction: why does Fatal Error happen?

Out-of-memory errors are one of the most common and hard-to-fix problems that PHP developers run into — especially with applications that process large amounts of data — thanks to PHP’s relatively conservative default memory settings. In fact, there are more than 1,300 questions related to PHP memory errors on Stack Overflow alone.

98% of the time this error comes from loading more into memory than what you set up PHP to handle in one process. There are other causes, but these are much less common — very rarely it can be a memory leak if you’re on PHP 5.3 and above.

If you aren’t sure what your PHP memory limit is set to, it’s helpfully included in the error message. The size is reported in bytes, though, so we’ve done some conversions for you:

• PHP: Fatal Error: Allowed Memory Size of 8388608 Bytes Exhausted — 8 MB
• PHP: Fatal Error: Allowed Memory Size of 16777216 Bytes Exhausted — 16 MB
• PHP: Fatal Error: Allowed Memory Size of 33554432 Bytes Exhausted — 32 MB
• PHP: Fatal Error: Allowed Memory Size of 67108864 Bytes Exhausted — 64 MB
• PHP: Fatal Error: Allowed Memory Size of 134217728 Bytes Exhausted — 128 MB
• PHP: Fatal Error: Allowed Memory Size of 268435456 Bytes Exhausted — 256 MB
• PHP: Fatal Error: Allowed Memory Size of 536870912 Bytes Exhausted — 512 MB
• PHP: Fatal Error: Allowed Memory Size of 1073741824 Bytes Exhausted — 1 GB

2 What do I have to do to resolve it?

Your first course of action is to increase your memory limit. Note, this is a temporary debugging producedure. The goal is to increase the memory to a point where we have the application working again for the purpose of then reducing the memory usage. Once you decrease the memory usage you can lower the memory limit it to a value that’s more suitable. Your plan should be to use as little memory as you could practically use where the application works and functions correctly in a production server based on the workload by your users (humans or programmatic). I usually recommend setting the memory limit to something high, like 1GB, assuming you have at least 150% of that free in RAM.

Also, never do these tests on a production server unless you’re sure you have plenty of RAM and you fully understand how web server processes consume memory. You could easily bring a server to its knees if there are many concurrent processes running, each using a high amount of memory. I would never, ever recommend setting the memory limit to -1 (unlimited) in a production environment. That’s a recipe for disaster. Don’t make that newbie mistake.

So how do you do this? Simple — increase the memory limit programmatically early on in your code, before your process runs out of memory. If you do it this way, you can give PHP extra memory only when that piece of code gets called rather than increasing the memory limit for all PHP processes.

• If by increasing the memory limit you have gotten rid of the error and your code now works, you’ll need to take measures to decrease that memory usage. Here are a few things you could do to decrease it:
• If you’re reading files, read them line-by-line instead of reading in the complete file into memory. Look at fgets and SplFileObject::fgets .
• Upgrade to a new version of PHP if you’re using PHP 5.3. PHP 5.4 and 5.5 use much less memory.
• Avoid loading large datasets into in an array. Instead, go for processing smaller subsets of the larger dataset and, if necessary, persist your data into a database to relieve memory use.
• Try the latest version or minor version of a third-party library (1.9.3 vs. your 1.8.2, for instance) and use whichever is more stable. Sometimes newer versions of libraries are written more efficiently.
• If you have an uncommon or unstable PHP extension, try upgrading it. It might have a memory leak.
• If you’re dealing with large files and you simply can’t read it line-by-line, try breaking the file into many smaller files and process those individually.
• Disable PHP extensions that you don’t need.
• In the problem area, unset variables which contain large amounts of data and aren’t required later in the code.

2.1 Did everything, set it to unlimited and still get the error

Call the ER, because you’re probably going to end up there. No, seriously, here are a couple of things you could do.

First, you need to ask yourself when this started happening. Was it working before, and now it’s not? If so, think about what could have changed. Isolate the problem.

Maybe you didn’t touch your code before the problem appeared. Well, what else could have changed? Are there external dependencies? Perhaps a database, or files that were imported by a user? Put that on your list of suspects and start investigating.

Start off small; begin with what you «think» the problem is and try to prove yourself wrong. If you can’t, move on to the next suspect. See how far you get into your code before it exits prematurely, then start working up the call stack from there ( var_dump debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS) if you don’t have Xdebug installed). If you can interactively debug with Xdebug or Zend Debugger, do that and put a breakpoint right before the problem area.

I once had an issue where an Excel file kept running out of memory after being imported. It was working fine for months, but suddenly stopped. I think it took me at least 5 hours of relentless debugging before I discovered the problem: random data that had somehow been inserted into one of the worksheet’s cells by the user. Apparently PHP just went haywire, and I still haven’t discovered the root cause, despite knowing the trigger.

I could’ve saved a lot of time by asking myself what changed. The answer was very obvious — data input by the user and the database. You could have a similar experience.

3 Xdebug, the Swiss Army Knife

In any situation, there’s one tool you can count on to help diagnose how much memory you’re using and where in your code large amounts of memory are being used: Xdebug. You can install it using package managers like yum , apt-get , port , and homebrew ; install a pre-built binary; use pecl ; or simply compile it yourself.

After installing Xdebug, all you need to do is refresh the page or, if your code is meant to run in a shell, re-run it in the CLI. PHP will now throw much more informative errors, including a call stack that will tell you exactly where the script stopped with a file path, line number, and even the last function that was called.

If you want more detailed information you’ll need to generate what’s called a «trace file.» To do this, set the xdebug.auto_trace and xdebug.show_mem_delta config directives to 1 . Trace files are normally saved in /tmp or /var/tmp , but you can check the output path by looking at the xdebug.trace_output_dir directive in phpinfo() .

Just run the code, and a trace file — including memory usage — will be created even if you run out of memory early.

To locate the problem, begin at the bottom of the trace file and work your way up. Look for deltas (numbers with + or –) with a large number, and keep in mind that they’re shown in bytes. 1024 bytes = 1 kilobyte.

Once you’re finished debugging, make sure to set xdebug.auto_trace back to 0 . Trace files can become very large, very quickly, and eat up disk space.

4 PHP Memory management

Here’s a great slide deck on how PHP deals with memory internally.

5 Challenge

Use the following script and try to pinpoint where the problem is. Even better, install Xdebug and generate a trace file.

With all of these tips in mind you should be able to fix any memory exhaustion error. If you’re still having issues, I’d be glad to jump on an AirPair session and help get to the root of the problem so you can focus on what’s important.

Источник