Несколько недель назад я получил 3 VPS-машины (KVM) от провайдера, и 2 из них вышли из строя через неделю (в случайное / разное время). Все они имели 512 МБ оперативной памяти (с 512 МБ подкачки).
Один из них фактически был выключен и имел ярлык «офлайн» в админ-панели провайдера, а другой был немного заморожен, на панели отображалось «Онлайн», но я не мог получить доступ к ssh или доступ к нему через веб-консоль.
Никто из них не выполнял каких-либо задач, интенсивно использующих процессор / память. Один из них был просто сервером openvpn (с 2-3 пользователями), а другой - просто nginx + php, обслуживающий статический сайт. У них обоих всегда было около 200-300 доступной памяти, а загрузка процессора была ниже 10%.
У меня был установлен мониторинг Netdata. Так что у меня была история почти всего. Я посмотрел каждый график и график прямо перед сбоем. Не было резкого скачка или внезапного увеличения использования CPU / Memory / Disk / Network / Process / Firewall.
Я посмотрел каждый лог-файл в /var/logs/
. Я читаю их построчно (до сбоя). Я также использовал journalctl
. Не было ни ошибок, ни предупреждений, ни нехватки памяти, ни процесса уничтожения, а просто обычных событий.
Оба сервера, которые потерпели крах, имели syslog
, который выглядел так:
Как вы можете видеть, ufw просто блокирует случайных спамеров прямо перед сбой, а затем нет журнала. Кроме того, загрузка, которую вы видите в 20:41:02
, является принудительной / принудительной перезагрузкой, которую мы сделали после сбоя, просто чтобы вернуть систему в рабочее состояние.
Когда я спросил поставщика, они сказали, что все выглядит хорошо на их стороне, и причина, по которой мои серверы рухнули, была в том, что 512 МБ ОЗУ было слишком мало, и мне пришлось обновить.
Кроме того, есть 2 вещи, которые я случайно прочитал в Интернете, и я подумал, что спрашиваю здесь, являются ли они реальной вещью.
journal_data_writeback
, что если он включен, система может пропустить запись журналов на диск во время сбоя . После говорящий guiverc в комментариях, я понял, что мне на самом деле нужно было назвать пакет linux-crashdump
. Но потому что сервер был установлен с помощью минимального шаблона Ubuntu, Он не произвел файлов журнала во время катастрофического отказа. Вот почему я ничего не мог найти.
Для любого, кто исследует их причину катастрофического отказа и задается вопросом, почему нет никаких файлов журнала в /var/crash
, удостоверьтесь, что Вы устанавливаете linux-crashdump
так, надо надеяться, в следующий раз у Вас может быть что-то для взгляда на ;)