Fatal error allowed memory size of 536870912 bytes exhausted tried to allocate 20480 bytes - Исправление ошибок и поиск оптимальных решений проблем

Пользователь 3214649

Заглянувший

Сообщений: 8
Авторитет:

0
Рейтинг пользователя:

0
Регистрация: 13.06.2019

Здравствуйте,
при обратной загрузке большого заказа с 1с в битрикс выпадает ошибка Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 20480 bytes) in /var/www/…/bitrix/modules/main/lib/orm/fields/field.php on line 643
Добавил оперативки до 6Гб, limit memory 3072, execute time 900 поставил. Ошибка при загрузке большого заказов (~400 позиций) с 1С в битрикс сохранилась Fatal error: Allowed memory size of 536870912 bytes exhausted
Подскажите куда копнуть?

Пользователь 176202 Постоянный посетитель Сообщений: 180 Баллов: 30 Авторитет: 1 Рейтинг пользователя: 0 Регистрация: 28.03.2013	php_info покажите? именно memory_limit… судя по ошибке у вас меньше 512мБ

Пользователь 3214649

Заглянувший

Сообщений: 8
Авторитет:

0
Рейтинг пользователя:

0
Регистрация: 13.06.2019

16.01.2020 05:32:33

Цитата
Андрей Ковач написал: php_info покажите? именно memory_limit… судя по ошибке у вас меньше 512мБ

Сейчас 3072 мегабайт

http://prntscr.com/qobo9d

Пользователь 3214649 Заглянувший Сообщений: 8 Авторитет: 0 Рейтинг пользователя: 0 Регистрация: 13.06.2019	#4 0 16.01.2020 06:43:57 Проблема решилась. Оказывается если смотреть настройки phpinfo() через Админку сайта Инструменты-Диагностика-Настройки PHP и так сайт.ru/i.php Они получается разные. А поскольку сайт работает в режиме многосайтовости, то точные настройки phpinfo будут на сайт.ru/i.php для каждого сайта. И в этом случае сыграло значение value для memory limit, которое нужно прописать в /bitrix/php_interface/dbconn.php ini_set(«memory_limit», «3072M»);

Источник

A common error with Open Source Software like WordPress, Moodle, and Joomla is the php “Allowed memory size error.” Increasing the memory limit is an easy solution. This memory_limit can be changed in the php.ini in the public_html folder in your hosting account. This error can creep up in your website during the normal development process. The following is an example of the error:

Fatal error: Allowed memory size of 268435465 bytes exhausted (tried to allocate 280559520) in Unknown on line 0

This is due to php variable data being stored in the memory that is not cleared while the php scripts are running.

For those who code their own sites: Coders use the unset() function to clear variable data that is no longer needed; however, with open source software, you will not want to alter any code.

How to fix the “Allowed memory size Error”

The php memory resource can be increased in the php.ini located in the public_html. The following steps will explain how to set the php.ini to allow a larger amount of memory use.

Login to your cPanel
Go to the File Manager.
Select the Web root (public_html/www) directory and click Go.
Find the php.ini file in the public_html.
Note! If you do not have a php.ini in your public_html files, you can have our tech support staff restore the php.ini to your public_html directory.

Open the php.ini with the code editor.
Find the following section in the php.ini file.
max_execution_time = 30 max_input_time = 60 memory_limit = 128M
Try increase the memory_limit value to 256M.
If the php memory_limit is already at 256M, you can increase it to 512M.

Save the changes.
In order for your memory limit to take effect you will need to make the php.ini recursive.
Important! Making the php.ini recursive is an important step. If you do not know how to do this, please see our article on Make the php.ini recursive in the .htaccess.

Now visit the site. You should not see the “Allowed memory size” error anymore. If the error still shows on your website, there may be a setting within the software itself that is overriding the change or the php.ini in the public-html may be overriden by another setting elsewhere. If this is the case, you can contact our our tech support staff to have them look into the error further.

Источник

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

Closed

onny opened this issue

Feb 22, 2021

· 102 comments

· Fixed by #25770

Comments

How to use GitHub

Please use the 👍 reaction to show that you are affected by the same issue.
Please don’t comment if you have no relevant information to add. It’s just extra noise for everyone subscribed to this issue.
Subscribe to receive notifications on status change and new comments.

Steps to reproduce

Upgrading to Nextcloud 21
Run php ./occ in Nextcloud root directory
./occ crashes

Expected behaviour

Occ should work normally, for example printing available commands

Actual behaviour

Occ crashes with the following error:

$ sudo -u http ./occ update
PHP Warning: Module “gd” is already loaded in Unknown on line 0
PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 20480 bytes) in /usr/share/webapps/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php on line 133

