>Стабильность в том, что запущенный через тспсервер того же автора (правда с
>патчами) переживает такие проблемы как нехватка памяти, дискового пространства, достижение лимита
>максимального количества клиентов, т.е. после освобождения ресурсов возобновляет обслуживание, а это
>- главное.
Никогда не замечал такой проблемы у postfix. Замечу что в нем имеется аналогичный алгоритм.>Не факт. В среднем образ процесса qmail-smtpd, обрабатывающего одну рассылку (кстати один
>процесс может обслужить поочередно несколько писем), имеет размер порядка 900КБ (в
>основном зависит от ОС, может быть немногим больше или меньше), т.е
>для обслуживания 900 одновременных рассылок нужно 900МБ - неплохой показатель. У
>обычных ИСП среднего размера (50000 почтовых ящиков) выше 2000 не поднимается,
>да и то в пиках и если есть новостные engines. Правда,
>это моё наблюдение. Если нужно больше, используют несколько машин (независимо от
>типа МТА).
Я говорил об накладных расходах на запуск процесса, а не на память. А их много. Количество используемой памяти зависит от методик обработки. И в целом будет кореллировать с объемом трафика обрабатываемым почтовым сервером.
>У qmail эти процессы запускают не одновременно, а один из другого
накладные расходы от этого не уменьшаются.
>1. У postfix примерно такая же структура mail delivery как у qmail
>в плане распределения задач между демонами и дочерние процессы точно также
>запускаются и завершаются.
Не верно. Демоны выгружаются только при условии не возможности использовать повторно. В случае с qmail это происходит всегда.
>2. В большинстве современных ОС существуют технологии, сокращающие расходы на создание\завершение процессов.
Это какие ? В использование потоков я бы еще поверил, но они не используются qmail.
>3. Для подъема производительности нужна система распределенных вычислений (кластер).
>У меня в данное время интенсивно тестируется qmail HA-agent для Sun Cluster
>3.0 (один из наиболее удачных кластерных решений, правда действует только под
>Solaris).
А другое что-то пробовали? Или вам проще собрать кластер?
>Zero administration - это полное отсутствие необходимости каких-либо действий со стороны обслуживающего
>персонала для поддержания работоспособности ПО (автоматизм обслуживания).
Любой грамотно настроенный MTA попадает в эту категорию.
>Система конфигурации состоит из ряда файлов, имя которых означают опцию, а содержимое
>- значение опции. Практически отсутствует необходимость в разборе формата конфигурационного файла.
Теперь нечитаемость конфиурационного файла преподносится как удобство?
>Более того, все изменения в них вступают в силу после их
>сохранения, без необходимости уведомления демонов об изменениях.
Вот за этим и нужен простой формат. Хотя проще было бы держать конфигурацию в памяти. Но к сожалению это было не достаточно параноидально. В случае postfix достаточно запустить postfix reload. Все же стоит тратить ресурсы менее расточительно? Тем более что так уж часто меняется конфигурация.
>А использования конфигурации в
>формате cdb позволяет использовать очень большие (до 4 ГБ) конфигурационные файлы
>(в которых например может держаться база по антиспаму).
А зачем ? Особенно в cdb это держать. Да и такое умеет postfix.
> И производительность при этом не теряется: например, чтобы определить отсутствие записи в базе необходимо только 2 вызова write(). Что здесь дебильного?
Теряется за счет запуска кучи процессов для обработки одного письма. Причем все они это делают. В независимости от легковестности вызовов если процессов много это грузит машину.
>
>Насчет нарушения FHS - так это в инсталляции по умолчанию. Легко обойти.
>Во всяком случае, так очень многие и сделали.
Только вот почему по умолчанию этого не сделано? Плюс там нужен большой напильник. Без напильника и патчей qmail вещь убогая. Кроме этого никто не гарантирует, что не вносят уязвимости. А функционал и удобство аналогичное postfix из qmail можно получить только наложив много патчей.
>Что Вы понимаете под большими программами?
Любая программа которая перед ее написанием требует проектирования и ее код больше 7 страниц.
>Под словом "удобный стиль" понимается хорошая читабельность кода независимо от размеров проекта
Тут необыло слова удобный стиль. Тут было слово "авторский стиль". Авторский стиль и стиль принятый в проекте это две разные вещи. К примеру посмотрите требования к стилю при написании патчей к ядру.
>независимость от большинства системных библиотек (реализованы собственные библиотечные интерфейсы)
интересно только в параноидальных случаях, это кстати ухудшает мобильность.
>хорошая защищенность кода от несемантических ошибок программирования (почти все проблемы >выявляются сразу на этапе проверки инвариантности алгоритма, если алгоритм удовлетворяет >поставленной спецификации задачи, значит код фактически работоспособен в силу того, что >все необходимые проверки типа buffer overflow уже произведены).
Извините какое отношение может быть между защищенностью кода и алгоритмом? Связь конечно есть но это уязвимость есть проблема алгоритма и гараздо реже самого кода.
PS Да и последнее скажите мне в каком из *nix используется qmail в качестве почтовика по умолчанию ? Я вот что-то такого не знаю. Обычно используют или sendmail или postfix или exim.
