# Mysql crash one o two times every day
**URL:** https://forums.percona.com/t/mysql-crash-one-o-two-times-every-day/15476
**Category:** MySQL & MariaDB
**Tags:** mysql, percona
**Created:** [April 29, 2022, 11:41am UTC](https://forums.percona.com/t/mysql-crash-one-o-two-times-every-day/15476 "2022-04-29T11:41:01Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@albertntv](https://forums.percona.com/u/albertntv)
#### Post date: [April 29, 2022, 11:41am UTC](https://forums.percona.com/t/mysql-crash-one-o-two-times-every-day/15476/1 "2022-04-29T11:41:01Z")
Hello,
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 [https://bugs.percona.com/](https://bugs.percona.com/)
key\_buffer\_size=8388608
read\_buffer\_size=131072
max\_used\_connections=84
max\_threads=1001
thread\_count=63
connection\_count=63
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
/usr/sbin/mysqld(my\_print\_stacktrace+0x2c)[0x55eedf164b7c]
/usr/sbin/mysqld(handle\_fatal\_signal+0x591)[0x55eedefa96f1]
/lib/x86\_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f89b2943730]
/usr/sbin/mysqld(my\_hash\_sort\_bin+0x23)[0x55eedf567293]
/usr/sbin/mysqld(+0xd9df9e)[0x55eedf149f9e]
/usr/sbin/mysqld(my\_hash\_insert+0x188)[0x55eedf14a6c8]
/usr/sbin/mysqld(\_ZN11Query\_cache11store\_queryEP3THDP10TABLE\_LIST+0x42a)[0x55eedee8737a]
/usr/sbin/mysqld(\_Z12handle\_queryP3THDP3LEXP12Query\_resultyy+0x2b3)[0x55eedef0b2d3]
/usr/sbin/mysqld(+0xb1f29b)[0x55eedeecb29b]
/usr/sbin/mysqld(\_Z21mysql\_execute\_commandP3THDb+0x570c)[0x55eedeed337c]
/usr/sbin/mysqld(\_Z11mysql\_parseP3THDP12Parser\_stateb+0x485)[0x55eedeed5805]
/usr/sbin/mysqld(\_Z16dispatch\_commandP3THDPK8COM\_DATA19enum\_server\_command+0x127f)[0x55eedeed6aef]
/usr/sbin/mysqld(\_Z10do\_commandP3THD+0x1cf)[0x55eedeed7cff]
/usr/sbin/mysqld(handle\_connection+0x2c8)[0x55eedef90da8]
/usr/sbin/mysqld(pfs\_spawn\_thread+0x157)[0x55eedf1812a7]
/lib/x86\_64-linux-gnu/libpthread.so.0(+0x7fa3)[0x7f89b2938fa3]
/lib/x86\_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f89b2135eff]
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, wol.link, ‘’ 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
Status: NOT\_KILLED
You may download the Percona Server operations manual by visiting
[Percona Server for MySQL is a drop-in replacement for MySQL](http://www.percona.com/software/percona-server/). 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?
thanks
---
### Author:  [@matthewb](https://forums.percona.com/u/matthewb)
#### Post date: [April 29, 2022, 3:04pm UTC](https://forums.percona.com/t/mysql-crash-one-o-two-times-every-day/15476/2 "2022-04-29T15:04:11Z")
> [@albertntv](#):
>
> /usr/sbin/mysqld(handle\_fatal\_signal+0x591)[0x55eedefa96f1]
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.
---
### Author:  [@albertntv](https://forums.percona.com/u/albertntv)
#### Post date: [April 29, 2022, 3:10pm UTC](https://forums.percona.com/t/mysql-crash-one-o-two-times-every-day/15476/3 "2022-04-29T15:10:34Z")
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
---
### Author:  [@matthewb](https://forums.percona.com/u/matthewb)
#### Post date: [April 29, 2022, 3:14pm UTC](https://forums.percona.com/t/mysql-crash-one-o-two-times-every-day/15476/4 "2022-04-29T15:14:35Z")
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?
```auto
query_cache_type=0
query_cache_size=0
```
---
### Author:  [@albertntv](https://forums.percona.com/u/albertntv)
#### Post date: [April 29, 2022, 3:21pm UTC](https://forums.percona.com/t/mysql-crash-one-o-two-times-every-day/15476/5 "2022-04-29T15:21:41Z")
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.
thanks
---
### Author:  [@albertntv](https://forums.percona.com/u/albertntv)
#### Post date: [May 23, 2022, 4:44pm UTC](https://forums.percona.com/t/mysql-crash-one-o-two-times-every-day/15476/6 "2022-05-23T16:44:06Z")
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?
Thanks
---
### Author:  [@matthewb](https://forums.percona.com/u/matthewb)
#### Post date: [May 24, 2022, 2:40am UTC](https://forums.percona.com/t/mysql-crash-one-o-two-times-every-day/15476/7 "2022-05-24T02:40:30Z")
No. The query cache was removed in MySQL 8 so simply not allocating that memory won’t have any negative impact.
---
### Author:  [@albertntv](https://forums.percona.com/u/albertntv)
#### Post date: [June 14, 2022, 10:16am UTC](https://forums.percona.com/t/mysql-crash-one-o-two-times-every-day/15476/8 "2022-06-14T10:16:37Z")
ok, thanks you very much
---
### Author:  [@Mingyang\_Cai](https://forums.percona.com/u/Mingyang_Cai)
#### Post date: [October 14, 2024, 6:51am UTC](https://forums.percona.com/t/mysql-crash-one-o-two-times-every-day/15476/9 "2024-10-14T06:51:25Z")
hello ,i have use mysql5.7.29 and has same problem，i has check query\_cache\_type=0 query\_cache\_size=0 and check dmesg -T and free -h
free -h
total used free shared buff/cache available
Mem: 251G 87G 3.7G 4.1G 160G 158G
Swap: 0B 0B 0B
is there any thing can cause this?
---
### Author:  [@matthewb](https://forums.percona.com/u/matthewb)
#### Post date: [October 14, 2024, 5:13pm UTC](https://forums.percona.com/t/mysql-crash-one-o-two-times-every-day/15476/10 "2024-10-14T17:13:07Z")
@Mingyang_Cai This is a 2 year old thread which is solved. Please open a new thread with logs.