To be more precise, this also happens running php cli against other files of Nextcloud, for example index.php or console.php.
Surprisingly Nextcloud is running fine through php-fpm and web server. It was even able to perform the upgrade to v21 just fine.

Another user commented on the ArchLinux bug tracker:

If it could help, I added a trace in /usr/share/webapps/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php on line 133, and I get in an infinite loop the following messages:

Could not resolve OCUserManager!
Could not resolve OCSecurityCSRFCsrfTokenManager!

As if it was unable to locate its lib/private/ folder.
If I set memory_limit to -1, it fill completely memory and hit OOMkiller.
(tried with both php7 and php8, with nextcloud-21.0.0-7)

Possibly not only related to ArchLinux setups. An other user reported the exact issue here, which was triggered on a Ubuntu installation.

Server configuration

Operating system: Archlinux x64

Web server: Caddy 2

Database: Mysql

PHP version: 8.0.2

Nextcloud version: (see Nextcloud admin page) 21.0.0

Updated from an older Nextcloud/ownCloud or fresh install: Yes

Where did you install Nextcloud from: Package repository

Signing status:

Signing status

List of activated apps:

App list

accessibility/         drawio/                files_trashbin/           nextcloud_announcements/  settings/               twofactor_gateway/
activity/              encryption/            files_versions/           notes/                    sharebymail/            updatenotification/
admin_audit/           extract/               files_videoplayer/        notifications/            spreed/                 user_ldap/
apporder/              federatedfilesharing/  firstrunwizard/           oauth2/                   support/                user_status/
calendar/              federation/            integration_discourse/    password_policy/          survey_client/          viewer/
cloud_federation_api/  files/                 integration_github/       photos/                   suspicious_login/       weather_status/
comments/              files_ebookreader/     integration_reddit/       polls/                    systemtags/             workflowengine/
contacts/              files_external/        integration_twitter/      privacy/                  tasks/
contactsinteraction/   files_pdfviewer/       keeweb/                   provisioning_api/         text/
dashboard/             files_rightclick/      logreader/                recommendations/          theming/
dav/                   files_sharing/         lookup_server_connector/  serverinfo/               twofactor_backupcodes/

Nextcloud configuration:

Config report

<?php
$CONFIG = array (
  'instanceid' => '****',
  'datadirectory' => '/var/lib/nextcloud/data',
  'dbtype' => 'mysql',
  'version' => '21.0.0.18',
  'dbname' => 'nextcloud',
  'dbhost' => 'mysql.pi',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nextcloud',
  'dbpassword' => '****',
  'installed' => true,
  'maintenance' => false,
  'loglevel' => 0,
  'cron_log' => true,
  'maxZipInputSize' => 5145728000,
  'allowZipDownload' => true,
  'memcache.local' => '\OC\Memcache\APCu',
  'allow_local_remote_servers' => true,
  'trusted_domains' => 
  array (
    0 => 'nextcloud.****.org',
  ),
  'passwordsalt' => '***',
  'secret' => '****',
  'mail_domain' => '******.org',
  'mail_smtpmode' => 'php',
  'mail_from_address' => 'nextcloud',
  'trashbin_retention_obligation' => 'auto',
  'updatechecker' => false,
  'app.mail.verify-tls-peer' => false,
  'overwrite.cli.url' => 'https://nextcloud.***.org',
  'default_phone_region' => 'DE',
);

Are you using external storage, if yes which one: None, had configured SFTP mount point

Are you using encryption: No

Are you using an external user-backend, if yes which one: No

Client configuration

Browser: Latest Firefox

Operating system: NixOS

Nextcloud log (data/nextcloud.log)

Nothing exceptional here, also no error logs
Nextcloud log

[...]
{"reqId":"pti6pSFymOb7PvbzzzmM","level":0,"time":"2021-02-21T18:08:04+00:00","remoteAddr":"2****","user":"--","app":"files_sharing","method":"GET","url":"/cron.php","message":"/appinfo/app.php is deprecated, use \OCP\AppFramework\Bootstrap\IBootstrap on the application class instead.","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0","version":"21.0.0.18"}
{"reqId":"pti6pSFymOb7PvbzzzmM","level":0,"time":"2021-02-21T18:08:04+00:00","remoteAddr":"*****","user":"--","app":"keeweb","method":"GET","url":"/cron.php","message":"/appinfo/app.php is deprecated, use \OCP\AppFramework\Bootstrap\IBootstrap on the application class instead.","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0","version":"21.0.0.18"}
{"reqId":"pti6pSFymOb7PvbzzzmM","level":0,"time":"2021-02-21T18:08:04+00:00","remoteAddr":"*****","user":"--","app":"onlyoffice","method":"GET","url":"/cron.php","message":"/appinfo/app.php is deprecated, use \OCP\AppFramework\Bootstrap\IBootstrap on the application class instead.","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0","version":"21.0.0.18"}

