LINUX.ORG.RU
решено Форум — Admin  

Периодически OOM Killer убивает MariaDB 10.5.18

 


1

1

Всем доброго дня! Помогите, пожалуйста, разобраться в проблеме! Периодически отваливается сервер БД.

Сервер с 16Гб оперативки

Debian 11
MariaDB 10.5.18
Все таблицы InnoDB

.mycnf
[mysqld]
log-error=/var/log/mysql/mysql-errors.log
innodb_buffer_pool_size = 10G

В Логах такое:

2023-03-24 15:43:49 0 [Note] InnoDB: Uses event mutexes
2023-03-24 15:43:49 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2023-03-24 15:43:49 0 [Note] InnoDB: Number of pools: 1
2023-03-24 15:43:49 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2023-03-24 15:43:49 0 [Note] InnoDB: Using Linux native AIO
2023-03-24 15:43:49 0 [Note] InnoDB: Initializing buffer pool, total size = 10737418240, chunk size = 134217728
2023-03-24 15:43:49 0 [Note] InnoDB: Completed initialization of buffer pool
2023-03-24 15:43:49 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=510990515215,510992943381
2023-03-24 15:43:49 0 [Note] InnoDB: Starting final batch to recover 2116 pages from redo log.
2023-03-24 15:43:50 0 [Note] InnoDB: 128 rollback segments are active.
2023-03-24 15:43:50 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2023-03-24 15:43:50 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2023-03-24 15:43:50 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2023-03-24 15:43:50 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2023-03-24 15:43:50 0 [Note] InnoDB: 10.5.18 started; log sequence number 511012950843; transaction id 293489669
2023-03-24 15:43:50 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2023-03-24 15:43:50 0 [Note] Plugin 'FEEDBACK' is disabled.
2023-03-24 15:43:50 0 [Note] Server socket created on IP: '127.0.0.1'.
2023-03-24 15:43:50 0 [Note] Reading of all Master_info entries succeeded
2023-03-24 15:43:50 0 [Note] Added new Master_info '' to hash table
2023-03-24 15:43:50 0 [Note] /usr/sbin/mariadbd: ready for connections.
Version: '10.5.18-MariaDB-0+deb11u1'  socket: '/run/mysqld/mysqld.sock'  port: 3306  Debian 11
2023-03-24 15:43:50 3 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
2023-03-24 15:43:50 4 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
2023-03-24 15:44:10 0 [Note] InnoDB: Buffer pool(s) load completed at 230324 15:44:10

При перезагрузке (service mysqld restart) - сервер стартует нормально. Но судя по графикам, после перезагрузки использование оперативной памяти постоянно растет и в какой-то момент опять срабатывает OOM Killed

[Fri Mar 24 15:41:03 2023] Out of memory: Killed process 953944 (mariadbd) total-vm:15435712kB, anon-rss:11604836kB, file-rss:0kB, shmem-rss:0kB, UID:111 pgtables:23380kB oom_score_adj:0

Менял настройки innodb_buffer_pool_size, не помогает Что еще можно покрутить?

Заранее спасибо! )



Последнее исправление: Sega (всего исправлений: 3)
← Как сделать сервер маршрутизации?
Кластеризация pacemaker на Astra Linux 1.7 →
 ← 1 2
Ответ на: комментарий от Sega

Это началось после переезда на новый сервер. На старом сервере таких проблем не было, с таким же количеством оперативки…

Про своп, смотрю, уже написали. Но ещё вопрос версии и/или сборки. Может просто баг у MariaDB. Можно или откатить, или, наоборот, обновить.

AS ★★★★★
()

какие были версии ОС и СУБД =до= переезда на debian11+mariadb-server-10.5 ?
по твоим логам проблем нет - если OOM не придёт, сервер просто зависнет
(а он приходит, потому что видит 11Гб потребления RSS)

d00fy ★★★
()

Парни, от общего размера БД эта проблема может возникать?

