Mysql with only 33 connections consuming 53GB of RAM.
innodb_buffer_pool_size configured with 34 GB
Server with 72 GB of RAM
Ubuntu 24.04.1 LTS
/usr/sbin/mysqld Ver 8.4.3 for Linux on x86_64 (MySQL Community Server - GPL)
mysql> status
--------------
mysql Ver 8.4.3 for Linux on x86_64 (MySQL Community Server - GPL)
Connection id: 52024
Current database:
Current user: user@localhost
SSL: Not in use
Current pager: stdout
Using outfile: ''
Using delimiter: ;
Server version: 8.4.3 MySQL Community Server - GPL
Protocol version: 10
Connection: Localhost via UNIX socket
Server characterset: utf8mb4
Db characterset: utf8mb4
Client characterset: utf8mb4
Conn. characterset: utf8mb4
UNIX socket: /var/run/mysqld/mysqld.sock
Binary data as: Hexadecimal
Uptime: 5 days 16 hours 30 min 46 sec
Threads: 32 Questions: 955098704 Slow queries: 170 Opens: 674859 Flush tables: 3 Open tables: 992 Queries per second avg: 1943.445
--------------
my.ini
[mysqld]
# === Required Settings ===
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
bind_address = 0.0.0.0
datadir = /dados/mysql-data
mysql_native_password = ON
max_allowed_packet = 256M
max_connect_errors = 1000000
pid_file = /var/run/mysqld/mysqld.pid
port = 3307
skip_external_locking
skip_name_resolve
socket = /var/run/mysqld/mysqld.sock
tmpdir = /dados/mysql-data/tmp
# === SQL Compatibility Mode ===
sql_mode='STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION'
# === InnoDB Settings ===
innodb_buffer_pool_instances = 8
innodb_buffer_pool_size = 34G
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_log_buffer_size = 64M
innodb_sort_buffer_size = 1M
innodb_stats_on_metadata = 0
innodb_use_fdatasync = 1
transaction_isolation = READ-COMMITTED
innodb_redo_log_capacity = 536870912
#innodb_thread_concurrency = 4
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_io_capacity = 10000
innodb_io_capacity_max = 20000
key_buffer_size = 4M # UPD
# === Connection Settings ===
max_connections = 200
back_log = 512
thread_cache_size = 100
interactive_timeout = 3600
wait_timeout = 3600
# === Buffer Settings ===
join_buffer_size = 8M
read_buffer_size = 1M
read_rnd_buffer_size = 1M
sort_buffer_size = 4M
# === Table Settings ===
table_definition_cache = 1000
table_open_cache = 1000
open_files_limit = 8000
max_heap_table_size = 16M
tmp_table_size = 32M
# === Binary Logging ===
server_id = 6
log_bin = binlog
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON
binlog_expire_logs_seconds = 345600
replica_parallel_workers = 10
log_replica_updates = 0
relay_log = relaybinlog
# === Error & Slow Query Logging ===
log_error = /var/log/mysql/error.log
log_queries_not_using_indexes = 0
long_query_time = 1
slow_query_log = 1
slow_query_log_file = /dados/mysql-data/mysql_slow.log
general_log = 0
general_log_file = /dados/mysql-data/mysql_general.log
log_timestamps = SYSTEM
lower_case_table_names=1
local_infile=1
log_error_verbosity = 3
slave-skip-errors=1062,1032,1735,1452
[mysqldump]
quick
quote_names
max_allowed_packet = 256M
Hello @CharlesR
As this is related to memory usage I would just using performance_schema and sys database queries to find out the top memory consumption instruments
https://dev.mysql.com/doc/refman/8.4/en/monitor-mysql-memory-use.html
Example:
This sys schema query aggregates currently allocated memory (current_alloc) by code area:
mysql> SELECT SUBSTRING_INDEX(event_name,'/',2) AS
code_area, FORMAT_BYTES(SUM(current_alloc))
AS current_alloc
FROM sys.x$memory_global_by_current_bytes
GROUP BY SUBSTRING_INDEX(event_name,'/',2)
ORDER BY SUM(current_alloc) DESC;
Hi @lalit.choudhary ,
Note that adding everything up, it is using 37GB of RAM, which would be ok, but it is currently consuming a total of 57 GB, and the values ââincrease every day.
This did not occur in MySQL 5.7.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2140222 mysql 20 0 62.0g **57.7g** 41856 S 47.8 81.6 34,43 mysqld
+---------------------------+---------------+
| code_area | current_alloc |
+---------------------------+---------------+
| memory/innodb | 34.92 GiB |
| memory/sql | 2.43 GiB |
| memory/performance_schema | 267.69 MiB |
| memory/temptable | 13.00 MiB |
| memory/mysys | 6.56 MiB |
| memory/mysqld_openssl | 756.57 KiB |
| memory/refcache | 21.46 KiB |
| memory/mysqlx | 3.45 KiB |
| memory/vio | 3.34 KiB |
| memory/myisam | 728 bytes |
| memory/csv | 120 bytes |
| memory/blackhole | 120 bytes |
+---------------------------+---------------+
12 rows in set (0.01 sec)
@CharlesR Please also check sys.memory_by_user_by_current_bytes, and sys.memory_by_thread_by_current_bytes
Hi @matthewb
mysql> select * from sys.memory_by_user_by_current_bytes;
+------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
| user | current_count_used | current_allocated | current_avg_alloc | current_max_alloc | total_allocated |
+------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
| app_user | 1093385 | 4.26 GiB | 4.09 KiB | 2.36 GiB | 11.13 TiB |
| background | 22017 | 52.13 MiB | 2.42 KiB | 34.67 MiB | 144.13 GiB |
| repl | 105 | 116.73 KiB | 1.11 KiB | 54.14 KiB | 3.06 GiB |
| event_scheduler | 3 | 16.27 KiB | 5.42 KiB | 16.04 KiB | 16.27 KiB |
| debian-sys-maint | 0 | 0 bytes | 0 bytes | 0 bytes | 1.68 MiB |
| datadog | -2 | -32.02 KiB | 16.01 KiB | 0 bytes | 97.09 GiB |
+------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
6 rows in set (0.01 sec)
mysql> select * from sys.memory_by_thread_by_current_bytes;
+-----------+---------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
| thread_id | user | current_count_used | current_allocated | current_avg_alloc | current_max_alloc | total_allocated |
+-----------+---------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
| 55356 | app_user@10.10.200.3 | 154122 | 2.35 GiB | 15.99 KiB | 2.19 GiB | 225.62 GiB |
| 27623 | app_user@10.10.200.2 | 414743 | 743.85 MiB | 1.84 KiB | 584.73 MiB | 2.08 TiB |
| 56967 | app_user@10.10.10.3 | 65989 | 327.51 MiB | 5.08 KiB | 171.29 MiB | 94.85 GiB |
| 29036 | app_user@10.10.200.5 | 163079 | 319.95 MiB | 2.01 KiB | 276.51 MiB | 90.20 GiB |
| 152 | app_user@10.10.200.6 | 82713 | 250.78 MiB | 3.10 KiB | 215.24 MiB | 72.47 GiB |
| 27649 | app_user@10.10.200.2 | 84161 | 148.15 MiB | 1.80 KiB | 124.56 MiB | 201.09 GiB |
| 54938 | app_user@10.10.200.6 | 12099 | 73.83 MiB | 6.25 KiB | 52.90 MiB | 118.75 GiB |
| 50 | innodb/clone_gtid_thread | 6453 | 36.68 MiB | 5.82 KiB | 34.62 MiB | 15.07 GiB |
| 29025 | app_user@10.10.200.5 | 13151 | 26.36 MiB | 2.05 KiB | 21.77 MiB | 7.95 GiB |
| 29028 | app_user@10.10.200.5 | 50349 | 22.65 MiB | 471 bytes | 14.60 MiB | 564.52 GiB |
| 62408 | charles@localhost | 119 | 16.31 MiB | 140.36 KiB | 16.00 MiB | 16.55 MiB |
| 27650 | app_user@10.10.200.2 | 33046 | 13.77 MiB | 436 bytes | 9.63 MiB | 573.28 GiB |
| 41 | innodb/dict_stats_thread | 4368 | 11.59 MiB | 2.72 KiB | 9.38 MiB | 8.95 GiB |
| 57 | app_user@10.10.200.6 | 4862 | 7.74 MiB | 1.63 KiB | 5.93 MiB | 22.84 GiB |
| 27642 | app_user@10.10.200.2 | 2271 | 6.38 MiB | 2.88 KiB | 5.91 MiB | 15.47 GiB |
| 57203 | app_user@10.10.10.2 | 1760 | 5.38 MiB | 3.13 KiB | 3.39 MiB | 33.34 GiB |
| 27620 | app_user@10.10.200.2 | 3073 | 3.78 MiB | 1.26 KiB | 2.39 MiB | 15.13 GiB |
| 29035 | app_user@10.10.200.5 | 4289 | 3.04 MiB | 742 bytes | 1.22 MiB | 64.82 GiB |
| 29032 | app_user@10.10.200.5 | 1104 | 2.72 MiB | 2.52 KiB | 2.20 MiB | 12.85 GiB |
| 55 | sql/compress_gtid_table | 1265 | 2.13 MiB | 1.72 KiB | 1.85 MiB | 44.07 MiB |
| 131 | app_user@10.10.200.6 | 707 | 2.01 MiB | 2.91 KiB | 1.00 MiB | 24.51 GiB |
| 29039 | app_user@10.10.200.5 | 816 | 1.62 MiB | 2.04 KiB | 1.32 MiB | 3.27 GiB |
| 1 | sql/main | 8224 | 1.53 MiB | 195 bytes | 402.17 KiB | 1.95 GiB |
| 29033 | app_user@10.10.200.5 | 916 | 1.04 MiB | 1.17 KiB | 811.74 KiB | 10.40 GiB |
| 51130 | app_user@10.10.200.5 | 321 | 637.76 KiB | 1.99 KiB | 534.31 KiB | 649.11 MiB |
| 27666 | app_user@10.10.200.2 | 142 | 219.50 KiB | 1.55 KiB | 138.91 KiB | 2.10 GiB |
| 32 | innodb/log_writer_thread | 1538 | 192.25 KiB | 128 bytes | 192.25 KiB | 262.84 KiB |
| 27643 | app_user@10.10.200.2 | 52 | 107.39 KiB | 2.07 KiB | 50.58 KiB | 6.92 GiB |
| 61452 | app_user@10.212.134.3 | 21 | 44.41 KiB | 2.11 KiB | 23.71 KiB | 553.51 KiB |
| 27664 | app_user@10.10.200.2 | 9 | 44.02 KiB | 4.89 KiB | 18.05 KiB | 1.65 GiB |
| 29038 | app_user@10.10.200.5 | 14 | 37.12 KiB | 2.65 KiB | 18.05 KiB | 1.65 GiB |
| 307 | repl@10.10.10.25 | 53 | 30.44 KiB | 588 bytes | 18.05 KiB | 1.02 GiB |
| 309 | repl@10.10.200.3 | 27 | 25.22 KiB | 956 bytes | 18.05 KiB | 1.02 GiB |
| 308 | repl@10.10.200.4 | 25 | 25.00 KiB | 1.00 KiB | 18.05 KiB | 1.02 GiB |
| 51110 | app_user@10.10.200.2 | 7 | 16.71 KiB | 2.39 KiB | 16.12 KiB | 641.70 MiB |
| 52 | sql/event_scheduler | 3 | 16.27 KiB | 5.42 KiB | 16.04 KiB | 16.27 KiB |
| 42 | innodb/fts_optimize_thread | 47 | 5.26 KiB | 114 bytes | 1.65 KiB | 5.38 KiB |
| 51 | innodb/srv_purge_thread | 44 | 4.59 KiB | 106 bytes | 1.65 KiB | 117.78 GiB |
| 20 | innodb/page_flush_coordinator_thread | 40 | 3.99 KiB | 102 bytes | 1.65 KiB | 4.10 KiB |
| 40 | innodb/srv_master_thread | 40 | 3.99 KiB | 102 bytes | 1.65 KiB | 57.03 MiB |
| 54 | mysqlx/acceptor_network | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 53 | sql/signal_handler | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 43 | mysqlx/worker | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 11 | innodb/io_read_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 19 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 25.86 MiB |
| 18 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 25.85 MiB |
| 17 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 25.77 MiB |
| 16 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 25.86 MiB |
| 15 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 25.85 MiB |
| 14 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 25.84 MiB |
| 13 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 25.90 MiB |
| 12 | innodb/io_write_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 25.77 MiB |
| 21 | innodb/page_flush_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 10 | innodb/io_read_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 9 | innodb/io_read_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 8 | innodb/io_read_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 7 | innodb/io_read_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 6 | innodb/io_read_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 5 | innodb/io_read_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 4 | innodb/io_read_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 3 | innodb/io_ibuf_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 30 | innodb/log_flusher_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 45 | mysqlx/acceptor_network | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 44 | mysqlx/worker | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 39 | innodb/buf_resize_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 38 | innodb/srv_monitor_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 37 | innodb/srv_error_monitor_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 36 | innodb/srv_lock_timeout_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 65.51 KiB |
| 33 | innodb/log_files_governor_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 178.12 KiB |
| 31 | innodb/log_write_notifier_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 49 | innodb/buf_dump_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 4.99 MiB |
| 29 | innodb/log_flush_notifier_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 28 | innodb/log_checkpointer_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 46.21 MiB |
| 27 | innodb/page_flush_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 26 | innodb/page_flush_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 25 | innodb/page_flush_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 24 | innodb/page_flush_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 23 | innodb/page_flush_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
| 22 | innodb/page_flush_thread | 0 | 0 bytes | 0 bytes | 0 bytes | 0 bytes |
+-----------+---------------------------------------+--------------------+-------------------+-------------------+-------------------+-----------------+
79 rows in set (0.08 sec)
Kill all âapp_userâ connections and see if that memory is freeâd up. Perhaps that user is executing too many bad queries causing extra memory to be allocated for sort buffers, join buffers, etc.
Note that the âtimeâ is not high. Shouldnât there be a limit?
Why didnât it happen in 5.7?
Donât these variables kill idle connections?
interactive_timeout = 3600
wait_timeout = 3600
mysql> show processlist;
+-------+------------------+--------------------+-------------+------------------+--------+-----------------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-------+------------------+--------------------+-------------+------------------+--------+-----------------------------------------------------------------+------------------+
| 5 | event_scheduler | localhost | NULL | Daemon | 584382 | Waiting on empty queue | NULL |
| 9 | app_user | 10.10.200.6:12659 | cli_alarcom | Sleep | 6 | | NULL |
| 82 | app_user | 10.10.200.6:12668 | cli_alarcom | Sleep | 13 | | NULL |
| 103 | app_user | 10.10.200.6:12681 | cli_alarcom | Sleep | 44 | | NULL |
| 258 | repl | 10.10.10.25:57088 | NULL | Binlog Dump GTID | 584337 | Source has sent all binlog to replica; waiting for more updates | NULL |
| 259 | repl | 10.10.200.4:10600 | NULL | Binlog Dump GTID | 584336 | Source has sent all binlog to replica; waiting for more updates | NULL |
| 260 | repl | 10.10.200.3:58286 | NULL | Binlog Dump GTID | 584336 | Source has sent all binlog to replica; waiting for more updates | NULL |
| 27571 | app_user | 10.10.200.2:15943 | cli_alarcom | Sleep | 2 | | NULL |
| 27574 | app_user | 10.10.200.2:32137 | cli_alarcom | Sleep | 0 | | NULL |
| 27593 | app_user | 10.10.200.2:39190 | cli_alarcom | Sleep | 2 | | NULL |
| 27594 | app_user | 10.10.200.2:39344 | cli_alarcom | Sleep | 3 | | NULL |
| 27600 | app_user | 10.10.200.2:44806 | cli_alarcom | Sleep | 0 | | NULL |
| 27601 | app_user | 10.10.200.2:45048 | cli_alarcom | Sleep | 1 | | NULL |
| 27615 | app_user | 10.10.200.2:49267 | cli_alarcom | Sleep | 8 | | NULL |
| 27617 | app_user | 10.10.200.2:58338 | cli_alarcom | Sleep | 7 | | NULL |
| 28976 | app_user | 10.10.200.5:43372 | cli_alarcom | Sleep | 8 | | NULL |
| 28979 | app_user | 10.10.200.5:49870 | cli_alarcom | Sleep | 1 | | NULL |
| 28983 | app_user | 10.10.200.5:51112 | cli_alarcom | Sleep | 6 | | NULL |
| 28984 | app_user | 10.10.200.5:51934 | cli_alarcom | Sleep | 1 | | NULL |
| 28986 | app_user | 10.10.200.5:57027 | cli_alarcom | Sleep | 2 | | NULL |
| 28987 | app_user | 10.10.200.5:58414 | cli_alarcom | Sleep | 4 | | NULL |
| 28989 | app_user | 10.10.200.5:63514 | cli_alarcom | Sleep | 9 | | NULL |
| 28990 | app_user | 10.10.200.5:23436 | cli_alarcom | Sleep | 8 | | NULL |
| 51061 | app_user | 10.10.200.2:45552 | cli_alarcom | Sleep | 8 | | NULL |
| 51081 | app_user | 10.10.200.5:59068 | cli_alarcom | Sleep | 5 | | NULL |
| 54889 | app_user | 10.10.200.6:48647 | cli_alarcom | Sleep | 0 | | NULL |
| 55307 | app_user | 10.10.200.3:58892 | cli_alarcom | Sleep | 6 | | NULL |
| 56918 | app_user | 10.10.10.3:60919 | cli_alarcom | Sleep | 4 | | NULL |
| 57154 | app_user | 10.10.10.2:62688 | cli_alarcom | Sleep | 0 | | NULL |
| 61403 | app_user | 10.212.134.3:59463 | cli_alarcom | Sleep | 46 | | NULL |
| 62653 | app_user | 10.212.134.2:64412 | cli_alarcom | Sleep | 4 | | NULL |
| 63550 | charles | localhost | NULL | Query | 0 | init | show processlist |
+-------+------------------+--------------------+-------------+------------------+--------+-----------------------------------------------------------------+------------------+
32 rows in set, 1 warning (0.00 sec)
There isnât a way in MySQL to limit the per-thread memory.
Why didnât it happen in 5.7?
Unknown. Youâd have to do a side-to-side comparison. Same exact data, same exact queries.
But itâs exactly the same data and the same application.
I migrated to 8.4 a month ago and from time to time I need to restart MySQL to free up memory before it consumes all the memory.
In MySQL 5.7 you donât need to do this.
Look at the value it has now: 59.0g
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2140222 mysql 20 0 62.0g 59.0g 41856 S 22.3 83.5 37,17 mysqld
Uptime: 6 days 18 hours 34 min 49 sec
Did you run with 8.0 first? Any memory issues with 8.0? Have you searched https://bugs.mysql.com/ for any other reports of memory issues with 8.4?
If you confirm that by killing all the âapp_userâ connections, the memory is release, then you know where to begin. Start looking at the queries this user is executing. Make sure none are doing full-table scans, or cross-table full JOINs. Make sure that connections are being closed when transactions are finished.
I dumped MySQL 5.7 and restored it to a new instance of 8.4.
Thatâs why I didnât upgrade to 8.0. But I know that to upgrade you need to upgrade to 8.0 first.
I found this BUG: https://bugs.mysql.com/bug.php?id=105004.
My client executes queries with IN with many values.
I have already opened the same Bug in MySQL.
Nice find.
The best practice for large IN() lists is to first create a temporary table, populate the table all the IN values. Then JOIN this table to the original query. This is optimal for several reasons: less memory for the query, and allows MySQL to optimize access using the JOIN algorithms vs the slower per-value lookups that happen with IN.
1 Like
The temporary alternative I am doing is to decrease innodb_buffer_pool_size, which is now dynamic, and then immediately return to the previous value.
This procedure frees up memory for the OS.
The only downside is that the change generates some slow queries.
That can help, but the better alternative is to fix your queries using the technique described above, rather than mess with changing settings. Changing the innodb buffer pool size, for example, incurs various internal locks while the memory is reallocated.
But this increase in memory should not occur since it did not happen in 5.7
And even with the solution above, I need to create the tables with IDs, indexes and do the join, a query that is currently done in 0.805 s will certainly be slower.
I agree. Itâs a 8.0 bug that has been reported to Oracle. Now we wait for them to fix it. In the meantime, letâs work on better query design which follows best practices to keep performance high, and resource usage low.
The temporary table can be created with a simple CREATE TEMPORARY TABLE AS SELECT âŠ, and the indexes on the joining table should already be present since thatâs the same column from your IN() clause data.
a query that is currently done in 0.805 s will certainly be slower.
Make a choice. Do you want a query that executes fast but maintains a memory leak, or do you want stable memory with a query that takes 25% (random guess) longer to execute?
Until Oracle decides to fix the issue, which seems very unlikely due to the bugâs age, you have the two choices above.
Even github said: âIn those cases, we needed to rewrite the queries prior to continuing the upgrade process.â
Hi @matthewb ,
This is a bug to me, since it did not occur in MySQL 5.7 and can result in OOM when the server runs out of memory.
Return team MySQL:
Thank you very much for your bug report.
However, this is not a bug.
That is (very much) expected behaviour with most operating systems, but especially with Linux.
Namely, OS is not releasing memory after MySQL releases it by free() or other functions or method. That is the case only when MySQL server is one of the daemons that takes most of the memory on the operating system.
That is how malloc library on OS functions.
Instead of releasing memory, malloc system library keeps it tied to the process that is running. Why ??? Because if it did not keep it with the process, malloc library would have to ask Linux kernel for memory and that is VERY expensive and (relatively) time consuming process. Instead, memory is not freed, so when a new request for memory comes from mysqld, malloc library simply takes unused memory already attached to the process and immediately makes it available.
You can check that easily.
Just write a very small program in C, containging only calloc() call, that will ask for more RAM that is currently available. Then ,mysqld size will shrink.
Do note , however, that MySQL server will run slower after that.
Not a bug.
Whatâs the link to your bug report?