Scrumplex, ngreve, mogwa1, tgurr, yapbreak, onny, jfreax, donvipre, kvnp, tbasilici, and 114 more reacted with thumbs up emoji
sokai reacted with eyes emoji

I am also affected by this. I run Arch Linux. I even tried a fresh install (but old data directory). The web interface works as expected.

I also run Arch Linux, and in the web interface, of O go to the page admin/overview, it says, among other things
Last background job execution ran 9 days ago. Something seems wrong. Check the background job settings
And if go to settings/admin#backgroundjobs I see that the choice «cron» is checked, and if try to check webcron or ajax, and leave the page to come back, cron is still checked. So even the webinterface doesn’t work correctly.

debian 10 here, same issue: tried with php 7.0 7.3 and 8.0 no joy, this is a nextcloud issue not an operative system one…

I upgraded from 21.0.0 RC2 to 21.0.0 and the issue presented itself on the upgrade at the end of the update process (that is the first time occ is run AFTER the files changed from rc2 to stable), this suggests me the problem might be somewhere in the changelog between the rc2 and the production ?

As a matter of fact, there are whole bunch of things that don’t work with web interface. I can’t update, enable, disable, remove or download applications.

As it might be relevant, here is some info about the php cli configuration:

php -i

I can reproduce this bug with Nextcloud stable21 and php v7.4 on Arch Linux.

Another finding: The occ command works fine if the instance is not yet installed. After installing (e.g. using web installer or occ install command) it becomes unusable.

Currently I suspect the upgrade process somehow corrupted the Mysql database?
I get following erros from the mysql/mariadb daemon:

InnoDB: Page […] log sequence number […] is in the future!

Feb 22 17:42:03 mysql mariadbd[327]: 2021-02-22 17:42:03 254850 [ERROR] InnoDB: Page [page id: space=2026, page number=45620] log sequence number 352586303314 is in the future! Current system log sequence number 320954826491.
Feb 22 17:42:03 mysql mariadbd[327]: 2021-02-22 17:42:03 254850 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.

If I stop the database, occ runs until connection timeout to Mysql server. So my guess is Occ crashes after connecting to the database …

Okay maybe it is something different. Nevertheless I put this at line 133 in lib/private/AppFramework/Utility/SimpleContainer.php:

echo "<pre>".print_r(debug_backtrace(),true)."</pre>";

Which is giving me this stack trace showing some kind of iteration with arrays including the PHP environment and configuration array?! https://onny.project-insanity.org/files/stacktrace_short.txt

Information which might be useful in this case:

Config file is located in /etc/webapps/nextcloud/config/config.php. /usr/share/webapps/nextcloud/config is a symlink to the config folder located in /etc/webapps-folder
After upgrading via web frontend I had to change the data directory according to the new packaging guidlines in Archlinux. It is now stored in /var/lib/nextcloud/data

This is what I get from logging mysql queries:

210222 21:05:09      6 Connect  nextcloud@http.pi on nextcloud using TCP/IP
                     6 Query    SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED
                     6 Query    SET SESSION AUTOCOMMIT=1
                     6 Query    SELECT * FROM `oc_appconfig`

Nothing more …

Edit: oc_appconfig has a lot of keys so I don’t know where to look at. In case some value in there is causing the issue …

I hit OOM when upgrading to latest nextcloud by running occ upgrade.
Is there any workaround or fix?

I upgraded from 21.0.0 RC2 to 21.0.0 and the issue presented itself on the upgrade at the end of the update process (that is the first time occ is run AFTER the files changed from rc2 to stable), this suggests me the problem might be somewhere in the changelog between the rc2 and the production ?

I second this. I have been testing using the stable21 branch last week and it worked fine until a couple days ago. The regression was introduced recently.

Maybe bisecting from 21RC2 to the current version is a good starting point.

Same issue here. Arch Linux ARM, but with Postgres backend, so it might not be related to mysql at all.

occ attempts to allocate a lot more memory on startup than usual on 21.0.0, I tried increasing memory_limit in php.ini but that just causes it to get oomkilled at some point.

Disabling all extensions except for pgsql and pdo_pgsql (without these two occ just crashes) still results in the same behaviour.

php -i

Even with memory_limit set to -1 (so no limit at all), occ will fail and trigger OOMKiller on my server with 32GiB RAM and 32GiB Swap…

Same problem on FreeBSD 12.2, php 7.3.

Upgrades to NC 21 RC 1 and NC 21 RC 2 went through without problems. Now it’s just the main release NC 21.0.0:

