@577calla

Почему на проде может диск уходить в ридонли и как отследить и проблему наиболее грамотно?

Всем привет.
Есть мощная физ тачка на Debian 11.
на ней крутится достаточно много софта:
- nginx
- mariadb
- множество инстансов гугл хрома, которые автоматически по разным сценариям тестируют расширение и связанное с ним веб-приложение, коммуницируют с машей с целью записи результатов. всеми этими хромами руководит оператор через пыху через нгинкс, пыха дергает некоторые баш скрипты, которые разбираются с запуском всей этой среды для каждого хрома.
общая схема достаточно замудреная, хромы работают через screen и через xvfb-run (т.е. не в хедлесс режиме). иногда переполняется диск - перезагрузка это решает, судя по всему хромы чем то куда-то срут, что я не до конца учитываю.
-множество небольших скриптов делающих разные штуки для управления всем этим добром, например полный килл всех работающих процессов предметной области, т.е. хромов

Проблема:
- 2-3 раза в сутки происходит нечто, из за чего диск переходит в read-only, соотв. маша крашится, сайт крашится, работа стопается. инфа при том более чем адекватная:
$ df -h:
Filesystem      Size  Used Avail Use% Mounted on
udev            189G     0  189G   0% /dev
tmpfs            38G   54M   38G   1% /run
/dev/nvme0n1p4  913G   83G  785G  10% /
tmpfs           189G  4.4M  189G   1% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/nvme0n1p2  475M   50M  397M  12% /boot
/dev/nvme0n1p1  500M  3.5M  496M   1% /boot/efi
tmpfs            38G     0   38G   0% /run/user/0

$ df -i:
Filesystem       Inodes   IUsed    IFree IUse% Mounted on
udev           49502014     381 49501633    1% /dev
tmpfs          49514813   13541 49501272    1% /run
/dev/nvme0n1p4 60858368 1793699 59064669    3% /
tmpfs          49514813      34 49514779    1% /dev/shm
tmpfs          49514813       2 49514811    1% /run/lock
/dev/nvme0n1p2   128520     343   128177    1% /boot
/dev/nvme0n1p1        0       0        0     - /boot/efi
tmpfs           9902962      20  9902942    1% /run/user/0

это не меняется никак на протяжении работы и во время сбоев особенно.

Может ли такая тема в одном из баш скриптов очищения состояния вести к подобным проблемам?
sync; echo 1 > /proc/sys/vm/drop_caches
sync; echo 2 > /proc/sys/vm/drop_caches
sync; echo 3 > /proc/sys/vm/drop_caches


как отследить? Выявить? Решить? Чем собирать и какую инфу? На что не обращаю внимание?
Из приходящего сразу на ум - заворачивать всю эту муть в контейнеры, и уже изолированно в них локализовывать проблему. однако, складывается стойкое впечатление, что это все можно решить гораздо легче, мб сам себе в ногу стреляю чем-то. Подход - полное говно, да что успел за отведенные сроки. если докер - не будет оно в сумме жрать в итоге больше ресурса, чем сейчас?
был бы рад даже общим наставлениям, всем спасибо.
  • Вопрос задан
  • 108 просмотров
Пригласить эксперта
Ваш ответ на вопрос

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

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