Столкнулся с необычной ошибкой во время работы postfix. Ошибка не сложная, но первые признаки этой ошибки странные и вызывают вопросы. Это мешает быстро разобраться в ситуации. Расскажу обо всем подробно.
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Началось все с того, что иногда я стал на почту получать вот такие оповещения:
Transcript of session follows. Out: 220 mx.mailserver.ru ESMTP EME Postfix In: EHLO EMEserv Out: 250-mx.mailserver.ru Out: 250-PIPELINING Out: 250-SIZE 50000000 Out: 250-ETRN Out: 250-STARTTLS Out: 250-AUTH PLAIN LOGIN Out: 250-AUTH=PLAIN LOGIN Out: 250-ENHANCEDSTATUSCODES Out: 250-8BITMIME Out: 250 DSN In: AUTH LOGIN Out: 334 VXNlcrthbWU6 In: dW1qQmwtZS5ydQ== Out: 334 UGFzc3dvcmQ6 In: aXNyQXBQDpmY3OA== Out: 235 2.7.0 Authentication successful In: MAIL FROM: <> Out: 250 2.1.0 Ok In: RCPT TO: <user@mailserver.ru> Out: 250 2.1.5 Ok In: DATA Out: 354 End data with . Out: 451 4.3.0 Error: queue file write error Session aborted, reason: lost connection For other details, see the local mail logfile
Первое что пришло в голову, когда увидел такое сообщение - что-то с файловой системой или с диском. Ошибка на тему невозможности записи очереди на это намекает. Все внимательно проверил на севере, ошибок с диском не заметил.
Подобные сообщения приходили не часто, сервер при этом нормально работал, мониторинг никаких проблем не видел, тестовые письма пролетали. Когда подобные ошибки стали появляться все чаще, начал разбираться подробнее.
Сервер достаточно нагруженный, поэтому его maillog читать неудобно, но пришлось. В логе обнаружил следующие предупреждения:
warning: connect to mysql server 10.1.6.224: Too many connections Aug 30 00:03:51 mailsrv postfix/smtpd[1137]: warning: mysql:/etc/postfix/alias-mysql.cf lookup error for "user@mailserver.ru"
Тут стало все понятно. Срабатывает ограничение mysql сервера на количество параллельных запросов. Причем ошибка возникает не постоянно, а время от времени, скорее всего во время всплесков нагрузки. У меня mysql сервер это отдельная машина. Идем на этот сервер, заходим в консоль mysql и проверяем параметр max_connections. Если вы его не трогали, то по-умолчанию он будет равен 100.
Проверяем это в консоли mysql:
> show variables like "max_connections";
Я уже изменил на 200, поэтому у меня такое значение. Сделал я это следующей командой mysql:
> set global max_connections = 200;
Параметр применяется сразу же, без перезагрузки. Чтобы после перезапуска сервера, значение осталось равным 200, добавляем в my.cnf в секцию [mysqld] следующий парметр.
max_connections = 200
Для того, чтобы посмотреть количество текущих соединений, используйте следующую команду в mysql консоли:
> show full processlist;
Дальше длинный список подключений в состоянии sleep. Почему они спят и остаются висеть я не знаю. С этим как раз надо разобраться. Если кто-то знает, прошу подсказать. Пока нет времени более подробно разбираться.
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Добрый день!
Как дела, решили данную проблему?
Да, в итоге сделал, как советуют по ссылке с proxy. Нормально работает, запросов к базе стало значительно меньше и ошибок больше нет.
Отлично!
ОК, отпишите, т.к. самому интересно.
Не проверял, но идея вроде годная.
По форумам больше вопли "Ая-яй, у меня все плохо. Что делать с этой ошибкой?"
Это вроде по делу :-)
Попробовал, работает с такими настройками. Но спящих процессов все равно в БД достаточно. Пока не понял, что изменилось. Но сегодня выходной, нагрузка значительно ниже. Посмотрим, что будет в будни.
ОК, понял.
Будем посмотреть.
Здравствуйте!
Ну что, помогло?
Пока еще не проверял, но обязательно проверю, так как нужная настройка.
Добрый вечер!
Советую Вам обратить внимание на эту статью — https://cheriches.com/tips-and-tricks/2013-08-09-tip-make-postfix-use-less-sql-connections.html
Спасибо, идею понял, попробую.