# Percona 5.7.18-16 memory leak **URL:** \ **Category:** Percona Server for MySQL 5.7\ **Created:** [September 13, 2017, 10:02am UTC](https://forums.percona.com/t/percona-5-7-18-16-memory-leak/5862 "2017-09-13T10:02:24Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![nigel2006](https://avatars.discourse-cdn.com/v4/letter/n/3d9bf3/32.png) [@nigel2006](https://forums.percona.com/u/nigel2006)\ **Post date:** [September 13, 2017, 10:02am UTC](https://forums.percona.com/t/percona-5-7-18-16-memory-leak/5862/1 "2017-09-13T10:02:24Z")
Hi! I have 2 servers with Percona Server 5.6.24-72 with master-slave replication. After ugrading to version 5.7.18-16 I’ve got memory leak on the master server(about 3 Gb a day). Before upgrade master used about 70 Gb RAM, after upgrade RAM usage ircreases every day. Maybe there’s problem in my config file? [client] #password = pass port = 3306 socket = /tmp/mysql.sock #default-character-set=cp1251 # Here follows entries for some specific programs # The MySQL server [mysqld] # NEW skip-innodb-doublewrite # Logs log\_error = /var/log/mysql/mysql.err slow\_query\_log\_file = /var/log/mysql/slow.log # sql\_mode=‘ALLOW\_INVALID\_DATES,NO\_ENGINE\_SUBSTITUTION,NO\_UNSIGNED\_SUBTRACTION’ back\_log=2048 bind-address=192.168.0.5 innodb\_file\_per\_table port = 3306 socket = /tmp/mysql.sock datadir=/var/lib/mysql tmpdir=/tmp/ key\_buffer\_size = 8M max\_allowed\_packet = 512M slave-pending-jobs-size-max = 512M table\_open\_cache=6144 table\_open\_cache\_instances=16 table\_definition\_cache = 6144 sort\_buffer\_size = 4M read\_buffer\_size = 4M read\_rnd\_buffer\_size = 2M myisam\_sort\_buffer\_size = 16M thread\_cache\_size = 4096 query\_cache\_size = 0 tmp\_table\_size = 2048M max\_heap\_table\_size = 4096M max\_connections=6000 max\_user\_connections=5990 group\_concat\_max\_len=4096 slow\_query\_log=1 connect\_timeout=10 interactive\_timeout=28800 wait\_timeout=28800 net\_write\_timeout=30 net\_read\_timeout=60 #default-character-set=cp1251 init-connect=“SET NAMES cp1251” long\_query\_time=1 skip-external-locking skip-name-resolve skip-host-cache skip-slave-start # REPLICATION # BIN-LOGGING log-bin=db\_stats11-bin binlog\_ignore\_db = mysql binlog\_ignore\_db = information\_schema binlog\_ignore\_db = performance\_schema binlog\_ignore\_db = test binlog-format=MIXED max\_binlog\_size=1073741824 sync\_binlog=0 relay-log=server1\_relay expire\_logs\_days=4 slave-skip-errors=1032,1062 replicate-ignore-db = mysql replicate-ignore-db = information\_schema replicate-ignore-db = performance\_schema replicate-ignore-db = test # Crutch for backup slave\_parallel\_workers=10 slave\_parallel\_type=DATABASE server-id = 3005 innodb\_data\_home\_dir = /var/lib/mysql/ innodb\_data\_file\_path = ibdata1:2000M;ibdata2:100M:autoextend innodb\_log\_group\_home\_dir = /var/lib/mysql/ innodb\_buffer\_pool\_size = 60G innodb\_log\_file\_size = 1G innodb\_log\_buffer\_size = 54M innodb\_flush\_log\_at\_trx\_commit = 2 innodb\_flush\_method=O\_DIRECT innodb\_lock\_wait\_timeout = 120 innodb\_read\_io\_threads = 32 innodb\_write\_io\_threads = 32 open\_files\_limit = 65535 innodb\_stats\_on\_metadata = 0 myisam-recover-options = backup,force # gtid gtid\_mode = on enforce-gtid-consistency = on log-slave-updates # [mysqldump] quick max\_allowed\_packet = 16M [mysql] no-auto-rehash [isamchk] #key\_buffer = 256M sort\_buffer\_size = 256M read\_buffer = 2M write\_buffer = 2M [myisamchk] #key\_buffer = 256M sort\_buffer\_size = 256M read\_buffer = 2M write\_buffer = 2M [mysqlhotcopy] interactive-timeout ---
**Author:** ![taraso](https://avatars.discourse-cdn.com/v4/letter/t/fbc32d/32.png) [@taraso](https://forums.percona.com/u/taraso)\ **Post date:** [November 20, 2017, 3:51pm UTC](https://forums.percona.com/t/percona-5-7-18-16-memory-leak/5862/2 "2017-11-20T15:51:31Z")
I have similar problem, but I don’t think it is a memory leak though. The binary logs accumulated on the server stay in memory cache (not just on the disk). So when you do PURGE BINARY LOGS BEFORE NOW() - INTERVAL 2 DAY, you probably should see some memory freed. I however, couldn’t find a variable that would control of how much of binary logs should stay in RAM. It would be really great if someone from Percona could shed some light into that. Also at a glance you have my.cnf that allows for enormous memory usage. You can use [http://mysqltuner.pl](http://mysqltuner.pl) script to get some rough estimates and suggestions on how to improve the config. GTID replication should be run with “ROW” binlog-format, MIXED is unsafe. Again, that’s what attracts the most of attention, but you probably should do some more work on the config. ---
**Author:** ![taraso](https://avatars.discourse-cdn.com/v4/letter/t/fbc32d/32.png) [@taraso](https://forums.percona.com/u/taraso)\ **Post date:** [November 20, 2017, 5:06pm UTC](https://forums.percona.com/t/percona-5-7-18-16-memory-leak/5862/3 "2017-11-20T17:06:30Z")
Just realized the major memory consumer in your case might be the performance schema, once it consumed RAM it won’t release it (PT can re-use consumed memory though). Turn it off by adding (unless you do some debugging): performance\_schema = 0 to your my.cnf. Otherwise you may limit some of it counters, for example: performance\_schema\_accounts\_size = 100 performance\_schema\_hosts\_size = 100 performance\_schema\_users\_size = 100 But if you are not using performance\_schema or don’t know what stats it enables, probably it is the easiest to turn it off. Note: mysql restart is required. ---
**Author:** ![zjagust](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/zjagust/32/1212_2.png) [@zjagust](https://forums.percona.com/u/zjagust)\ **Post date:** [February 8, 2018, 6:48am UTC](https://forums.percona.com/t/percona-5-7-18-16-memory-leak/5862/4 "2018-02-08T06:48:56Z")
In my case it was the enabled performance schema in combination with thread\_handling=pool-of-threads. Leaving thread\_handling on default (one-thread-per-connection) solved my memory leak problem.