☰

Паника из-за нехватки памяти ядра (3.2.0) (Debian 7.3), даже если вызывающий проблему процесс был завершен

tag-icon • tag-icon linux debian kernel-panic rdiff-backup outofmemoryerror
Паника из-за нехватки памяти ядра (3.2.0) (Debian 7.3), даже если вызывающий проблему процесс был завершен

При попытке создания резервной копии довольно большой папки (450 ГБ) на диске емкостью 2 ТБ, который находится на этом сервере исключительно в качестве места назначения резервной копии rdiff-backup(версия 1.2.8 - последняя помеченастабильный) вызвало панику ядра.

Система:

Linux giorgio 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux

Диски: 2 диска по 1 ТБ в режиме программного зеркального RAID, 1 диск емкостью 2 ТБ исключительно для резервного копирования.

У меня есть подозрение: память на сервере 2G RAM + 2G swap = 4G. Есть файлы размером до 16G. Возможно ли, что rdiff-backupв какой-то момент загружает весь файл в память?

В любом случае, паника ядра не должна была произойти (поскольку процесс rdiff был завершен?, значит, память должна была снова стать доступной?), поэтому, полагаю, мой вопрос состоит из двух частей: одна: о моих подозрениях, вторая: о панике ядра.

Кстати, паника началась недавно, довольно много резервных копий уже были успешными - полными и инкрементальными - и эти большие файлы в ГБ уже были там. Так что, я полагаю, это вина нового ядра Debian, а не rdiff-backup?

Раздел лог-файла на момент возникновения паникиhttp://pastebin.com/e9a5fQdh

Последнее на экране:

EDIT/Update: Я только что попытался создать файл подкачки размером 20 ГБ (с помощью dd из /dev/zero), и сервер снова ОТКЛЮЧИЛСЯ, никакой реакции на ping.

Из логов следует: похоже, что ядро ​​завершило некоторые процессы, включая тот, который, как я подозреваю, и стал причиной всего этого (rdiff-backup).но говорит "заканчиваются убиваемые процессы". Похоже, что уничтожение процессов не освободило память?

решение1

Он не уничтожил rdiff-backup, хотя должен был, но его oom_score_adjзначение -1000.

Это вызвано ошибкой в ​​sshd. Ошибка исправлена, но не будет доступна до следующего релиза, который называется openssh 6.5.

sshd не может установить oom_score_adj новых созданных им оболочек обратно на 0, если вы перезагрузите его, в результате чего все дочерние процессы, которые вы создаете через SSH (то есть ваша оболочка bash и любые дочерние процессы, которые она создает), будут иметь значение -1000 oom_score_adjи впоследствии могут занять всю память, и oom-killer не удалит их.

Самый быстрый способ исправить это (предполагая, что 7567 — это pid sshd, как в вашем случае):

  • Бегатьecho 0 >/proc/7567/oom_adj_score
  • Перезапустите sshd.

Не перезагружайте sshd, перезапустите его, пока исправление не вступит в силу. (в openssh 6.5 оно должно быть)

Об ошибке сообщается и она устраняется здесь.https://bugzilla.mindrot.org/show_bug.cgi?id=2156

Связанный контент