Почему Debian вылетает с OOM

499
Christian Wolf

Недавно я обновил свой сервер с Debian squeeze i386 до wheezy amd64, переустановив и реконфигурировав. Кроме того, я хотел иметь возможность запускать виртуальных гостей, поэтому я также установил XEN.

Тогда у меня возникла проблема, заключающаяся в том, что время от времени OOM killer уничтожал несколько процессов на моем Dom0. Затем я перезапустил и отключил несколько служб (таких как apache2, mysql, postgresql, ...). Теперь кажется, что никакие процессы больше не разрушаются (неуверенно, поскольку это происходит не регулярно, а случайным образом). НО: если я сильно нагружу машину (доступ к зашифрованной файловой системе), активатор OOM активируется.

К сожалению, система больше не работает после возникновения проблемы. Поэтому я не могу получить доступ через ssh для расследования. Также физическое расследование через консоль в большинстве случаев зависает.

У меня есть atopдемон, работающий каждую минуту, так что я могу видеть потребление памяти и замены подкачки перед сбоем: ОЗУ составляет 1 ГБ (880 МБ) в целом (статически выделено для Dom0, без всплывающих окон) где aprox. 440 МБ это кеш. Некоторые МБ являются буферами и около 20 МБ свободны. Своп всего 25GiB и совершенно бесплатно.

Что я не понимаю: почему ядро ​​не убивает часть кеша, если требуется больше оперативной памяти. Это кеш, поэтому все, что может произойти, это проблема производительности, но система останется стабильной. Таким образом, система падает. Кроме того, почему ненужные разделы памяти, используемые другими программами, не помещаются в swap? Там должно быть достаточно места, чтобы делать то, что вы хотите.

Иногда я видел на консоли сообщение о том, что задача (jbod / raid5 или что-то подобное) блокировала (?) Более 120 секунд. Я не уверен, является ли это причиной или следствием проблемы ООМ.

Теперь мои вопросы:

  • Может ли это быть проблемой XEN?
  • Может ли это быть аппаратная проблема? RAM или HD?
  • Что я могу сделать, чтобы избежать будущих сбоев?

Изменить: я просто попытался воспроизвести ошибку. Сбой произошел, но на этот раз (я не знаю точно, были ли другие ошибки в других ситуациях) зависшей программой был xenwatch. Так что нет программы доступа к HD.

1
JBOD и RAID5 оба связаны с хранилищем. Возможно ли, что хранилище умирает (либо контроллер, либо диск (и)), система обнаруживает это и, следовательно, не будет использовать своп, даже если он должен быть доступен? Тайм-аут хранения * никогда * не является хорошим знаком. a CVn 10 лет назад 2
Всего есть 4 ГБ, и я хочу возможность обновления. Christian Wolf 10 лет назад 0
@ MichaelKjörling У меня есть 3 устройства Soft-RAID: root, PVS (оба на 3 диска) и резервная копия на 2 диска. Подкачка НЕ ​​под LVM, а физическим разделом на 3 основных дисках. У меня была проблема с одним из двух резервных дисков. Таким образом, я догадался, что это было причиной проблем. Можно ли сказать, что хранилище умерло? Christian Wolf 10 лет назад 0
Проверьте информацию SMART для ваших дисков `sudo smartctl -a / dev / sdX` terdon 10 лет назад 0
@terdon Ищете что? Есть ошибки? Есть только на дисках, которые не являются частью какого-либо RAID. Только бэкап. (см. правку в основном вопросе) Christian Wolf 10 лет назад 0
Это просто способ узнать, не умирает ли какой-либо из дисков, обслуживающих ваш своп, что может помешать его использованию. terdon 10 лет назад 0
@terdon Все диски, имеющие разделы подкачки, не сообщают об ошибках, за исключением одного в прошлом. Christian Wolf 10 лет назад 0

0 ответов на вопрос

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