форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Postfix оптимизация"
Сообщение от Vladp on 30-Окт-03, 17:09  (MSK)
FreeBSD 4. Pentium-III667 / 384 Mb Почтовый сервер Postfix. В Postfix настроено еще 2 обрабатывальщика писем. т.е. основоной, затем некоторая обработка (1), а потом еще Spamassassin(2). В некотором будущем хочу прикрутить проверку на вирусы. Иногда производится некоторая рассылка. Одно письмо, а в нем 200-1000 адресов. При его получениии сервер создает по 1 письму на каждого. И иногда при этом приходят мне письма от MAILER-DAEMON примерно следующего содержания. Transcript of session follows. Out: 220 localhost mail server-ok In:  EHLO localhost.localdomain Out: 250-localhost Out: 250-PIPELINING Out: 250-SIZE 10240000 Out: 250-VRFY Out: 250-ETRN Out: 250-AUTH LOGIN PLAIN Out: 250-AUTH=LOGIN PLAIN Out: 250-XVERP Out: 250 8BITMIME In:  EHLO mailfilter Out: 250-localhost Out: 250-PIPELINING Out: 250-SIZE 10240000 Out: 250-VRFY Out: 250-ETRN Out: 250-AUTH LOGIN PLAIN Out: 250-AUTH=LOGIN PLAIN Out: 250-XVERP Out: 250 8BITMIME In:  MAIL FROM:<user1@domain> Out: 250 Ok In:  RCPT TO:<user2@domain> Out: 250 Ok In:  DATA Out: 354 End data with <CR><LF>.<CR><LF> Out: 451 Error: queue file write error In:  QUIT Out: 221 Bye При этом есть подозрение, что эти письма не доходят. В какую сторону копать?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "Postfix оптимизация"
Сообщение от Vladp on 31-Окт-03, 14:10  (MSK)
Так что, никто ничего не знает? Или у всех все прекрасно работает на конфигурации по умолчанию?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "Postfix оптимизация"
Сообщение от Mikhail on 31-Окт-03, 14:24  (MSK)
>Out: 451 Error: queue file write error - перевести? Такое происходит только с письмами из этой рассылки, или еще бывает? Чем отличаются письма ,из-за которых происходит ошибка, от других? Места на диске хватает (Pentium-III667 / 384 Mb - это все?)? debug_peer_level увеличь, отправь письмо(а) большого объема, что скажет?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "Postfix оптимизация"
	Сообщение от Vladp on 31-Окт-03, 14:44  (MSK)
	>>Out: 451 Error: queue file write error >- перевести? >Такое происходит только с письмами из этой рассылки, или еще бывает? Чем >отличаются письма ,из-за которых происходит ошибка, от других? Места на диске >хватает (Pentium-III667 / 384 Mb - это все?)? >debug_peer_level увеличь, отправь письмо(а) большого объема, что скажет? /var свободно 150 метров /var/mail свободно 1700 метров В /tmp почти гиг свободно, в своп при этом нелезет. Есть 2 рассылки. одна на примерно адресов 500. Письма до 1500 байт. и другая на 200 адресов по примерно 70 к. Вроде как места должно хватать. Это происходит с разными письмами, но в момент, когда постфикс разгребает эту самую почту. Можно ли ему как-то сказать, чтобы он немного медленнее разгребал. Например поработал 2 минуты, отдохнул 5. Ну или что-то в этом роде (разбирать письма со скоростью, чтобы одновременно отправлялись не было более 50 писем) Так же есть ошибки такого плана In:  MAIL FROM:<user1@not.my.domain> Out: 250 Ok In:  RCPT TO:<user2@my.domain> Out: 451 <user2@my.domain>: Temporary lookup failure И всегда при рассылке очень сильно загружен проц. Адреса проверяются через mysql. Видимо по таймауту вылетает из-за сильной загрузки...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "Postfix оптимизация"
	Сообщение от Mikhail on 31-Окт-03, 15:39  (MSK)
	'cat <whereis>/main.cf|grep queue_directory' - у меня, например, /var/spool/postfix; тогда ему может и не хватать места. qmgr_message_recipient_limit; default_destination_concurrency_limit; default_destination_recipient_limit; smtpd_recipient_limit etc. А debug_peer_level ясности не прибавил? Сначала хотелось бы все-таки понять, на чем именно он срубается. Еще можно покопать master.cf на тему maxproc.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "Postfix оптимизация"
	Сообщение от Vladp on 31-Окт-03, 16:37  (MSK)
	>'cat <whereis>/main.cf|grep queue_directory' >- у меня, например, /var/spool/postfix; тогда ему может и не хватать места. то же самое. Расположено оно на разделе /var >qmgr_message_recipient_limit; по умолчанию 20000. Не понял что это значит. :( >default_destination_concurrency_limit; по умолчанию 20. Не понял что это значит. :( >default_destination_recipient_limit; по умолчанию 50. Тут это не имеет значения. На каждого адресата генерируется письмо, поскольку все адреса забиты в bcc >smtpd_recipient_limit etc. по умолчанию 1000. Это понял что такое. Пока устраивает. >А debug_peer_level ясности не прибавил? Сначала хотелось бы все-таки понять, на чем >именно он срубается. Так оно бывает раз в месяц. И то хорошо. Пока попросил рассылать несколько писем на мньшее кол-во адресатов с промежуткам времени. Еще не сбоило. >Еще можно покопать master.cf на тему maxproc. график построеный при помощи rrd не показвает сильного увеличения процессов. Только увеличение загрузки процессора увеличивается с 0.1 до 6-10
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "Postfix оптимизация"
	Сообщение от Mikhail on 31-Окт-03, 16:59  (MSK)
	>>'cat <whereis>/main.cf|grep queue_directory' >>- у меня, например, /var/spool/postfix; тогда ему может и не хватать места. >то же самое. Расположено оно на разделе /var Ну, так если там 150 Мб - может, и не хватает? > >>qmgr_message_recipient_limit; >по умолчанию 20000. Не понял что это значит. :( > >>default_destination_concurrency_limit; >по умолчанию 20. Не понял что это значит. :( > >>default_destination_recipient_limit; >по умолчанию 50. Тут это не имеет значения. На каждого адресата генерируется >письмо, поскольку все адреса забиты в bcc > >>smtpd_recipient_limit etc. >по умолчанию 1000. Это понял что такое. Пока устраивает. > Может, почитать <whereis>/samples/*.cf? Там много про это рассказывают. Если кратко - это разные виды ограничений: одновременных соединений, адресов TO: и т.д >>А debug_peer_level ясности не прибавил? Сначала хотелось бы все-таки понять, на чем >>именно он срубается. >Так оно бывает раз в месяц. И то хорошо. >Пока попросил рассылать несколько писем на мньшее кол-во адресатов с промежуткам времени. >Еще не сбоило. Так выставь дебаг, когда потребуется - оно уже будет записано. > >>Еще можно покопать master.cf на тему maxproc. > >график построеный при помощи rrd не показвает сильного увеличения процессов. Только увеличение >загрузки процессора увеличивается с 0.1 до 6-10
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "Postfix оптимизация"
	Сообщение от Vladp on 31-Окт-03, 17:05  (MSK)
	>>>'cat <whereis>/main.cf|grep queue_directory' >>>- у меня, например, /var/spool/postfix; тогда ему может и не хватать места. >>то же самое. Расположено оно на разделе /var >Ну, так если там 150 Мб - может, и не хватает? Если я правильно понимаю, то 150 м это для 1000 писем по 150к примерно. у меня же мксимум 1500*500=450к или 200*70к=14м. Или я неправильно считаю? >Так выставь дебаг, когда потребуется - оно уже будет записано. Видимо так и сделаю. оно все в maillog писаться будет?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "Postfix оптимизация"
	Сообщение от Mikhail on 31-Окт-03, 17:21  (MSK)
	>Если я правильно понимаю, то 150 м это для 1000 писем по 150к примерно. у меня же мксимум 1500*500=450к или 200*70к=14м. Или я неправильно считаю? Ну, отсюда сложно сказать :-) Слишком много вариантов. Если проводятся дополнительные обработки - где они и как это делают? Кто еще пользуется /var (многие...)? Сколько времени идет обработка рассылки - можно же посмотреть, что в это время происходит с дисковым пространством. Это не вопросы, а повод для раздумий. >Так оно бывает раз в месяц. И то хорошо. Можно ввечеру (ночью?) самому смоделировать ситуацию. Сначала включить дебаг, разослать почту (мониторя пространство и процессы), выключить дебаг, почитать логи.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "Postfix оптимизация"
	Сообщение от Vladp on 05-Ноя-03, 17:59  (MSK)
	Спсибо за советы... На тестовой машине была сэмулирована похожая ситуация. Что оказалось. Действительно не хватало места в спуле и при большой нагрузке не хватало 100 конекшенов (по умолчанию) к mysql серверу. То и то пришлось увеличивать. Теперь буду ждать результатов в реальной работе.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.