С тех пор как я в этом году мигрировал свой крупный форум на Discourse, я периодически сталкиваюсь с сбоями: облачная виртуальная машина становится недоступна по SSH, а на виртуальной консоли появляется трассировка вызовов. Сбои происходят примерно каждые 3–6 недель без какого-либо конкретного паттерна. Изначально я запускал Discourse на Clear Linux, поскольку использовал эту ОС, чтобы выжать немного больше производительности из системы во время длительной и интенсивной миграции старого форума на Discourse. Однако я начал подозревать, что Clear Linux может быть менее стабильной из-за всех её загадочных оптимизаций производительности, поэтому примерно 6 недель назад, во время выхода Debian 12 Bookworm, я перенёс свой Discourse на Debian 12 Bookworm.
К сожалению, сегодня система на Debian впервые дала сбой. Вот последовательность событий:
Jul 22 05:00:22 kernel: BUG: kernel NULL pointer dereference, address: 0000000000000002kernel: Oops: 0000 [#1] PREEMPT SMP NOPTIkernel: CPU: 3 PID: 3235204 Comm: postmaster Not tainted 6.1.0-10-amd64 #1 Debian 6.1.37-1kernel: Voluntary context switch within RCU read-side critical section!kernel: CPU: 3 PID: 3235204 Comm: postmaster Tainted: G D 6.1.0-10-amd64 #1 Debian 6.1.37-1
journalctlпоказывает последнюю запись лога в 06:40:50. Однако ОС и Discourse продолжали работать. Последняя запись была просто стандартным шумом от агента почты в Docker-контейнере, который я запускаю на той же ВМ.- Около 08:30 я проверил, что Discourse работает нормально.
- В 08:46 в логе ошибок Discourse:
Unexpected error in Message Bus : ActiveRecord::ConnectionNotEstablished : connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: could not fork new process for connection: Cannot allocate memory - В 08:53 в логе ошибок Discourse:
Failed to process hijacked response correctly : ActiveRecord::ConnectionNotEstablished : connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: could not fork new process for connection: Cannot allocate memory - В 09:01 в логе ошибок Discourse:
Failed to handle exception in exception app middleware : ActiveRecord::StatementInvalid : PG::ObjectNotInPrerequisiteState: ERROR: lost connection to parallel worker - Последняя публикация на Discourse была в 09:17.
- В 09:22 в логе ошибок Discourse:
'Track Visit' is still running after 90 seconds on db default, this process may need to be restarted! - В 09:22 в логе ошибок Discourse:
Redis::TimeoutError (Connection timed out) - Было ещё несколько подобных записей в логах Discourse до того момента, как я заметил, что сайт недоступен, примерно в 11:20.
Когда я не смог войти через SSH, я сделал эти скриншоты из просмотрщика виртуальной консоли и выполнил принудительную перезагрузку ВМ:
Я администрирую Linux-серверы уже давно, и эта цепочка событий для меня не имеет смысла. Логи Discourse довольно явно указывают на событие нехватки памяти, а виртуальная консоль подтверждает, что один из компонентов моего Docker-агента почты на той же ВМ был убит OOM-киллером. Однако в journalctl нет никаких записей об этом действии OOM-киллера, который, по-видимому, перестал работать задолго до того, как начали отказывать другие системы. Первое событие в 05:00:22 несколько раз упоминает процесс postmaster (из PostgreSQL в контейнере приложения Discourse), но база данных не упала полностью как минимум до 09:17, когда на Discourse была успешная публикация.
В настоящее время, после работы в течение всего дня, система показывает нормальное использование памяти; обычно она находится примерно на таком уровне:
#> free -m
total used free shared buff/cache available
Mem: 7751 4965 129 1832 4773 2785
Swap: 3875 2879 996
Единственная немного необычная особенность моей конфигурации заключается в том, что пространство подкачки реализовано через Zram, а не через файл или раздел подкачки. Я использую Zram уже много лет и никогда не сталкивался с проблемами. Кроме того, я установил ВМ с нуля с помощью установочного ISO-образа Debian, чтобы иметь корневую файловую систему XFS вместо стандартной EXT4, которую используют образы Debian от облачного провайдера. Хост — Hetzner. После первоначальной установки Discourse на Clear Linux я создал другую ВМ для миграции на Debian, так что, вероятно, я сейчас нахожусь на другом узле гипервизора, и я не думаю, что это проблема оборудования. Поэтому я задаюсь вопросом: было ли это просто обычным случаем нехватки памяти или же я обнаружил пограничный случай в сочетании ядра 6.1 + Zram + XFS + KVM/virtio? Буду признателен за любые ваши соображения.
. Попробуйте по очереди отключить Zram и XFS и посмотрите, что произойдет. Zram — мой главный подозреваемый. Discourse должен работать нормально с обычным свопом и ext4. Эти оптимизации могут быть интересны, но сейчас они лишь усложняют вашу установку. Как только ваш экземпляр заработает стабильно, вы сможете добавлять их обратно по одному и проверять, где возникают проблемы.