0

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 ?

  • truncate table a DDL statement, and isn't transactional. I suggest asking about your original problem. Are you using MySQL as a message queue (native implementations like rabbitmq are better)? – danblack Jan 24 at 0:07
  • 1
    No, it's not good either for 5.7 or 8.0. Your better bet would be to monitor Threads_running from SHOW GLOBAL STATUS and let the clients back off if it's too high. – akuzminsky Jan 24 at 4:46
  • Thanks for discovering and pointing out that the QC is the 'cause' of the significant slowdown. – Rick James Jan 24 at 23:35
  • What do you mean by "mirror table" – Rick James Jan 24 at 23:42
  • By "mirror" I meant a table that contains the same information as another table, a copy of it. In this case it's an innodb table 'processlist' that contains the same as information_schema.processlist. In my case it's not a complete copy because I use LEFT() to reduce the amount of data stored (some of my queries can be a few MB in size) – John Jan 24 at 23:56
0

(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!?)

  • The reason for the TRUNCATE is that I need to delete all entries from the processlist table as it's not self-delete like the original one from information_schema. Do you think this transaction once per second is having any impact on the performance ? I mean it's a small table after all. I am not using a cron job, I use a background service that will not trigger the operation twice if the previous one is still loading. The truncate is only used because I have hundreds of threads accessing the table 'processlist', they should not access it empty between TRUNCATE and INSERT. – John Jan 24 at 23:53
  • @John - I'm serious about not using truncate, and about doing the summarization in the background thread, and not using a timer to run it. Without these changes, you have multiple problems waiting to happen. Boil the processlist down to a single row of info; don't list the details. (Or justify why you need multiple rows.) – Rick James Jan 25 at 6:31
  • Like I said, the timer I am using is preventing simultaneous executions. I might go for a single number instead, with the current approach I have the possibility to select for specific States and not just the whole count. For example I can look for locked rows, rows that are sending data, etc. – John Jan 25 at 16:58
  • @John - A timer does not prevent simultaneous executions. If one invocation is severely delayed, it really can bump into the next invocation. – Rick James Jan 25 at 18:14
  • It's a background task which only executes if the previous execution is finished, it will not execute twice. That really works fine. – John Jan 25 at 18:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.