PHP Fatal error:  Allowed memory size of 8489271296 bytes exhausted (tried to allocate 20480 bytes) in /usr/local/www/nextcloud-test/lib/private/AppFramework/Utility/SimpleContainer.php on line 133

Fatal error: Allowed memory size of 8489271296 bytes exhausted (tried to allocate 20480 bytes) in /usr/local/www/nextcloud-test/lib/private/AppFramework/Utility/SimpleContainer.php on line 133

and a few more reports on the forum:
https://help.nextcloud.com/t/occ-command-php-fatal-error-allowed-memory-size-of-xxx-bytes-exhausted/108521

Also having this problem on FreeBSD 12.2, with php 7.4.

Downgrading (using FreeBSD binary packages built myself) restores functionality, the DB looks unmodified by the botched update.

I had exactly the same issue after I upgraded from NC 20.0.7 to 21.0.0 release. The cron.php also did not run.

CentOS 7 — postgreSQL 13 — php 7.4 or 8.0 (did not matter)

I «solved» the problem by downgrading to NC 21.0.0 RC2

@onny Try to enable apc.enable_cli=1 in /etc/php/8.0/cli/conf.d/20-apcu.ini. After I added that line to the file occ worked and the memory didn’t get filled anymore.
Also see the warning here in the manual.

RipClaw2971, kvnp, n1bs, onny, Schueni1, tim427, s644, st3iny, tbasilici, hansenpansen, and 35 more reacted with thumbs up emoji
Mister-Muffin, BornToBeRoot, matthiasbe, pogobanane, jpylypiw, Razican, EX0l0N, josegreyes, ryhaberecht, and ahiiti reacted with heart emoji

@andreaslutsch your solution worked for me (21.0.0, ArchLinux). For reference for others, you can enable the option by adding the parameter --define apc.enable_cli=1 to your php cli call (e.g. php --define apc.enable_cli=1 occ [...]).

andreaslutsch, kvnp, tim427, Grotax, hansenpansen, st3iny, pholthaus, Pafzedog, beardhatcode, Mister-Muffin, and 10 more reacted with thumbs up emoji
pierre-alain-b reacted with hooray emoji
Mister-Muffin reacted with heart emoji

@onny Do you think, this issue is fixed? For me it is a regression and thus a bug when software changes it behavior and is crashing, when there is something missing in the environment. At least this should be documented, if apc is a hard requirement (and checked by the application when starting and throwing an error message). Enabling apc is in this case just a «workaround».
So can you please reopen the issue so it can be fixed?

@waja it looks like a regression for me because it worked without this option before and it’s only recommended for the cronjob.

Similar issue here on Ubuntu server 20.10, php 7.4, MariaDB 10.3, whatever amount of memory I allocate to my Nextcloud instance gets exhausted.
I tried the apc_enable_cli workaround but it didn’t change anything it still ends up being OOM-killed
the command I’m being asked to run is php occ db:add-missing-indices.
Also, no Cron jobs can complete, they also run out of memory.

Thanks for your help

I tried the apc_enable_cli workaround but it didn’t change anything it still ends up being OOM-killed

Just in case: it is apc.enable_cli with a dot. It’s working for me with the changed config file. Maybe also check, if you are using the correct php version and try running it with explicit version command e.g. php7.4 -f /var/www/nc/cron.php.

Edit: added version info

OMV 5.6.0-1/Debian GNU/Linux 10 (buster)
PHP 8.0.2 (cli)

I ran git bisect and the commit a745d58 seems to be introducing this regression.

I tried the apc_enable_cli workaround but it didn’t change anything it still ends up being OOM-killed

Just in case: it is apc.enable_cli with a dot. It’s working for me with the changed config file. Maybe also check, if you are using the correct php version and try running it with explicit version command e.g. php7.4 -f /var/www/nc/cron.php.

Thanks for your reply.
sorry I did use apc.enable_cli, I typed it above rather than copy/paste.
I also tried both php and php7.4

EDIT: my mistake it worked with apc.enable_cli=1

Was there any comments from maintainers about fixing this or apcu is mandatory now?

I can’t enable accessibility no more, though. Not sure what that app does anyway, so it’s fine if nobody notices.

It’s the start of special needs tweaks for the system, like a dyslexia-friendly font.

Was there any comments from maintainers about fixing this or apcu is mandatory now?

Set your log_level to 2 in you config. That’s all in need to do.

In my case, the system started allowing so much memory that it would make the machine inaccessible. I’m going to lower the maximum amount of memory allowed to PHP… I almost lost a drive with the 3 reboots I had to do because of this, a filesystem got corrupt.
I’m very worried about upcoming updates.

allowing PHP to use more memory than you have or filesystem corruption are both not issues related to nextcloud, these are issues for themselves.

