Для определения списка элементов, назначаемых различным параметрам в постфиксе, можно использовать список, разделенный запятыми, например:
relay_domains = example.com,example.net,example.org
или хэш-карта вроде этой:
relay_domains = hash:/etc/postfix/relay_domains
а затем используйте postmap для преобразования этого файла элементов «ключ-значение» в файл bdb.
У меня такой вопрос: есть ли какие-либо причины для повышения производительности использовать хэш-карту вместо простого указания списка?
решение1
У меня нет данных или метрики, чтобы решить, имеет ли значение производительность в обоих случаях. Я попытаюсь объяснить, какой фоновый процесс включает эти два случая.
Когда был запущен демон 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 по требованию.
Существует четыре вида постфиксных демонов
- Демон, который не умрет, поэтому он не будет автоматически подхватывать изменения в main.cf. Вызов
postfix reload
после изменения конфигурации заставит процесс перечитать его. Это включает:владелец. - Демон, который стал постоянным процессом, поэтому он не будет автоматически подхватывать изменения в main.cf. Вызов
postfix reload
после изменения конфигурации заставит процесс перечитать его. Это включает:qmgr,tlsmgr,проверять. - Длительный процесс, который может работать в диапазоне от одного часа до нескольких часов. Вызов
postfix reload
после изменения конфигурации ускорит изменение конфигурации. Это включает:тривиально-переписать,подобрать,постэкран,проксикарта - Коротко работающий процесс, который выполняется только ограниченное количество времени. Вызов
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