Сегодня сервер БД останавливался 4 раза (примерно раз в два часа). Поверил таблицы, одна таблица кэша выросла на 49+Гб…

Очистил ее, буду дальше наблюдать (

Sega
() автор топика
Ответ на: комментарий от d00fy

какие были версии ОС и СУБД =до= переезда на debian11+mariadb-server-10.5 ?

Сейчас уже не могу сказать. Знаю только что был Debian 10 а сейчас 11

Многие пишут про Своп, но его же не желательно для БД использовать…

Sega
() автор топика

Обычно прежде чем крутить ручки начинают с наблюдений. Метрики какие-нибудь есть, мониторинг?

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

Альтернативно, ты можешь посмотреть на источник подключений, возможно на сайтик который обслуживает эта бд пришла орда ботов и их можно оттуда прогнать?

slowpony ★★★★★
()

Когда у меня тек мускуль, я сменил ему аллокатор на jemalloc. Время на выжирание всей памяти выросло в разы, после чего всем стало пофиг и мускуль просто перезапускали планировщиком раз в несколько суток.

thesis ★★★★★
()
Ответ на: комментарий от Dimez

Ну ты-то разобрался бы и сделал бы как надо. О, погоди-ка, так ты же прямо сейчас в треде о текущем на проде мускуле! Давай же, рассказывай ТСу, что делать, не томи.

thesis ★★★★★
()
Ответ на: комментарий от thesis

Ну ему посоветовали уже, ждём ответа, дублировать советы неправильно.

P.S. Я к тому, что гордиться перезагрузкой прода по расписанию - ну прям совсем такоэ.

Dimez ★★★★★
()
Последнее исправление: Dimez (всего исправлений: 1)
Ответ на: комментарий от Dimez

Я не «горжусь перезагрузкой прода», а даю вероятно смягчающую боль свечу от геморроя ТСу на то время, которое ему потребуется для поиска и, возможно, решения проблемы. А в моем случае там и думать особо было не о чем, когда убедились, что это течет мускуль, а не мы криворукие. Откатываться? Хз, поможет ли, и продукт уже обмазан фичами новых версий. Мигрячить на постгрес? Ниасилили бы. Ночной даунтайм несколько секунд пару раз в месяц? Да боже ж мой.

А, да, я еще мог развернуть стенд с копией конфигурации и реальными данными, эмулировать нагрузку и плотно заняться профилированием. И уж точно вскоре показал бы этим лохам из оракуля, как надо писать СУБД ггг.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 2)
Ответ на: комментарий от thesis

Я не «горжусь перезагрузкой прода», а даю вероятно смягчающую боль свечу от геморроя ТСу на то время, которое ему потребуется для поиска и, возможно, решения проблемы

Значит, я не так тебя понял.

Ночной даунтайм несколько секунд пару раз в месяц?

А нет, так :))

Dimez ★★★★★
()

Ну как минимум посмотреть какой именно pool_size тебе действительно нужен (в гигабайтах)

SELECT CEILING(Total_InnoDB_Bytes*1.6/POWER(1024,3)) FROM
(SELECT SUM(data_length+index_length) Total_InnoDB_Bytes
FROM information_schema.tables WHERE engine='InnoDB') A;

Больше чем даст этот select ставить не имеет смысла.

После этого начинай ограничивать

join_buffer_size
sort_buffer_size
read_buffer_size
read_rnd_buffer_size
max_connection

и это. не слушай тех кто предлагает по крону рестартовать или добавлять swap - это глупость от неквалифицированности

adn ★★★★
()
Последнее исправление: adn (всего исправлений: 1)

… Что еще можно покрутить?

По поводу настройки OOM killer: https://www.percona.com/blog/out-of-memory-killer-or-savior/

