производительность постфикса со списками в main.cf

производительность постфикса со списками в main.cf

Для определения списка элементов, назначаемых различным параметрам в постфиксе, можно использовать список, разделенный запятыми, например:

relay_domains = example.com,example.net,example.org

или хэш-карта вроде этой:

relay_domains = hash:/etc/postfix/relay_domains

а затем используйте postmap для преобразования этого файла элементов «ключ-значение» в файл bdb.

У меня такой вопрос: есть ли какие-либо причины для повышения производительности использовать хэш-карту вместо простого указания списка?

решение1

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

Когда был запущен демон postfix, между этими двумя вариантами не было большой разницы, потому что:

  • При использовании main.cfpostfix анализирует файл конфигурации, сохраняет его в памяти и не проверяет файл снова, пока postfix не будет перезапущен или администратор не выдаст postfix reloadкоманду.
  • При использовании хэш-таблицы postfix анализирует таблицу, сохраняет ее в памяти И периодически проверяет, изменился ли файл. Если база данных была изменена, postfix завершит работу перед обработкой следующего клиентского запроса, чтобы новый процесс мог инициализироваться с новой базой данных.источник

Теперь, если вы хотите изменить список, то

  • После изменения main.cfследует вызвать postfix reload. Это заставит главный демон перечитать файл конфигурации и завершить дочерний процесс, чтобы он мог принять новую конфигурацию.источник
  • После изменения хэш-таблицы нет необходимости вызывать postfix reload.

Я все еще не понимаю разницу между (1) перезапуском дочернего процесса путем ручного вызова postfix reloadи (2) перезапуском дочернего процесса, вызванным изменением хэш-таблицы.

Вот некоторые знания после прочтениястраница руководств по postfix, особенно наДемоны Процессраздел. Это помогло мне понять разницу между (1) перезапуском дочернего процесса путем ручного вызова postfix reloadи (2) перезапуском дочернего процесса, вызванного хэш-таблицей, которая была изменена.

У Postfix есть главный процесс, который называетсявладелец. Он был вызван в первый раз и служил в качестве 'главной' программы. Он вызывал другие демоны, такие как smtpd, qmgr, trivial-rewrite по требованию.

Существует четыре вида постфиксных демонов

  1. Демон, который не умрет, поэтому он не будет автоматически подхватывать изменения в main.cf. Вызов postfix reloadпосле изменения конфигурации заставит процесс перечитать его. Это включает:владелец.
  2. Демон, который стал постоянным процессом, поэтому он не будет автоматически подхватывать изменения в main.cf. Вызов postfix reloadпосле изменения конфигурации заставит процесс перечитать его. Это включает:qmgr,tlsmgr,проверять.
  3. Длительный процесс, который может работать в диапазоне от одного часа до нескольких часов. Вызов postfix reloadпосле изменения конфигурации ускорит изменение конфигурации. Это включает:тривиально-переписать,подобрать,постэкран,проксикарта
  4. Коротко работающий процесс, который выполняется только ограниченное количество времени. Вызов postfix reloadне нужен, так как процесс перечитывает main.cf при повторном запуске. Это включаетSMTP-протокол,smtpd,местныйи другие процессы, помимо трех категорий, указанных выше.

Если вы используете main.cfдля хранения списков, но не вызываете postfix reload, то

  • Демоны категории 4 подхватят его сразу после возрождения процесса из-за его короткого возраста.
  • Демонам категории 3 нужно некоторое время, чтобы получить эффект
  • Демоны категории 1 и 2 никогда не перечитываются, main.cfпока вы не вызовете postfix reload:

Когда вы используете хэш-таблицу для хранения списков и вы postmapредактируете файл, то

  • Демоны категории 2,3,4 обнаружат изменения файла. Поэтому нет необходимости делать перезагрузку postfix.
  • Категория демона 1 не имеет значения параметра типа хэш. Поэтому она не оказывает никакого влияния на мастер-демон.

Заключение

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

Дополнительная информация:Postfix Performance readme

Связанный контент