That may be so, but a bug that is so dramatic that it has the potential to tear down not quite cleanly set up servers is still a huge problem in my eyes. On servers that are not only running nextcloud, this can have far-reaching consequences for other services. This will happen to many and in my opinion is so critical that it should block the further rollout of Nextcloud 21 until the problem is fixed.

TheRaven500, gentakojima, sgebauer, flortsch, mrschaal, wangxu94, NotAFile, hubertbanas, zersenser, hul51u, and 5 more reacted with thumbs up emoji

The changeset which has caused this issue is known. Someone made a critical modification after the testing of the last release candidate 2 for Nextcloud 21 was finished short before Nextcloud 21.0.0 was released. This is not a good strategy. If you install Nextcloud 21RC2 then you don’t have this bug.

The changeset which has caused this issue is known. Someone made a critical modification after the testing of the last release candidate 2 for Nextcloud 21 was finished short before Nextcloud 21.0.0 was released. This is not a good strategy. If you install Nextcloud 21RC2 then you don’t have this bug.

This is not true, i reported this bug during the beta phase and again after RC1 was released.
Here: #26154

TheRaven500:
You are confusing things!

You are talking about NC21.0.1 RC1
I was talking about NC21.0.0 RC2 (the version BEFORE NC21.0.1 that you refer to)

NC21.0.0 RC 2 does NOT have this bug. NC21.0.0 Release introduced it.

Your report (26154) you are linking to was created on 16. March 2021 and is a duplicate of this one which was added on 22. Februar 2021.

The bug was introduced short BEFORE NC21.0.0 was released and AFTER NC21.0.0 RC2 was out for testing.
All this (including the changeset which introduced the problem) was written here some lines above.

I am still using Nextcloud 21.0.0 RC2 and I don’t have this bug.

Just updated to NC 21.0.1. Managed to consume 24 GB RAM and then 24 GB of SWAP. Caught it just in time to stop the server crashing. PHP is limited to 18 GB on my system, APCu is already enabled, log level is already at 2.

Considering the comments reporting this issue, and just how crippling it is, I don’t understand why it’s still available for people to run the update.

@RealSnoopyDog:
You may be right, but it doesn’t really matter who is right. It is a serious bug and should be fixed as soon as possible!

Yes. But not «may». Talking about software and bugs is not guessing, it is based on facts. And everything was written here already (not by me, I only repeated what was found by others).

Ubuntu 20.04.2 LTS here. I had the crash as well,
changing from ‘loglevel’ => 0, to ‘loglevel’ => 2, worked for me.
Just FYI
GLLM

I’m getting a notification that 21.0.2 is available for upgrade.

Can I assume that as this bug is still open, it’s likely to try and cripple my server all over again?

I’m getting a notification that 21.0.2 is available for upgrade.

Can I assume that as this bug is still open, it’s likely to try and cripple my server all over again?

In my particular case it eats all memory and forces me to kill the php process. I did disable the accessibility app and set loglevel to 2, but when i start the update process again, it resets loglevel back to 0 and screws up again.

I’m getting a notification that 21.0.2 is available for upgrade.
Can I assume that as this bug is still open, it’s likely to try and cripple my server all over again?

In my particular case it eats all memory and forces me to kill the php process. I did disable the accessibility app and set loglevel to 2, but when i start the update process again, it resets loglevel back to 0 and screws up again.

Have you checked your APC/Redis cache setting, libraries and server?

I’m getting a notification that 21.0.2 is available for upgrade.
Can I assume that as this bug is still open, it’s likely to try and cripple my server all over again?

In my particular case it eats all memory and forces me to kill the php process. I did disable the accessibility app and set loglevel to 2, but when i start the update process again, it resets loglevel back to 0 and screws up again.

Have you checked your APC/Redis cache setting, libraries and server?

nextcloud instance itself runs in its own container by itself. Redis and the database are in a different container. The nextcloud container is the one that has the memory leak. Haven’t checked libraries — do you have any specific ones in mind (fyi, i’m not experienced with php)?

Since it’s a personal cloud server that i’ve already backed up, i tried this workaround #25742 (comment) and so far everything seems to be in order.

I’m getting a notification that 21.0.2 is available for upgrade.
Can I assume that as this bug is still open, it’s likely to try and cripple my server all over again?

In my particular case it eats all memory and forces me to kill the php process. I did disable the accessibility app and set loglevel to 2, but when i start the update process again, it resets loglevel back to 0 and screws up again.

Have you checked your APC/Redis cache setting, libraries and server?

nextcloud instance itself runs in its own container by itself. Redis and the database are in a different container. The nextcloud container is the one that has the memory leak. Haven’t checked libraries — do you have any specific ones in mind (fyi, i’m not experienced with php)?

