500 Errors due to PHP memory limit

[Nicholasbell03]

Pulse Version

v1.0.0-beta9

Laravel Version

10.40.0

PHP Version

8.2.13

Livewire Version

3.3.5

Database Driver & Version

MySQL 8.0.33

Description

Getting Server 500 errors on our production app when viewing the Pulse Dashboard.
Error below

-[2024-01-26 14:01:45] production.ERROR: Allowed memory size of 134217728 bytes exhausted (tried to allocate 94760960 bytes) {"userId":78,"exception":"[object] (Symfony\Component\ErrorHandler\Error\FatalError(code: 0): Allowed memory size of 134217728 bytes exhausted (tried to allocate 94760960 bytes) at /var/www/prod-campus/storage/framework/views/739ecd821f4687d0eee4066fca79ed9a.php:252)
[stacktrace]
#0 {main}
"}

Our app is a single DB (table) multitenancy app and does have a decent amount of traffic:
I'm seeing 2M entries in the pulse entries table

I'm just raising this so the issue is known whilst Pulse is still in Beta.
I can try increase the memory limit, however, I wanted to raise this first in case there is an issue around optimisation.

Worth noting that we are running Pulse on it's own DB.

I'm happy to provide any more details, or assist/lead a PR to improve this if that's helpful. I'm not an extremely experienced developer, hence why I'm raising the issue, rather than immediately being able to identify the core issue and propose a solution.

Steps To Reproduce

Run Pulse with 7-Day selected in high traffic environment.

[driesvints]

I'm guessing the solution here is indeed to raise your memory limit but will let Tim or Jess reply.

[jessarcher]

Thanks for the report, @Nicholasbell03.

From the screenshot, it looks like it's running out of memory generating the "Slow Queries" card. This makes me think it's the SQL highlighter/formatter. Pulse loads up to 100 unique SQL queries for that card, and my guess is you're near that amount and/or have some very long SQL queries.

Can you please try setting the environment variable PULSE_SLOW_QUERIES_HIGHLIGHTING to false, making sure to clear any cached config files.

If that fixes the issue, can you please report roughly how many rows you have in the Slow Queries card, and whether any of them are particularly long?

[Nicholasbell03]

@jessarcher thanks for your response.

Yes, you're right it does appear to be the "Slow Queries" card.

I see that on beta v9 there isn't a 'highlighting' => env('PULSE_SLOW_QUERIES_HIGHLIGHTING', true), config in the pulse config file.

But I found on another app I am testing it out on, using beta v7 that it does have this config variable.
I copied the pulse tables to the app on v7 just for local testing, and setting the PULSE_SLOW_QUERIES_HIGHLIGHTING to false does seem to resolve the issue.

I've checked the slow queries, and as you suspected, some are extremely long.
I identified one which was approximately 80,000 characters long.

So it appears this is likely the issue.
Let me know if I can assist with any further information, testing or assisting with any improvements here

[timacdonald]

Glad you got this sorted.

The config flag is the only real answer here, unfortunately, unless we start trimming SQL queries.

Will close this as we do have a solution to the problem.

[timacdonald]

80,000 characters long

A chunky boi!

[jessarcher]

Whoa! Sounds like a report query 😁

I agree there's not much to be done here. My only ideas are:

• Allow a configurable limit to the number of rows returned instead of 100. This might let you trade between highlighting and the amount of data you'll see.
• Find a client-side SQL formatting library and make the browser do all the work 😈

If that big query isn't problematic (i.e. it's as fast as it's going to get), you could always add an ignore rule for it.

[Nicholasbell03]

@timacdonald @jessarcher thank you for this!
I've had a look and the eloquent query does look to be very inefficient, will turn off the highlighting, so we can identify these inefficient queries.

Thank you both!