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

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

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

• Когда используешь main.cf, postfix анализирует файл конфигурации, сохраняет его в памяти и не проверяет файл повторно до перезапуска 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