Swap-раздел конечно надо добавить в систему. А чтобы он не использовался тупо без реальной необходимости на СУБД-шном сервере, нужно уменьшить волшебный параметр vm.swappiness в /etc/sysctl.conf - должен быть где-то в районе 10 или даже меньше (зависит от реального потребления памяти СУБД-шкой).

vinvlad ★★
()
Ответ на: комментарий от adn

это глупость от неквалифицированности

Глупость и неквалифицированность - это думать, что правка конфигов лечит софт от внутренних багов, ведущих к утечке памяти.

thesis ★★★★★
()
Ответ на: комментарий от thesis

Глупость и неквалифицированность - это думать, что правка конфигов лечит софт от внутренних багов, ведущих к утечке памяти.

Для начала надо бы конкретно выяснить, а имели ли реально место быть эти самые утечки памяти? Глупые настройки по дефолту на СУБД-шном сервере вполне могут создать проблемы на ровном месте.

Обратите внимание на значения total-vm и anon-rss:

Out of memory: Killed process 953944 (mariadbd) total-vm:15435712kB, anon-rss:11604836kB, file-rss:0kB, shmem-rss:0kB, UID:111 pgtables:23380kB oom_score_adj:0

почитайте, что они означают…

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Для начала надо бы конкретно выяснить, а имели ли реально место быть эти самые утечки памяти?

Разумеется, надо. А теперь внимание, вопросы: что лучше ДАЖЕ ПОКА МЫ НЕ ВЫЯСНИЛИ ПРИЧИНУ: запланированный перезапуск по крону во время минимальной нагрузки на сервис, или выстрел в затылок от oom killer'а в произвольный момент времени? В каком случае больше визга от юзеров? В каком случае выше риск потери данных?

почитайте, что они означают…

Вот это многозначительное многоточие - оно должно навести меня на мысли, что проблема точно не в утечке? Или что?

thesis ★★★★★
()
Ответ на: комментарий от thesis

… А теперь внимание, вопросы: что лучше ДАЖЕ ПОКА МЫ НЕ ВЫЯСНИЛИ ПРИЧИНУ

Для начала, как уже было сказано выше, лучше добавить SWAP и правильно настроить vm.swappiness - ну т.е позволить СУБД-шке без проблем использовать все реально доступное пространство оперативной памяти сервера. И далее посмотреть, будет ли иметь место своппинг и грохание СУБД-шки OOM-киллером. Еще разок можно и потерпеть. А далее уже предпринимать другие меры.

Вот это многозначительное многоточие …

Ну вообще-то anon-rss:11604836kB - т.е. СУБД-шка, вроде как, не заюзала всю имеющуюся оперативную память. При неправильных системных настройках так бывает, что OOM-killer начинает суетиться слишком рано - особенно, когда нет SWAP-а.

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Вообще согласен приблизительно со всем.
Но чот сдается мне (по причине собственного трагического опыта), что там просто помимо субд бежит еще что-то, доедающее остаток памяти. Например, умельцы прикрутили скрипт бэкапа, который начинает прямо на сервере тщательно паковать дамп, и...
В пользу твоих доводов говорит то, что утечки, которые я видел, показывали гораздо большее выделение виртуальной памяти.

Еще раз проговорю, более внятно: то, что я первым своим каментом писал про костыли и jemalloc - сказано о ситуации "мы точно знали, что это мемлик, не лечащийся конфигурированием или минорным апгрейдом/даунгрейдом".

thesis ★★★★★
()
Ответ на: комментарий от adn

Ну как минимум посмотреть какой именно pool_size тебе действительно нужен (в гигабайтах)

MariaDB [(none)]> SELECT CEILING(Total_InnoDB_Bytes*1.6/POWER(1024,3)) FROM
    -> (SELECT SUM(data_length+index_length) Total_InnoDB_Bytes
    -> FROM information_schema.tables WHERE engine='InnoDB') A;
+-----------------------------------------------+
| CEILING(Total_InnoDB_Bytes*1.6/POWER(1024,3)) |
+-----------------------------------------------+
|                                            14 |
+-----------------------------------------------+
1 row in set (0,491 sec)
Sega
() автор топика

