Приветствую вас, эксперты!
Система: стандартная установка gentoo с постфиксом.
Прошлой ночью я был в процессе большой миграции электронной почты с использованием IMAP (куча сценариев Perl), когда новый почтовый сервер перестал отвечать. Однако мои SSH-соединения все еще работают и не разорвутся. Новые соединения зависают (до аутентификации), но не истекло время ожидания.
Значит ли это, что со временем он выздоровеет? Или мне нужно перезагрузить сервер?
Требуется перезагрузка. В ожидании этого ничего не произошло.
В ходе дальнейшего расследования было обнаружено, что в используемой библиотеке Perl IMAP произошла утечка памяти. Первоначально я настроил Perl-скрипт для загрузки всех учетных записей электронной почты в массив (из текстового файла, на который ссылается аргумент 1 в командной строке), а затем перебрал их, запустив код миграции для каждой учетной записи. Для каждой итерации цикла сценарий входил в систему как на исходном почтовом сервере, так и на целевом почтовом сервере, запускал код миграции, а затем выходил из системы на обоих почтовых серверах. Это в конечном итоге съело всю доступную RAM, затем весь доступный SWAP, пока, наконец, init убил процесс.
Я думал, что ускорю: я использовал screen для запуска 9 из этих процессов, каждый для разных учетных записей. После запуска девяти из этих процессов система быстро замедлилась до сканирования, а затем перестала отвечать на запросы. я догадываюсь init имел бы в конце концов убил все процессы Perl, но сколько времени это займет? Таким образом, потребовалась перезагрузка.
Я изменил свой сценарий миграции Perl для создания одной учетной записи, а затем вышел. Затем я настроил цикл bash, подобный этому, чтобы просмотреть все учетные записи, полученные из одного и того же текстового файла:
# cat run_migration4.sh
#!/bin/bash
FILE=$1
# read $FILE using the file descriptors
exec 3<&0
exec 0<$FILE
while read line
do
# use $line variable to process line
echo line: $line
./migration4.pl $line
done
exec 0<&3
Это сработало очень хорошо. Мне удалось запустить девять из них за один сеанс экрана, и все они занимали незначительный объем оперативной памяти, что не могло быть близко к пределу сервера 4G. Средняя загрузка сервера никогда не превышала 2 или 3. Все прошло без проблем.
Возможно, в ядре закончилась энтропия. Это может произойти, по крайней мере, с сервером Cyrus IMAP, если он не настроен для использования / dev / urandom в качестве источника случайности, и если сервер не может сгенерировать достаточно "реальной" случайности для / dev / случайный. Ваши симптомы совпадают с теми, с которыми я столкнулся много лет назад.
Чтобы проверить, так ли это у вас, позвольте
watch -n1 'cat /proc/sys/kernel/random/entropy_avail'
или
while true; do cat /proc/sys/kernel/random/entropy_avail >>/somepath/available_entropy.txt; sleep 1; done
запустите и посмотрите, постоянно ли доступная энтропия падает до или около 0 во время зависания IMAP. В этом случае программное обеспечение сервера IMAP ожидает новой случайности.
Один из способов увеличить энтропию - установить rngd, в случае Gentoo это означает Emerge rng-tools а затем запустить rngd (Демон сбора случайных чисел). Он переносит полуслучайность из / dev / urandom в / dev / random, если реальная случайность слишком мала.
Обязательное предупреждение: в сверхзащищенной среде это не то, что вам нужно.