Mysql crash one o two times every day

my percona mysql prod server crash every day with the following log.

This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
Please help us make Percona Server better by reporting any
bugs at

It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 406432 K bytes of memory
Hope that’s ok; if not, decrease some variables in the equation.

Build ID: 8cd70042119a9a870d74dbfcaf5795781cdbc5eb
Server Version: 5.7.37-40 Percona Server (GPL), Release ‘40’, Revision ‘3a1347ec0d4’

Thread pointer: 0x7f84c7be6b50
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong…
stack_bottom = 7f8552291e60 thread_stack 0x40000

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f839c693180): SELECT wo.slug as idplantilla, wol.nombrecampo, wol.idlinea, wol.proveedor as idproveedor, wol.orden, wol.tipocampo, wol.titulo, wol.disponible, ‘’ as desplegado,, ‘’ as clase_css, wol.acciones, wol.condiciones FROM web_operacionescabecera wo INNER JOIN web_operacioneslineas wol ON(wo.idweboperacion = wol.idweboperacion) WHERE wo.slug = ‘BODEGONES_DATOS_ANCLADOS’ /AND wol.disponible IN(0,1)/ AND wol.login IN (‘1’, ‘2’) AND wol.proveedor IN (‘0’, ‘UTVK’) AND wo.iddispositivo = ‘web01’ AND wol.grimpo_lastdelete IS NULL ORDER BY wol.orden ASC, wol.proveedor ASC
Connection ID (thread ID): 1612099

You may download the Percona Server operations manual by visiting
Percona Server for MySQL is a drop-in replacement for MySQL. You may find information
in the manual which will help you identify the cause of the crash.

I update with last 5.7 version and migrate server from 32 to 64 GB RAM.
I discard RAM problems, and discard query problems.
My old MySql 5.7 without Percona work perfectlly with the same databases and queries, any suggestion?


This line tells me that the linux kernel is killing MySQL. Can you please check dmesg and the system log for any OOM killer messages? If you find these, that means MySQL is using too much memory.

1 Like

Hello and thanks for answer.
i check dmesg -T and the last record is 27/04/2022 and mysql last crash ocurred today on 29/04/2022

My mysql is configured with 16GB InnoDb Buffer Pool Size and is deployed on a Debian 10 server and, this serer only runs mysq

free -h
total used free shared buff/cache available
Mem: 62Gi 22Gi 451Mi 24Mi 39Gi 39Gi
Swap: 0B 0B 0B

1 Like

Have you isolated if a specific query causes the crash?
It seems your query cache is enabled. Can you please set the following then restart MySQL and see if the issue persists?

1 Like

I make configuration change that suggest but, i think that is not a query problem because i checked the crashed logs and every time is a different query and, the same query is executed to old mysql server and works fine.

I try to set new config values and wait the feedback.

1 Like

Thanks matthweb
you solution is working, our mysql is running with none stop about 20 days.

This solutions can have any negative impact in performance?


1 Like

No. The query cache was removed in MySQL 8 so simply not allocating that memory won’t have any negative impact.

1 Like

ok, thanks you very much

1 Like