In my case changing the nextcloud loglevel absolutely nothing. I removed the php-redis package/library by mistake, which led to nextcloud being unable to use said caching service. Reinstalling that library fixed it. Removing it broke it again. Switching to memcache by installing the daemon and php libraries and changing the nextcloud config appropriately fixed it, removing the libraries/package broke it again.
So in my case it was all dependent on the nextcloud cache interface.

And sure, it’s nextcloud that blows up, not any other service. So it absolutely makes sense that the nexcloud container is the one that dies, if you are using a containerized setup.

That is why I recommended to check your cache settings and your installed php libraries in your nextcloud container.

Installing php7.4-xml and php8.0-xml fixed it for me.

This is not a fix for the real problem, it is a workaround (like all other hints)

nodiscc

added a commit
to nodiscc/xsrv
that referenced
this issue

May 29, 2021

I haven’t had this problem until NC 22 Beta 3. Now I have the same error. Removing solves APCu resolves the problem but is not in line with the recommendations in the adminstration manual.

nodiscc

added a commit
to nodiscc/xsrv
that referenced
this issue

Jun 4, 2021

nodiscc

added a commit
to nodiscc/xsrv
that referenced
this issue

Jun 4, 2021

Posting this here in case it helps anyone else…

You can check the PHP memory limit using the command line like this:

php -r "phpinfo();" | grep memory_limit
memory_limit => 128M => 128M

With the above defaults I was unable to upgrade Nextcloud:

php updater/updater.phar --no-backup
...
PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 167968632 bytes) in phar:///home/cloud/sites/nextcloud/updater/updater.phar/lib/Updater.php on line 637

However after creating a ~/.php.ini file containing:

And then running the update using this ini file:

php --php-ini ~/.php.ini updater/updater.phar --no-backup

There isn’t a problem with the updater.

As far as I can tell you don’t need to enable the OPCache or APCu for the CLI, the upgrade works for me with these settings:

php -r "phpinfo();" | grep enable_cli
apc.enable_cli => Off => Off
opcache.enable_cli => Off => Off

I’m using PHP CLI param -d memory_limit=4096M
Work for me.
Nextcloud version 21.0.3
I’m docker.

How to
STEP 1

config.php is set 'loglevel' => 2,
run command wait 1 hour and CTRL+C.

STEP 2 run command wow!!

STEP 1

STEP 2

sudo —u www-data php —define memory_limit=512M /var/www/html/occ files:scan —all

Источник

If you are using WordPress to perform tasks which consume a large amount of Memory (RAM) to complete, you may run into errors due to the amount of Memory required for the task. This article will explain what these Memory errors mean, and how to resolve them.

About Allowed Memory Errors

If you are performing tasks that consume a large amount of Memory on your WP Engine server environment, you may encounter an error similar to the following:

Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 98574336 bytes) in /nas/content/live/yourinstall/wp-content/object-cache.php on line 425

In some cases this error will print directly on your page. In others, you may see a blank white screen (sometimes called the “White Screen of Death”), or a browser error:

This page isn’t working
yourdomain.com is currently unable to handle this request.
HTTP ERROR 500

In this case, you may find the fatal error mentioned above in the site error logs located in your User Portal instead.

In either scenario, this error indicates that the current task tried to use an amount of Memory that was higher than the amount allocated to PHP. It is not specific to WordPress sites, but rather to PHP and how much memory PHP is allowed to use.

Fixing Allowed Memory Errors

By default, WordPress defines the memory limit for WordPress PHP processes to 40MB for a standard site and 64MB for a WordPress multisite. Adding two lines to your wp-config.php file defining a new Memory limit will overwrite the default Memory limitations.

To edit your wp-config.php file you will need to connect to SFTP. If you have never connected to this website over SFTP before, be sure to review our SFTP guide for help downloading an SFTP client and adding an SFTP user.

Edit wp-config.php

Open your SFTP client and enter your SFTP credentials to connect to your website. Once you are connected, you will see a listing of the files and folders for your website. Right-click the “wp-config.php” file from the list and select “View/Edit.” This will open the file in a text editor.

In the text editor, scroll down to the “WP Engine Settings” section and add the following two lines:

define('WP_MEMORY_LIMIT', '256M');
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

We recommend setting 256MB for the standard WP_MEMORY_LIMIT, as this is the line that defines how much memory all WordPress operations can use. By adding a WP_MAX_MEMORY_LIMIT line as well, you are setting a separate limit specifically for tasks in the WordPress Admin Dashboard area of your site. We recommend setting this at a max of 512MB because administration-related tasks often require more Memory,

