☰

MariaDB - продолжает использовать больше памяти

tag-icon • tag-icon centos mysql memory mariadb
MariaDB - продолжает использовать больше памяти

Мы используем Maria DB 10.6.9 на CentOS и наблюдаем, что он продолжает увеличивать использование памяти. Характеристики сервера: RAM - 128 ГБ vCPUs - 48 Swap - 100 ГБ

Мы настроили innodb_buffer_pool на 65 ГБ.

Однако в настоящее время использование памяти выглядит следующим образом: введите описание изображения здесь

И мы продолжаем наблюдать рост свопов.

Сервер предназначен для MariaDb, и на нем не запущено никаких других приложений, кроме MariaDb.

Ночью нагрузка снижается, но мы не видим, чтобы MariaDB восстанавливалась и освобождала память.

У нас есть аналогичный сервер БД, работающий под управлением MySQL 5.7.38, и мы не наблюдаем подобной проблемы.

Мы будем очень признательны за любые идеи, которые помогут нам понять следующее:

  1. Что использует память в mariadb?
  2. Какие таблицы загружены в память и могут вызывать повышенное использование памяти?
  3. Как дополнительно проанализировать инструменты, которые могут дать нам представление об использовании памяти mariadb?

Какая-либо еще информация может вам понадобиться, чтобы лучше понять нашу ситуацию?

Ниже приведен текущий статус Innodb: Статус Innodb

[Запрашивается дополнительная информация]
A:https://justpaste.it/cs5vw
Б:https://justpaste.it/9868l
С:https://justpaste.it/8q99c
Д:https://justpaste.it/byhv5
Э:https://justpaste.it/cgnum
Г:https://justpaste.it/ba5if

ХТОП:https://justpaste.it/dd57f

Дополнительная информация Часть 2
1)https://jpst.it/30ItC- топ -б -н 1
2)https://jpst.it/30OBo- верх -б -н 1 -Н
3)https://jpst.it/30OGm- ulimit -a
4)https://jpst.it/30OKb- iostat -xm 5 3
5)https://jpst.it/30OME- дф -ч
6)https://jpst.it/30OPx- бесплатно -h
7)https://jpst.it/30OQF- кот /proc/meminfo
8)https://jpst.it/30OTB- дф -и

решение1

Возможные причины использования памяти,

Обычно мы видим сбалансированные счетчики на com_perpare_sql, com_execute_sql и com_dealloc_sql. В вашем глобальном статусе show com_dealloc_sql (close) был пропущен 151 033 раза, что означает, что ресурсы не были освобождены в течение 36 дней.

Обычно мы видим сбалансированные счетчики для com_stmt_prepare, com_stmt_execute и com_stmt_close. В вашем глобальном статусе показа com_stmt_close был пропущен 373,474 раза, что означает, что ресурсы не были освобождены в течение 36 дней.

Было зафиксировано 68 677 событий aborted_clients с частотой 78 в час, что может способствовать наблюдению.

com_rollback count 117,323, что в среднем составляет откат каждые 27 секунд, иногда можно предотвратить. Обработка отката требует больших ресурсов. Найдите «как избежать отката mysql».

Пожалуйста, просмотрите профиль для получения контактной информации. Многие глобальные переменные могут быть скорректированы для улучшения производительности.

Связанный контент