xenon
@xenon
Too drunk to fsck

Почему MariaDB отжирает все больше и больше памяти?

Debian Linux 11, обновлен, пакеты стандартные.
Server version: 10.5.18-MariaDB-0+deb11u1 Debian 11

На сервере крутится PowerDNS, который берет данные из MariaDB. Данных там - с гулькин хрен, полный дамп в SQL занимает 300кб всего. Еще на сервере в docker крутится PowerDNS-Admin, и еще prometheus-grafana, и nginx (пробрасывает к графане и админке) но это не должно влиять. Просто упомянул для полноты контекста.

Проблема - при явно небольшом объеме данных, MariaDB потребляет все больше и больше, и потом прибивается по out-of-memory. Я даже сделал ежечасный лог по памяти, которая отображается в `systemctl status mysql`, в логе (первая запись в сутки) имеем вот такое:

Sat Mar  4 00:17:01 UTC 2023
     Active: active (running) since Fri 2023-03-03 06:56:31 UTC; 17h ago
     Memory: 204.9M
--
Sun Mar  5 00:17:01 UTC 2023
     Active: active (running) since Fri 2023-03-03 06:56:31 UTC; 1 day 17h ago
     Memory: 316.6M
--
Mon Mar  6 00:17:01 UTC 2023
     Active: active (running) since Fri 2023-03-03 06:56:31 UTC; 2 days ago
     Memory: 425.6M

.....

Sun Mar 12 00:17:01 UTC 2023
     Active: active (running) since Fri 2023-03-03 06:56:31 UTC; 1 weeks 1 days ago
     Memory: 1.0G


После этого oom-killer прибивает ее:
Mar 12 05:04:17 localhost kernel: [2920750.963275] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=pdns.service,mems_allowed=0,global_oom,task_memcg=/system.slice/mariadb.service,task=mariadbd,pid=1604623,uid=108
Mar 12 05:04:17 localhost kernel: [2920750.977170] Out of memory: Killed process 1604623 (mariadbd) total-vm:2526336kB, anon-rss:1104724kB, file-rss:0kB, shmem-rss:0kB, UID:108 pgtables:2492kB oom_score_adj:0


Как оно смогло отожрать гигабайт если у нее данных-то на 300кб в SQL тексте....

Потом я сделал два запроса в течение нескольких дней, и вот какую разницу вижу между первым днем (13 марта) и последним (16ое):
mysql -u root pdns -e "SHOW GLOBAL STATUS LIKE '%memory%'"

# diff march16-memory march13-memory
2c2
< Memory_used 500222384
---
> Memory_used 137681608

mysql -u root pdns -e "SHOW GLOBAL STATUS LIKE '%pages%'"

# diff march16-pages march13-pages
3c3
< Innodb_buffer_pool_pages_dirty 61
---
> Innodb_buffer_pool_pages_dirty 23

MariaDB [pdns]> SHOW ENGINE INNODB STATUS;
...
=====================================
2023-03-16 10:34:55 0x7fe894091700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 17 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 12 srv_active, 0 srv_shutdown, 332781 srv_idle
srv_master_thread log flush and writes: 332724
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 3085
OS WAIT ARRAY INFO: signal count 159436
RW-shared spins 792, rounds 285, OS waits 0
RW-excl spins 83021, rounds 151227, OS waits 2865
RW-sx spins 0, rounds 0, OS waits 0
Spin rounds per wait: 0.36 RW-shared, 1.82 RW-excl, 0.00 RW-sx
------------
TRANSACTIONS
------------
Trx id counter 4548
Purge done for trx's n:o < 4548 undo n:o < 0 state: running but idle
History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 422111884841968, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 422111884837712, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 422111884833456, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 422111884829200, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 422111884824944, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
---TRANSACTION 422111884820688, not started
0 lock struct(s), heap size 1128, 0 row lock(s)
--------
FILE I/O
--------
Pending flushes (fsync) log: 0; buffer pool: 0
453 OS file reads, 37 OS file writes, 37 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
 insert 0, delete mark 0, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0
0.00 hash searches/s, 66.58 non-hash searches/s
---
LOG
---
Log sequence number 5768253
Log flushed up to   5768253
Pages flushed up to 5739462
Last checkpoint at  5739450
0 pending log flushes, 0 pending chkp writes
40 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 301989888
Dictionary memory allocated 1730040
Buffer pool size   16130
Free buffers       15580
Database pages     550
Old database pages 223
Modified db pages  61
Percent of dirty pages(LRU & free pages): 0.378
Max dirty pages percent: 90.000
Pending reads 0
Pending writes: LRU 0, flush list 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 418, created 131, written 0
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 550, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 read views open inside InnoDB
Process ID=0, Main thread ID=0, state: sleeping
Number of rows inserted 18, updated 30, deleted 18, read 8413143
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 58.17 reads/s
Number of system rows inserted 0, updated 0, deleted 0, read 0
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================


MariaDB [pdns]> SELECT @@innodb_buffer_pool_size, @@sort_buffer_size, @@join_buffer_size, @@query_cache_size \G ;
*************************** 1. row ***************************
@@innodb_buffer_pool_size: 268435456
       @@sort_buffer_size: 2097152
       @@join_buffer_size: 262144
       @@query_cache_size: 1048576


show status where variable_name = 'threads_connected';
| Threads_connected | 6     |


pt-mysql-summary: https://gist.github.com/yaroslaff/6c934241e74debf2...

Ну как бы очевидное - mariadb признается, что она жрет память.... Но почему? что посмотреть, что подкрутить?

Решение
Обновился до 10.11.2, из репозитория с сайта mariadb.org - потребление памяти значительно снизилось.

Всем, кто помогал - большое спасибо!
  • Вопрос задан
  • 1229 просмотров
Решения вопроса 1
2ord
@2ord
1. Советую обновиться до 10.5.19 и выполнить все штатные обновления ОС - полезно на случай получения исправлений.

2. Cудя по графику в комментариях, выглядит как утечка памяти. А что за менеджер распределения памяти используется? Я бы попробовал использовать библиотеку jemalloc.

https://itmag.pro/unix/common/jemalloc-for-all-app...
https://www.ibm.com/docs/en/ztpf/2022?topic=perfor...
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
TMProject
@TMProject
Frontend developer React/Redux
Смотри в сторону таких проблем:
  1. большое количестве соединений
  2. настройка буферов
  3. использование памяти для кэша

Один из возможных способов определить, что именно занимает память, это использовать инструменты мониторинга производительности, такие как pt-mysql-summary или pt-mysql-uptime
Ответ написан
@vitaly_il1
DevOps Consulting
Сколько у вашего сервера RAM?
Ответ написан
@vladimir-losta
попробуйте mysql>reset master
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы