mysql 8 information_schema.processlist -> correct approach to cache it?

Question

I have a high concurrency mysql 8.0 server.
Thousands of tasks happen per second (up to a million rows per second read in average)

In some of the tasks that can be very performance intense I have an emergency switch to prevent the database queue from overflowing.

I read the number of processes (sometimes specific ones) from information_schema.processlist and if they exceed a certain value the task is skipped until the database is back in time.

So much so good, that worked perfectly fine in mysql 5.7 and before, but in mysql 8.0 they removed the query cache which might be the reason why it can not deliver such performance anymore.
In my case the server quickly is overflown with these SELECTS.

So I decided to run a background task that refreshes a table every second with a dump of the processlist.
I am using Innodb as MEMORY has more blocking issues.

This is the syntax I run every second: processlist is "LIKE information_schema.processlist but I've changed the Info blob to a varchar"

BEGIN;
truncate table processlist;
replace into processlist SELECT ID,USER,HOST,DB,COMMAND,TIME,STATE,LEFT(INFO,1024) AS INFO FROM information_schema.processlist WHERE Command != 'Sleep';
COMMIT;

I am using a transaction to prevent race conditions and just truncate + replace into.

However I am not sure if this is the best solution to populate a "mirror" table.

So my question is: is this a good approach (especially not sure what truncate might mean on performance) ? Any ideas how to do this better ?

Answer 1

(I agree that Threads_running would be better.)

As for the Processlist, simply have a single program doing:

1. Collect processlist
2. parse and analyze it (there is probably no reason to have each worker do the same processing here)
3. store the minimal amount of info in some table dedicated to this purpose. This is probably a single UPDATE statement. (Not a much heavier TRUNCATE.)
4. Repeat forever -- Do not repeat every second; do it continually or with a slight delay in the loop.

The reason for not using a cron job: When the server is too busy, you could get a new copy of the job starting before the first finishes. It is much better to simply avoid that situation rather than use transactions (or whatever) to deal with it.

MEMORY should be fine, but might not be as fast as InnoDB. The simple UPDATE is minimally invasive, so the storage engine should not matter much.

No transactions; minimal overhead.

Probably step 2 boils down to the equivalent of SHOW GLOBAL STATUS LIKE 'Threads_running';

If it takes more effort to measure how "busy" the server is than to simple forge ahead, you are wasting your time.

(A side note: REPLACE is worse than INSERT in this case -- REPLACE does a DELETE, but you have already TRUNCATEd!?)