mysqlTuner


>>  MySQLTuner 2.1.1
	 * Jean-Marie Renouard <jmrenouard@gmail.com>
	 * Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.pl/
 >>  Run with '--help' for additional options and output filtering

[--] Skipped version check for MySQLTuner script
[OK] Logged in using credentials passed on the command line
[!!] Failed to execute: SHOW REPLICA STATUS\G
[!!] FAIL Execute SQL / return code: 256
[!!] Failed to execute: SHOW SLAVE STATUS
[!!] FAIL Execute SQL / return code: 256
[OK] Currently running supported MySQL version 10.5.18-MariaDB-0+deb11u1
[OK] Operating on 64-bit architecture
 
-------- Log file Recommendations ------------------------------------------------------------------
[OK] Log file /var/log/mysql/mysql-errors.log exists
[--] Log file: /var/log/mysql/mysql-errors.log (304K)
[OK] Log file /var/log/mysql/mysql-errors.log is not empty
[OK] Log file /var/log/mysql/mysql-errors.log is smaller than 32 Mb
[OK] Log file /var/log/mysql/mysql-errors.log is readable.
[!!] /var/log/mysql/mysql-errors.log contains 1381 warning(s).
[!!] /var/log/mysql/mysql-errors.log contains 2 error(s).
[--] 54 start(s) detected in /var/log/mysql/mysql-errors.log
[--] 1) 2023-03-27  9:40:02 0 [Note] /usr/sbin/mariadbd: ready for connections.
[--] 2) 2023-03-27  9:15:02 0 [Note] /usr/sbin/mariadbd: ready for connections.
[--] 3) 2023-03-27  6:45:03 0 [Note] /usr/sbin/mariadbd: ready for connections.
[--] 4) 2023-03-27  6:10:03 0 [Note] /usr/sbin/mariadbd: ready for connections.
[--] 5) 2023-03-27  5:20:03 0 [Note] /usr/sbin/mariadbd: ready for connections.
[--] 6) 2023-03-27  4:00:02 0 [Note] /usr/sbin/mariadbd: ready for connections.
[--] 7) 2023-03-27  3:05:03 0 [Note] /usr/sbin/mariadbd: ready for connections.
[--] 8) 2023-03-27  1:15:02 0 [Note] /usr/sbin/mariadbd: ready for connections.
[--] 9) 2023-03-27  0:35:02 0 [Note] /usr/sbin/mariadbd: ready for connections.
[--] 10) 2023-03-26 23:25:02 0 [Note] /usr/sbin/mariadbd: ready for connections.
[--] 6 shutdown(s) detected in /var/log/mysql/mysql-errors.log
[--] 1) 2023-03-25 10:26:11 0 [Note] /usr/sbin/mariadbd: Shutdown complete
[--] 2) 2023-03-24 18:11:29 0 [Note] /usr/sbin/mariadbd: Shutdown complete
[--] 3) 2023-03-24  9:50:12 0 [Note] /usr/sbin/mariadbd: Shutdown complete
[--] 4) 2023-03-23 11:36:37 0 [Note] /usr/sbin/mariadbd: Shutdown complete
[--] 5) 2023-03-23 11:15:07 0 [Note] /usr/sbin/mariadbd: Shutdown complete
[--] 6) 2023-03-23  9:53:55 0 [Note] /usr/sbin/mariadbd: Shutdown complete
 
-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +Aria +CSV +InnoDB +MEMORY +MRG_MyISAM +MyISAM +PERFORMANCE_SCHEMA +SEQUENCE 
[--] Data in InnoDB tables: 10.2G (Tables: 614)
[OK] Total fragmented tables: 0
 
-------- Analysis Performance Metrics --------------------------------------------------------------
[--] innodb_stats_on_metadata: OFF
[OK] No stat updates during querying INFORMATION_SCHEMA.
 
