Замечания по производительности

Предпологается, что конфигурационная директория  /var/imap .

• /var/imap/proc - Позле успешного входа пользователя, imapd создает файл в  /var/imap/proc который является идентификатором его unix-процесса. Файл также содержит имя выбранного ящика(с пом. команды SELECT). Файл уничтожается когда пользователь закрывает сеанс(log out).

  Учитывая потенциальную нагрузку, это первый кандидат на размещение его в другом месте. Это можно осуществить, сделав символьную ссылку на другую директорию на другом разделе. Мы у себя сделали ссылку в память/виртуальную FS в памяти (у Solaris'а для этого предусмотрена tmpfs). Если вы используете файловую систему типа tmpfs, нужно быть уверенным, что есть достаточно памяти для этого.

  Некоторые люди не задумываются над этой информацией и удаляют #ifdef из кода. Наверное, мы должны будем добавить конфигурационныю опцию для этого.

• /var/imap/mailboxes.db - список почтовых ящиков - часто является "точкой соприкосновения" процессов imap, особенно, если клиенты неэффективно используют команду LIST. По этой причине лучше использовать skiplist backend оптимизированного для этих целей, в отличие от используемого по умолчанию, Berkeley DB ( --with-mboxlist-db=skiplist).

  Mika Iisakkila (mika.iisakkila@pingrid.fi) пишет: Если вы совсем заморочены этим вопросом, то можно "тюнинговать" сервер c BDB. Cyrus ничего не сможет сделать для увеличения размера кэша BDB, а по умолчанию (256 kB) он слишком маленький для крупной системы. С, примерно, 50 000 почтовми ящиками и случайными операциями на сервере, я заметил, что частота обращения к кэшу BDB примерно 70-80%. После увеличения кэша до 2M, частота обращений в кэш составила 99%, а дисковый трафик значительно убавился, т.к. большинство обераций так или иначе обращаются к диску. В результате, процессы стали заканчивать свою работу вовремя и снимать блокоровки намного бастрее, сообщения типа "DBERROR: xxx lockers" стали появляться с приемлимой частотой. Вы можете оизменить исходник (/lib/cyrusdb_db3.c, настройки комментируется) или можете поместить файл  DB_CONFIG  в /var/imap/db с соответствующими настройками. До того как опробовать данный способ обязятельно ознакомьтесь с документацией на Berkeley, обечатки или неверные параметры могут вызвать опустошение.

• /var/imap/deliverdb - Пока Вы не отключите подавление двойной поставки, при доставке каждого сообщения выставиться блокировка на базу данных и будет проводена проверка - доставлено или нет сообщение с таким же идентификатором. Если Вам требуется действительно высокая производительность при доставке, возможно, придеться запретить функцию подавления двойной доставки.

  У нас все это работает при разрешенной проверке на двойнут доставку и значительных воздействий на производительность не наблюдается.

• /var/spool/mqueue - Sendmail может довольно грубо себя вести в spool-разделе. Хорошим решением  в этом случае является вынесение этого раздела на отдельный диск. Задумайтесь об использовании LMTP и доставки с другой машины.
• Неиспользованные механизмы SASL - Если Вы только что собрали библиотеку SASL и скопировали все механизмы в /usr/lib/sasl2, imapd будет пытаться использовать их все и выделит под них некоторое количество памяти. Вообще, операционная система засвопирует неиспользованние страницы памяти, но Вы будете использовать больше своп-пространства чем это реально необходимо. Короче говоря, исследуйте /usr/lib/sasl2 и если Вы не планируете использовать какие-то механизмы то неследует их там оставлять.
• Возможно Вы захотите увеличить значение слушающей очереди при запуске master-процесса. Например, это может потребоваться если Вы увидете что счетчик очереди Listen быстро увеличивается. Например, в Solaris смотрите переменную tcpListenDrop (из netstat -sP tcp).
• Восстановление базы данных. Если перезапуск сервера занимает много времени из-за процедуры восстановления БД  cyrusdb  (это обычно случается при большом числе доставок) Вам необходимо задуматься о сокращении интервала между чекпоинтами, которые контролируются событием(event) cyrusdb  в /etc/cyrus.conf(параметр period - Прим. пер.) . Мы запускаем чекпоинты каждые 5 минут; поумолчанию он равен 30 минутам.
• Некоторые файловые системы поддеживают опцию монтирования noatime . Сервер не использует информацию atime, так что можно спокойно разрешать эту опцию.
• В зависимости от Вашей конфигурации syslog используемых значений, Cyrus может выдавать тысячи сообзений через syslog. На Linux, производительность syslog можно значительно улучшить отключив синхронизацию протоколирования (не выполнять fsync() после каждого сообщения). Добавьте "-" перед именем файла в /etc/syslog.conf, т.е. "/var/log/maillog" будет "-/var/log/maillog", тем самым завпретив вызов fsync() после каждого сообщения поступающего в логи. Если у Вас в логах очень много сообщений, то  fsync() просто "положит" ваш I/O, снизив его производительность. Обратите внимание, что если Вам не нужно детельное протоколирование обеспеченное уровнем LOG_DEBUG, то отключив регистрацию таких сообщений можно значительно уменьшить количество записей которые делает cyrus.

Вообще, не существует каго-либо единого верного решения для повышения производительности. Все зависит от железа, операционной системы, и от того, как Ваши пользователи используют систему. Сам процесс  imapd  изначально занимает в памяти примерно от 256 Kbytes до 512 Kbytes. Требования к CPU не особо кретичны, но они возрастают при шифровании imap-сессий и более частом поиске. Дисковый I/O, вероятно, является самым важным моментом и использование аппаратного RAID с write-back-кэшем будет оправдана.

И наконец, если у Вас меньше 100 интерактивных пользователей, вероятно, любое более или менее современное железо обеспечит нормальную работу. Если у Вас больше 1000 интерактивных пользователей, Вы должны уметь предсказать потребности вашей системы, позволить себе дополнительное железо, быть готовым к растущей боли, или нанять кого-то, кто сможет помочь.

Есть множество хороших статей Адриана Коккрофта(Adrian Cockcroft) по тюнингу производительности под Solaris. Зайдите на Ваш либимый поисковик и наберите его имя.