LINUX.ORG.RU
Форум — Admin  

Падает СУБД

 ,


0

3

Имеется ВПС на Debiad c MariaDB. + ISP панель.

Периодически падает mariadb и не перезапускается. В логах вижу
Jun 29 09:39:35 vps16408 kernel: [1267939.378888] Out of memory: Killed process 1225920 (mariadbd) total-vm:2682672kB, anon-rs s:134764kB, file-rss:0kB, shmem-rss:0kB, UID:109 pgtables:1384kB oom_score_adj:0

Что странно, поскольку памяти там за глаза. В среднем используется 10-12% в пиках доходит до 25%.

Подскажите куда копать, как выяснить «кто виноват».

Ниже вывод journalctl -eu mariadb
В 09:43:38 я сделал ручной перезапуск службы

root@vps16408:~# journalctl -eu mariadb
июн 29 09:39:34 vps16408.myvps.tld systemd[1]: mariadb.service: A process of this unit has been killed by the OOM killer.
июн 29 09:39:36 vps16408.myvps.tld systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL
июн 29 09:39:36 vps16408.myvps.tld systemd[1]: mariadb.service: Failed with result 'oom-kill'.
июн 29 09:39:36 vps16408.myvps.tld systemd[1]: mariadb.service: Consumed 42min 21.652s CPU time.
июн 29 09:43:38 vps16408.myvps.tld systemd[1]: Starting MariaDB 10.5.19 database server...
июн 29 09:43:38 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:38 0 [Warning] Could not increase number of max_open_files to more than 16384 (request: 32186)
июн 29 09:43:38 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:38 0 [Note] Starting MariaDB 10.5.19-MariaDB-0+deb11u2 source revision f8a85af8ca1c937b8d4f847477bd282f>
июн 29 09:43:38 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:38 0 [Note] InnoDB: Uses event mutexes
июн 29 09:43:38 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:38 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
июн 29 09:43:38 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:38 0 [Note] InnoDB: Number of pools: 1
июн 29 09:43:38 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:38 0 [Note] InnoDB: Using generic crc32 instructions
июн 29 09:43:38 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:38 0 [Note] InnoDB: Using Linux native AIO
июн 29 09:43:38 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:38 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, ch>
июн 29 09:43:38 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:38 0 [Note] InnoDB: Completed initialization of buffer pool
июн 29 09:43:38 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:38 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=19504084>
июн 29 09:43:38 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:38 0 [Note] InnoDB: Starting final batch to recover 486 pages from redo >
июн 29 09:43:39 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:39 0 [Note] InnoDB: 128 rollback segments are active.
июн 29 09:43:39 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:39 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
июн 29 09:43:39 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:39 0 [Note] InnoDB: Creating shared tablespace for temporary tables
июн 29 09:43:39 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:39 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically wr>
июн 29 09:43:39 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:39 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
июн 29 09:43:39 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:39 0 [Note] InnoDB: 10.5.19 started; log sequence number 19506751676; tr>
июн 29 09:43:39 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:39 0 [Note] Plugin 'FEEDBACK' is disabled.
июн 29 09:43:39 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:39 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer>
июн 29 09:43:39 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:39 0 [Note] Server socket created on IP: '127.0.0.1'.
июн 29 09:43:39 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:39 0 [Note] Reading of all Master_info entries succeeded
июн 29 09:43:39 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:39 0 [Note] Added new Master_info '' to hash table
июн 29 09:43:39 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:39 0 [Note] /usr/sbin/mariadbd: ready for connections.
июн 29 09:43:39 vps16408.myvps.tld mariadbd[1269921]: Version: '10.5.19-MariaDB-0+deb11u2'  socket: '/run/mysqld/mysqld.sock'  port: 3306  Debi>
июн 29 09:43:39 vps16408.myvps.tld systemd[1]: Started MariaDB 10.5.19 database server.
июн 29 09:43:39 vps16408.myvps.tld /etc/mysql/debian-start[1269959]: Upgrading MySQL tables if necessary.
июн 29 09:43:39 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:39 75 [Warning] Access denied for user 'root'@'localhost' (using passwor>
июн 29 09:43:39 vps16408.myvps.tld /etc/mysql/debian-start[1269970]: Looking for 'mariadb' as: /usr/bin/mariadb
июн 29 09:43:39 vps16408.myvps.tld /etc/mysql/debian-start[1269970]: Reading datadir from the MariaDB server failed. Got the following error wh>
июн 29 09:43:39 vps16408.myvps.tld /etc/mysql/debian-start[1269970]: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using passw>
июн 29 09:43:39 vps16408.myvps.tld /etc/mysql/debian-start[1269970]: FATAL ERROR: Upgrade failed
июн 29 09:43:40 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:40 90 [Warning] Access denied for user 'root'@'localhost' (using passwor>
июн 29 09:43:40 vps16408.myvps.tld debian-start[1270009]: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
июн 29 09:43:40 vps16408.myvps.tld mariadbd[1269921]: 2023-06-29  9:43:40 0 [Note] InnoDB: Buffer pool(s) load completed at 230629  9:43:40
lines 958-1006/1006 (END)

Ответ на: комментарий от hargard

/var ведь не смонтирован отдельным диском?

Я не понимаю к чему этот вопрос, но нет.

root@vps16408:~# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0  160G  0 disk
└─sda1   8:1    0  160G  0 part /
root@vps16408:~# df -h
Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
udev               3,9G            0  3,9G            0% /dev
tmpfs              796M         560K  796M            1% /run
/dev/sda1          158G          94G   57G           63% /
tmpfs              3,9G            0  3,9G            0% /dev/shm
tmpfs              5,0M            0  5,0M            0% /run/lock
tmpfs              796M            0  796M            0% /run/user/1015
tmpfs              796M            0  796M            0% /run/user/0
SeVlad
() автор топика
Ответ на: комментарий от NeoZX

OOM в dmesk/log пишет кто сколько памяти использовал в момент его вызова. Если данные

Эмм.. Не понял. Можно для тупых чуть подробнее что/как нужно сделать, куда посмотреть?

будет понятно из-за чего случился OOM.

Ну как бэ понятно - Out of memory. Или речь о чем-то другом?

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

Эмм.. Не понял. Можно для тупых чуть подробнее что/как нужно сделать, куда посмотреть?

Памяти нажрала не мария. Убили ее просто потому что так выпвли кости и oom_score сказал что ее не жалко

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

Вопрос у Вас какой почему OOM случился или как СУБД запустить/починить или другой?

Очевидно что задача выяснить «кто виноват» и потом попытаться вылечить это.

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

смотри выхлоп dmesg после вылета. Там будет километр текста и должна быть детализация ООМ.

Спс. Погуглил за dmesg но пока что-то не понял как заюзать, чтобы получить указанное. Какие ключи надо и не поздно ли? Надо сразу после падения смотреть?

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

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

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

Можете его выгрузить на какой-то сайт типа pastebin, может кто-то из местных добрых дядек покрутит колесом мыши за вас.

Спс. Удалил всё что было до времени падения (там было за прошлые дни), осталось не мало, но почему-то закончилось именно на падении (возможно так и должно быть)

https://pastebin.com/x5PTNbgN

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

А теперь смотрите. У вас есть таблица значений:

[Чт июн 29 09:39:32 2023] [1268608]  1016 1268608    74651    12602   528384     5804             0 apache2
[Чт июн 29 09:39:32 2023] [1268609]  1016 1268609    75675    12693   536576     6678             0 apache2
[Чт июн 29 09:39:32 2023] [1268610]  1016 1268610    75163    11983   532480     6960             0 apache2

Заголовок нам говорит, что

[Чт июн 29 09:39:32 2023] Tasks state (memory values in pages):
[Чт июн 29 09:39:32 2023] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name

6-й столбец - это RSS, по-простому - непосредственно занятая оперативная память (коей у вас 8 ГБ + 2 ГБ свап). Смотрим 6й столбец:

12693   
11983

Это - значения в страницах памяти (которые на Linux практически всегда 4 КБ:

12693 * 4 КБ ~ 50 MB

Смотрите по сумме памяти, кто кушает сколько, можете скопировать в Calc/excel с разбиением на пробелы и умножьте столбец на 4096, а затем отсортировав по убыванию.

Ставлю на то, что у вас apache2 выжрал всё что было и потребовал еще:

[Чт июн 29 09:39:32 2023] apache2 invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
PPP328 ★★★★★
()

Ну, тебе нужно настроить мускуль, апач и все остальное, чтобы оно все вместе кушало не более твоего объема памяти, и еще чтобы на файловый кеш хватало.

Вторая часть кто виноват в том, что не перезапускается mariadb (ибо должна).

Можно настроить в systemd юните, но это такое, mariadb просто так не падает

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

Ужас, сколько там апачей. У тебя 1000 просмотров страниц в секунду по плану? Если да, то лучше избавиться от vps и использовать физическое железо и помощнее. Если нет, то ограничь его умеренным числом (а тебя возможно атаковали флудом что их столько наплодилось, посмотри access-log за то время). А лучше вообще выкинь апач и настрой nginx.

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

Ставлю на то, что у вас apache2 выжрал всё что было и потребовал еще

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

И почему тут не перезапускается убитый mariadb…

Я тестил на другом сервере с аналогичными хар-ками и стеком ПО (только оно чуть старее). Дав нагрузку - тоже наблюдал подобное, но там mariadb моментом рестартовала.

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

У тебя 1000 просмотров страниц в секунду по плану?

Тут нет такого не то что в планах, но и в текущей ситуации. Как-то так https://i.imgur.com/AO2mNfj.jpeg (это по одному сайту, но остальные сильно погоду не меняют )

посмотри access-log за то время

Что, придется теперь разгребать это.

SeVlad
() автор топика
Последнее исправление: SeVlad (всего исправлений: 1)
Admin