When the lines have been added, save the file in your text editor. Your SFTP client may ask whether or not you would like to apply the changes to your website. Make sure you select “yes” if prompted to confirm the change.

That’s it! Provided the task does not require more than the max memory allowed by WordPress (now 256MB for all requests, and 512MB for wp-admin requests), your issue will be resolved.

NOTE

The wp-config.php file can also be modified using SSH Gateway.

NEXT STEP: Review WP Engine default platform settings

Источник

Hi there!

I have exactly the same issue and I do hope we can figure this out to fix this problem / bug.

Our pfsense «crashed» last week and I could not access the GUI at all. It simply stated:

504 Gateway Time-out
nginx

Not thinking much, I rebooted pfsense (which was a mistake as it turns out). After 10 minutes it was still not back online, so I attached a monitor to the gateway and started debugging this issue.

In the end I figured out that we had the exact same issue as stated here. I have no idea why this worked for so many years.
From one day to the next the config blew up and killed the setup (this was not after a pfsense upgrade or after changing anything in the webgui, I was not even in the office when this happened).

Little more details:
On bootup it took nearly 45 minutes to get back «online» (which means no gui, but shell access). The config was around 60 MB at that time (also the backups were quite big).
On boot pfsense tried to parse the config and the backup which resulte in «Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 20480 bytes) in /etc/inc/xmlparse.inc on line 71».

After checking here, I increased the php cache to 1024 MB and rebooted. This took — again — 45 minutes to complete. It did not show the error again, but it was still horribly slow.

After having a shell again, it turned out that /var/ was mounted as a 3,7 MB FS which ran full and showed «107% usage» (with df -h). I never had any issues with this before.
At this timepoint my config already had 130 MB.

In the end I moved the config backups to a different dir and restored the first backup I had (which only had around ~100 KB). After a reboot pfsense was back up in around 5 minutes and started working perfectly fine again.
Just a note: I did not change anything about the /var/ FS, but after restoring the smaller config /var/ was not full anymore. I increased it afterwards to 100M just in case.

Sadly today I noticed the same behavior again… Can’t use the webgui, on logging in I can see that the config.xml grew again to over 50MB. This somehow stopped php from working correctly (/var/ is not full at the moment)

So please help me understand and fix this issue. I do not want to restore an old config every week

Interesting was the growth in config size:

ls -la
total 453772
drwxr-xr-x  2 root  wheel       1024 Aug  1 10:08 .
drwxr-xr-x  5 root  wheel       1024 Aug  1 12:52 ..
-rw-r--r--  1 root  wheel      85933 Jul 18 13:44 config-1563450244.xml
-rw-r--r--  1 root  wheel     103259 Jul 18 13:45 config-1563450245.xml
-rw-r--r--  1 root  wheel     104373 Jul 18 13:45 config-1563450316.xml
-rw-r--r--  1 root  wheel     139012 Jul 18 13:45 config-1563450318.xml
-rw-r--r--  1 root  wheel     139027 Jul 18 13:45 config-1563450331.xml
-rw-r--r--  1 root  wheel     208304 Jul 18 13:45 config-1563450333.xml
-rw-r--r--  1 root  wheel     207217 Jul 18 13:45 config-1563450349.xml
-rw-r--r--  1 root  wheel     207188 Jul 18 13:45 config-1563450356.xml
-rw-r--r--  1 root  wheel     207189 Jul 18 13:48 config-1563450358.xml
-rw-r--r--  1 root  wheel     207189 Jul 18 13:48 config-1563450492.xml
-rw-r--r--  1 root  wheel     207188 Jul 18 13:48 config-1563450493.xml
-rw-r--r--  1 root  wheel     345741 Jul 18 14:02 config-1563450495.xml
-rw-r--r--  1 root  wheel     345682 Jul 18 14:03 config-1563451324.xml
-rw-r--r--  1 root  wheel     622787 Jul 18 15:02 config-1563451388.xml
-rw-r--r--  1 root  wheel     622786 Jul 18 15:03 config-1563454923.xml
-rw-r--r--  1 root  wheel    1176995 Jul 18 16:02 config-1563454988.xml
-rw-r--r--  1 root  wheel    1176994 Jul 18 16:03 config-1563458524.xml
-rw-r--r--  1 root  wheel    2285411 Jul 18 17:02 config-1563458590.xml
-rw-r--r--  1 root  wheel    2285410 Jul 18 17:03 config-1563462127.xml
-rw-r--r--  1 root  wheel    4502243 Jul 18 18:02 config-1563462195.xml
-rw-r--r--  1 root  wheel    4502242 Jul 18 18:03 config-1563465730.xml
-rw-r--r--  1 root  wheel    8935907 Jul 18 19:02 config-1563465804.xml
-rw-r--r--  1 root  wheel    8935906 Jul 18 19:03 config-1563469336.xml
-rw-r--r--  1 root  wheel   17803235 Jul 18 20:02 config-1563469424.xml
-rw-r--r--  1 root  wheel   17803234 Jul 18 20:04 config-1563472955.xml
-rw-r--r--  1 root  wheel   35537891 Jul 18 21:03 config-1563473074.xml
-rw-r--r--  1 root  wheel   35537890 Jul 31 19:02 config-1564590959.xml
-rw-r--r--  1 root  wheel   35537890 Jul 31 19:04 config-1564592525.xml
-rw-r--r--  1 root  wheel   71007203 Jul 31 20:00 config-1564592678.xml
-rw-r--r--  1 root  wheel   71007202 Jul 31 20:10 config-1564596052.xml
-rw-r--r--  1 root  wheel  141945827 Aug  1 10:08 config.xml