-------- Views Metrics -----------------------------------------------------------------------------
 
-------- Triggers Metrics --------------------------------------------------------------------------
 
-------- Routines Metrics --------------------------------------------------------------------------
 
-------- Security Recommendations ------------------------------------------------------------------
[--] Skipped due to none of known auth columns exists
 
-------- CVE Security Recommendations --------------------------------------------------------------
[OK] NO SECURITY CVE FOUND FOR YOUR VERSION
 
-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 27m 37s (5M q [3K qps], 10K conn, TX: 70G, RX: 3G)
[--] Reads / Writes: 96% / 4%
[--] Binary logging is disabled
[--] Physical Memory     : 15.6G
[--] Max MySQL memory    : 13.0G
[--] Other process memory: 0B
[--] Total buffers: 10.2G global + 18.9M per thread (150 max threads)
[--] Performance_schema Max memory usage: 0B
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 11.6G (74.14% of installed RAM)
[OK] Maximum possible memory usage: 13.0G (82.88% of installed RAM)
[OK] Overall possible memory usage with other process is compatible with memory available
[OK] Slow queries: 0% (193/5M)
[OK] Highest usage of available connections: 50% (76/150)
[OK] Aborted connections: 0.02% (2/10108)
[!!] Name resolution is active: a reverse name resolution is made for each new connection which can reduce performance
[OK] Query cache is disabled by default due to mutex contention on multiprocessor machines.
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 2M sorts)
[!!] Joins performed without indexes: 19429
[OK] Temporary tables created on disk: 0% (28 on disk / 236K total)
[OK] Thread cache hit rate: 99% (76 created / 10K connections)
[OK] Table cache hit rate: 99% (6M hits / 6M requests)
[!!] table_definition_cache (400) is less than number of tables (696) 
[OK] Open file limit used: 0% (14/16K)
[OK] Table locks acquired immediately: 100% (1K immediate / 1K locks)
Sega
() автор топика 
-------- Performance schema ------------------------------------------------------------------------
[!!] Performance_schema should be activated.
[--] Sys schema is not installed.
 
-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is disabled.
 
-------- MyISAM Metrics ----------------------------------------------------------------------------
[--] No MyISAM table(s) detected ....
 
-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[--] InnoDB Thread Concurrency: 0
[OK] InnoDB File per table is activated
[!!] InnoDB buffer pool / data size: 10.0G / 10.2G
[!!] Ratio InnoDB log file size / InnoDB Buffer pool size (0.9375%): 96.0M * 1 / 10.0G should be equal to 25%
[--] Number of InnoDB Buffer Pool Chunk: 80 for 1 Buffer Pool Instance(s)
[OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances
[OK] InnoDB Read buffer efficiency: 99.99% (3712978619 hits / 3713186813 total)
[!!] InnoDB Write Log efficiency: 73.74% (221016 hits / 299728 total)
[OK] InnoDB log waits: 0.00% (0 waits / 78712 writes)
 
-------- Aria Metrics ------------------------------------------------------------------------------
[--] Aria Storage Engine is enabled.
[OK] Aria pagecache size / total Aria indexes: 128.0M/0B
[!!] Aria pagecache hit rate: 15.0% (20 cached / 17 reads)
 
-------- TokuDB Metrics ----------------------------------------------------------------------------
[--] TokuDB is disabled.
 
-------- XtraDB Metrics ----------------------------------------------------------------------------
[--] XtraDB is disabled.
 
-------- Galera Metrics ----------------------------------------------------------------------------
[--] Galera is disabled.
 
-------- Replication Metrics -----------------------------------------------------------------------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] Binlog format: MIXED
[--] XA support enabled: ON
[--] Semi synchronous replication Master: OFF
[--] Semi synchronous replication Slave: OFF
[--] This is a standalone server
 
