[STDERR] PHP Fatal error: Allowed memory size exhausted

bedrock
1

I recently migrated a Bedrock website to a new server. When starting Litespeed, the site errors out with what looks like a PHP memory error. I tried adjusting the memory_limit in /usr/local/lsws/lsphp74/etc/php/7.4/litespeed/php.ini and it made no difference. I cannot seem to find where the “allowed memory” size of 746586112 in the error logs below is being set.

Any ideas on how to troubleshoot this?

2024-02-05 14:51:05.456143 [NOTICE] [4085] [172.71.26.115:32956:HTTP2-1#staging.qtreatment.com] [STDERR] PHP Fatal error: Allowed memory size of 746586112 bytes exhausted (tried to allocate 20480 bytes) in /usr/local/lsws/staging.qtreatment.com/web/wp/wp-includes/class-wp-hook.php on line 77
2024-02-05 14:51:05.464438 [NOTICE] [4085] [172.71.26.115:32956:HTTP2-1#staging.qtreatment.com] [STDERR] PHP Fatal error: Allowed memory size of 746586112 bytes exhausted (tried to allocate 20480 bytes) in /usr/local/lsws/staging.qtreatment.com/web/wp/wp-includes/plugin.php on line 511
2024-02-05 14:51:09.234260 [NOTICE] [4085] [LocalWorker::workerExec] VHost:_AdminVHost suExec check uid 999 gid 65534 setuidmode 2.
2024-02-05 14:51:09.234432 [INFO] [4085] [LocalWorker::workerExec] VHost:_AdminVHost suExec check uid 999 gid 65534 setuidmode 2.
2024-02-05 14:51:09.234511 [NOTICE] [4085] [LocalWorker::workerExec] Config[AdminPHP]: suExec uid -1 gid -1 cmd /usr/local/lsws/admin/fcgi-bin/admin_php -c …/conf/php.ini, final uid 999 gid 65534, flags: 0.
2024-02-05 14:51:09.234908 [NOTICE] [4085] [AdminPHP] add child process pid: 4195
2024-02-05 14:51:17.474986 [NOTICE] [4085] [172.71.122.153:26338:HTTP2-1#staging.qtreatment.com] [STDERR] PHP Fatal error: Allowed memory size of 746586112 bytes exhausted (tried to allocate 262144 bytes) in /usr/local/lsws/staging.qtreatment.com/web/wp/wp-admin/includes/file.php on line 2155
2024-02-05 14:51:17.489854 [NOTICE] [4085] [172.71.122.153:26338:HTTP2-1#staging.qtreatment.com] [STDERR] PHP Fatal error: Allowed memory size of 746586112 bytes exhausted (tried to allocate 262144 bytes) in Unknown on line 0
2024-02-05 14:51:40.006071 [NOTICE] [4085] sendKillCmdToWatchdog: ‘extappkill:4195:-3:0’.
2024-02-05 14:51:40.200371 [NOTICE] [4083] Cmd from child: [extappkill:4195:-3:0]

2

Is this a roots.io-Bedrock site? There you would create a configuration environment file, as config/environments/production.php and set the memory limit as constant (1 GB in this example):

Config::define('WP_MEMORY_LIMIT', '1G');
3

Yes, this is a roots.io Bedrock site. There is a /config/environments /development file that exists today (and is referenced in the .env file: WP_ENV=‘development’) that I added the WP_MEMORY_LIMIT and set to 1GB, per your instructions. After a Lightspeed restart, the error is persisting, but this time reflecting the bump to 1GB. It seems any size of memory limit just reflects the error, but at the set memory limit. Something else has to be the culprit here.

Interestingly, its the same allocation size of 262144 bytes causing the problem in every scenario. The request is simply a POST to /wp/wp-login.php

Any ideas where else to look?

2024-02-05 17:19:20.331612 [NOTICE] [5190] [172.69.70.147:12654:HTTP2-1#staging.qtreatment.com] [STDERR] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 262144 bytes) in /usr/local/lsws/staging.qtreatment.com/web/wp/wp-includes/formatting.php on line 2809
2024-02-05 17:19:20.344827 [NOTICE] [5190] [172.69.70.147:12654:HTTP2-1#staging.qtreatment.com] [STDERR] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 262144 bytes) in Unknown on line 0
2024-02-05 17:19:24.364824 [NOTICE] [5191] [172.69.70.147:20338:HTTP2-1#staging.qtreatment.com] [STDERR] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 41943040 bytes) in /usr/local/lsws/staging.qtreatment.com/web/wp/wp-includes/class-wp-hook.php on line 79

4

This appears to be a symptom of an infinite loop.
One thing that should help in this case is systematically disabling plugins to find out what plugin is causing the loop.