This was the «first time»

And this is the second time:

ls -lah /conf/backup/
total 80632
drwxr-xr-x  2 root  wheel   1.5K Aug  2 00:04 .
drwxr-xr-x  4 root  wheel   512B Aug  4 10:24 ..
-rw-r--r--  1 root  wheel   4.7K Aug  2 00:04 backup.cache
-rw-r--r--  1 root  wheel   135K Aug  1 12:35 config-1564655707.xml
-rw-r--r--  1 root  wheel   202K Aug  1 12:38 config-1564655708.xml
-rw-r--r--  1 root  wheel   203K Aug  1 12:38 config-1564655901.xml
-rw-r--r--  1 root  wheel   203K Aug  1 12:39 config-1564655923.xml
-rw-r--r--  1 root  wheel   203K Aug  1 12:40 config-1564655970.xml
-rw-r--r--  1 root  wheel   202K Aug  1 12:40 config-1564656011.xml
-rw-r--r--  1 root  wheel   202K Aug  1 12:44 config-1564656044.xml
-rw-r--r--  1 root  wheel   202K Aug  1 12:44 config-1564656263.xml
-rw-r--r--  1 root  wheel   202K Aug  1 12:44 config-1564656286.xml
-rw-r--r--  1 root  wheel   202K Aug  1 12:52 config-1564656292.xml
-rw-r--r--  1 root  wheel   202K Aug  1 12:53 config-1564656779.xml
-rw-r--r--  1 root  wheel   202K Aug  1 12:53 config-1564656803.xml
-rw-r--r--  1 root  wheel   201K Aug  1 12:53 config-1564656804.xml
-rw-r--r--  1 root  wheel   330K Aug  1 12:53 config-1564656805.xml
-rw-r--r--  1 root  wheel   328K Aug  1 12:54 config-1564656806.xml
-rw-r--r--  1 root  wheel   328K Aug  1 12:54 config-1564656873.xml
-rw-r--r--  1 root  wheel   329K Aug  1 12:54 config-1564656874.xml
-rw-r--r--  1 root  wheel   602K Aug  1 12:54 config-1564656875.xml
-rw-r--r--  1 root  wheel   603K Aug  1 12:54 config-1564656876.xml
-rw-r--r--  1 root  wheel   605K Aug  1 12:54 config-1564656877.xml
-rw-r--r--  1 root  wheel   1.1M Aug  1 12:54 config-1564656879.xml
-rw-r--r--  1 root  wheel   1.1M Aug  1 12:55 config-1564656897.xml
-rw-r--r--  1 root  wheel   1.1M Aug  1 12:58 config-1564656904.xml
-rw-r--r--  1 root  wheel   1.1M Aug  1 13:00 config-1564657133.xml
-rw-r--r--  1 root  wheel   1.1M Aug  1 13:00 config-1564657233.xml
-rw-r--r--  1 root  wheel   1.1M Aug  1 13:00 config-1564657236.xml
-rw-r--r--  1 root  wheel   2.2M Aug  1 14:00 config-1564657238.xml
-rw-r--r--  1 root  wheel   4.3M Aug  1 15:00 config-1564660814.xml
-rw-r--r--  1 root  wheel   8.5M Aug  1 16:00 config-1564664413.xml
-rw-r--r--  1 root  wheel    17M Aug  1 17:01 config-1564668028.xml
-rw-r--r--  1 root  wheel    34M Aug  2 00:04 config-1564671667.xml

Any idea why it starts growing the config file in one day this quickly?

If you need any information please let me know and I’ll provide it.

Sadly I can currently not access the GUI so I cannot check the suggested «Diag > Backup&Restore > Config history»

But I do have access to the config files using SSH if this helps.
I could also restore an old config file, but I’m not sure what the config history will show then.

Thank you in advance!

Источник