-------- Recommendations ---------------------------------------------------------------------------
General recommendations:
    Check warning line(s) in /var/log/mysql/mysql-errors.log file
    Check error line(s) in /var/log/mysql/mysql-errors.log file
    MySQL was started within the last 24 hours: recommendations may be inaccurate
    Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1
    We will suggest raising the 'join_buffer_size' until JOINs not using indexes are found.
             See https://dev.mysql.com/doc/internals/en/join-buffer-size.html
             (specially the conclusions at the bottom of the page).
    Performance schema should be activated for better diagnostics
    Consider installing Sys schema from https://github.com/FromDual/mariadb-sys for MariaDB
    Before changing innodb_log_file_size and/or innodb_log_files_in_group read this: https://bit.ly/2TcGgtU
Variables to adjust:
    skip-name-resolve=1
    join_buffer_size (> 256.0K, or always use indexes with JOINs)
    table_definition_cache (400) > 696 or -1 (autosizing if supported)
    performance_schema=ON
    innodb_buffer_pool_size (>= 10.2G) if possible.
    innodb_log_file_size should be (=2G) if possible, so InnoDB total log file size equals 25% of buffer pool size.
Sega
() автор топика

И прогнал еще проверку через tuning-primer.sh

% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 64696  100 64696    0     0   220k      0 --:--:-- --:--:-- --:--:--  219k
 
 -- MYSQL PERFORMANCE TUNING PRIMER --
      - By: Matthew Montgomery -

MySQL Version 10.5.18-MariaDB-0+deb11u1 x86_64

Uptime = 0 days 0 hrs 30 min 10 sec
Avg. qps = 3243.76
Total Questions = 5871219
Threads Connected = 8

Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/10.5/en/server-system-variables.html

Visit https://github.com/BMDan/tuning-primer.sh for the latest version of
this script, or to suggest improvements.

SLOW QUERIES
The slow query log is NOT enabled.

BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/10.5/en/point-in-time-recovery.html

WORKER THREADS
Current thread_cache_size = 150
Current threads_cached = 73
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 150
Current threads_connected = 5
Historic max_used_connections = 76
The number of used connections is 50% of the configured maximum.
Your max_connections variable seems to be fine.

INNODB STATUS
Current InnoDB index space = 1.62 G
Current InnoDB data space = 8.84 G
Current InnoDB buffer pool free = 42 %
Current innodb_buffer_pool_size = 10.00 G
Depending on how much space your innodb indexes take up it may be safe
to increase this value to up to 2 / 3 of total system memory

MEMORY USAGE
Max Memory Ever Allocated : 10.26 G
Configured Max Per-thread Buffers : 436 M
Configured Max Global Buffers : 10.04 G
Configured Max Memory Limit : 10.47 G
Physical Memory : 15.63 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
No key reads.  If you aren't using MyISAM, this is normal.  If you are
using MyISAM, this is very, very bad.
Current MyISAM index space = 0 bytes
Current key_buffer_size = 32 M
Key cache miss rate is 1 : 0
Key buffer free ratio = 81 %
Your key_buffer_size seems to be fine

QUERY CACHE
You have query cache enabled.  With many versions of the server, you may see
query cache lock contention, especially if you have more than one core.
Current query_cache_size = 1 M
Current query_cache_used = 16 K
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 1.64 %
Current query_cache_min_res_unit = 4 K
Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 2 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 260.00 K
You have had 21521 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 16384 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_open_cache = 2000 tables
Current table_definition_cache = 400 tables
You have a total of 739 tables
You have 2000 open tables.
Current table_cache hit rate is 89%
, while 100% of your table cache is in use
You should probably increase your table_cache
You should probably increase your table_definition_cache value.

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 16 M
Of 267274 temp tables, 0% were created on disk
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 128 K
Current table scan ratio = 41 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 0 : 5875296
Your table locking seems to be fine
Sega
() автор топика
Ответ на: комментарий от Sega

