Yeah a large number of PHP errors can eat up memory due to the size of the stack trace that’s collected alongside each one. Query Monitor version 4 reduces that memory usage considerably, but it’s still potentially unbounded.
The nuclear option is to disable error handling in QM completely:
define( 'QM_DISABLE_ERROR_HANDLER', true );
Not ideal, but it’ll allow you to use all the other panels in QM.
Short of changing the way QM transiently stores the data that it collects, there’s not really anything I can do about this. Any attempt to put a limit on the number of queries or errors that QM collects immediately makes it less useful when you inevitably need to see that information.
QM also allows you to hide errors from certain plugins or themes, but this doesn’t stop the data being collected, it just prevents the admin toolbar from showing a coloured notification. Perhaps I need to introduce a new option for completely bypassing the collection of errors from certain plugins and themes.
Hmm, while that isn’t ideal, it might help narrow things down. Besides error reporting, it’s entirely possible the issues are related to db queries or something else that is happening on those requests.
I’ll try it out and see if the issue is indeed from the error handler, or somewhere else. Thanks!
Well, I remembered an issue I had way back on my staging site that I strongly suspect could be related. It had to do with Query Monitor sending data via response headers–because naturally you can’t pollute an admin-ajax.php response or various POST requests in the wp-admin.
Anyway, I had the error replicated, then put in that constant, and it went away. I removed the constant, and now I can’t get the issue to come back…
Well, anyway, here’s what I remember from when it happened on my staging site. I was having a similar issue, I think it was also causing 502 errors. There was some fix related to increasing the fastcgi_buffers and fastcgi_buffer_size settings. My staging site is on a different server setup, but now I can’t seem to replicate it there either.
Either way, I don’t think those settings can be changed on WPE, so I wonder if there’s any way to detect such a situation and limit the amount of data returned in the admin-ajax.php headers?
Not a huge issue, if I can just remember it for next time the issue crops up, but if you have any ideas, that’d be great.