Можно ли как-то по этим данным хоть чуть-чуть более приближенно понять проблему? )

Смотрим:

[--] Data in InnoDB tables: 10.2G (Tables: 614)
[--] Physical Memory     : 15.6G
[--] Max MySQL memory    : 13.0G
Total buffers: 10.2G global + 18.9M per thread (150 max threads)
...
[OK] Maximum reached memory usage: 11.6G (74.14% of installed RAM)
(что соответствует диагностике OOM killer в момент грохания)
[OK] Maximum possible memory usage: 13.0G (82.88% of installed RAM)
...
MEMORY USAGE
Max Memory Ever Allocated : 10.26 G
Configured Max Per-thread Buffers : 436 M
Configured Max Global Buffers : 10.04 G
Configured Max Memory Limit : 10.47 G
Physical Memory : 15.63 G
Max memory limit seem to be within acceptable norms

Ну видно же, что сама СУБД-шка не вышла по памяти за допустимые пределы.

Отсюда вывод:

  • или неправильно настроен Linux (см. выше) - т.е. OOM killer активизируется без реальной надобности;
  • или какой-то другой процесс временно хапнул память, а кильнули СУБД-шку :)

По картиночке ничего не разобрать. Дополнительную инфу может дать вся диагостика OOM-killer в syslog на момент «киляния» - там должны быть дополнительные строчки относительно других процессов.

vinvlad ★★
()
Ответ на: комментарий от vinvlad

или какой-то другой процесс временно хапнул память, а кильнули СУБД-шку

Если «СУБД-шка» без вины виноватая, ) то такое решается пользовательским oom-killer, например earlyoom. Он должен быть в репах всех дистров.

Т.е, прописываем в конфигах избегать убийства (--avoid) для нужного процесса, типа EARLYOOM_ARGS="-m 5 -r 60 --avoid '(^|/)(init|Xorg|ssh)$' --prefer '(^|/)(java|chromium)$'".
А --prefer, первыми под ‘нож’, в случае нехватки памяти.

p.s. Но я не спец по MariaDB, не знаю, что там можно ‘кильнуть’ без ущерба для сервера, чтобы он остался в работе. Т.е., он, скорее, все равно отвалится.

krasnh ★★★★
()
Ответ на: комментарий от Sega

Можно ли как-то по этим данным хоть чуть-чуть более приближенно понять проблему? )

Вся диагностика, которую вы выше привели, может пригодиться потом - когда будет понятно, какие процессы реально держали оперативную память на момент срабатывания OOM killer (и сколько каждый), и от кого поступил фатальный запрос на память. Ну т. е. для начала надо тщательно разглядеть всю диагностику OOM killer.

vinvlad ★★
()
Ответ на: комментарий от vinvlad

Вот как раз с этим не могу справиться никак. Уже несколько дней ищу способ, как понять что вызывает жор всей оперативной памяти ДО срабатывания OOM killer.

Как понять какие процессы занимают всю оперативную память, непосредственно перед срабатыванием OOM killer? Может есть какие-то трюки или bash скрипт какой написать и дергать его по крон или какие-то события системы ПЕРЕД срабатыванием OOM killer. Поделитесь, плз, кто как это диагностирует…

Ну или какие-то логи, по которым можно это понять…

Sega
() автор топика
Ответ на: комментарий от Sega

Уже несколько дней ищу способ, как понять что вызывает жор всей оперативной памяти ДО срабатывания OOM killer … Ну или какие-то логи, по которым можно это понять

Ну конечно есть такой лог - /var/log/syslog (еще в /var/log/kern.log вывод может быть). Туда OOM killer выводит расклад RSS памяти по процессам на момент трындеца. Там же есть и сведения о процессе, чей финальный запрос памяти вызвал срабатывание OOM killer.

vinvlad ★★
()
 ← 1 2
← Как сделать сервер маршрутизации?
Admin
Кластеризация pacemaker на Astra Linux 1.7 →