Улучшение производительности exim: монтирование очереди сообщений на RAMdisk

Рамдиск: последствия

• Использование виртуального диска полезно только тогда, когда ваше приложение привязано к вводу-выводу, особенно к вашему жесткому диску. Если вы не отправляете тысячи сообщений по быстрому оптоволоконному каналу, есть вероятность, что основным ограничителем является скорость вашего интернет-соединения, а не скорость вашего жесткого диска.
• Exim уже очень хорошо справляется с большими очередями на "медленных" носителях, таких как жесткие диски; просто установите split_spool_directory в файле конфигурации, и exim будет обрабатывать большие очереди более эффективно, разбивая сообщения на подкаталоги, а не на один каталог спулинга.
• Буферизация сообщений на виртуальном диске создает риск потери всей очереди в случае перезагрузки или отключения питания без возможности восстановления очереди.
• Каталог спулинга может стать довольно большим, и вы рискуете нехватить места в разделе ramdisk очень быстро. Несколько писем с большими вложениями могут легко заполнить даже значительный виртуальный диск. Точно так же сообщения, которые не могут быть доставлены, немедленно помещаются в очередь до тех пор, пока они не будут успешно доставлены, удалены вручную или не истекли exim, хотя это настраиваемый параметр в файле конфигурации exim.

Ramdisk: настройка виртуального диска

Многие дистрибутивы Linux уже имеют некоторые предварительно настроенные, но неиспользуемые диски. Выполните следующую команду, чтобы получить список ваших текущих виртуальных дисков:

ls /dev/ram*

Чтобы увидеть распределение размера, используйте fdisk стандартным образом: (где X это номер вашего виртуального диска)

fdisk -l /dev/ramX

Возможно, вы захотите увеличить выделение пространства по умолчанию. Поскольку размер ramdisk контролируется ядром, вам нужно установить опцию ядра, чтобы увеличить выделенное пространство. Если ваш загрузчик GRUB, вы можете отредактировать grub.conf файл и добавить ramdisk_size опция ядра. Ваш конфигурационный файл GRUB должен выглядеть примерно так: (в этом примере мы устанавливаем размер виртуального диска равным 256 МБ)

default 0
timeout 5
hiddenmenu
splashimage=(hd0,1)/boot/grub/splash.xpm.gz

title=Gentoo Gateway Server
root (hd0,1)
kernel /boot/vmlinuz root=/dev/sda2 ramdisk_size=256000

После перезагрузки ваши новые виртуальные диски должны отражать обновленное распределение пространства. Поскольку нет смысла форматировать виртуальный диск с журнализированной файловой системой, мы просто будем использовать ext2:

mke2fs -m 0 /dev/ram0

-m 0 опция не позволяет mke2fs резервировать любое пространство в файловой системе для пользователя root. Теперь вы можете создать точку монтирования для виртуального диска, смонтировать его и начать использовать.

mkdir /mnt/ramdisk
mount /dev/ram0 /mnt/ramdisk
df -h /dev/ram0

Кроме того, убедитесь, что у вас установлены правильные разрешения для точки монтирования (замените имя пользователя и имя группы на правильную группу и пользователя для вашей системы):

chown -R username:groupname /mnt/ramdisk

Теперь вы можете использовать этот раздел, как если бы это был стандартный раздел жесткого диска. Обратите внимание, что если вы размонтируете раздел, ваши данные не будут потеряны, а оперативная память не будет освобождена, поскольку ядро ​​постоянно выделяет необходимое пространство до перезагрузки.

Чтобы автоматизировать эту процедуру, добавьте следующее в ваш /etc/rc.local сценарий:

/sbin/mke2fs -q -m 0 /dev/ram0
/bin/mount /dev/ram0 /mnt/ramdisk
/bin/chown username:groupname /mnt/ramdisk
/bin/chmod 0750 /mnt/ramdisk

Ramdisk: конфигурация exim

Вы можете сделать монтирование связывания так, чтобы exim продолжал писать в его стандартный каталог спулинга. Для этого добавьте следующую строку в ваш /etc/fstab файл:

/mnt/ramdisk        /var/spool/exim        none        bind        0 0

Кроме того, вы можете просто указать Exim на точку монтирования ramdisk. Для этого вам необходимо установить следующее в exim.conf файл:

spool_directory = /mnt/ramdisk

Очевидно, вы бы сделали только один из вышеупомянутых, а не оба.

Лучшее решение: tmpfs

Вместо использования ramdisk лучше использовать tmpfs, поддерживаемый ядром Linux 2.4 и выше. Преимущество использования tmpfs заключается в том, что память распределяется динамически, что делает ее гораздо более гибким решением, чем виртуальные диски. Кроме того, если в вашем разделе tmpfs не хватает места, ядро ​​автоматически начнет выгружать данные на жесткий диск, тогда как решение ramdisk просто приведет к тому, что exim остановит обработку сообщений и вылетит.

Используя tmpfs, вам не нужно будет выполнять какие-либо шаги, необходимые для вышеупомянутого решения ramdisk. Для успешной настройки tmpfs необходимы следующие шаги:

Создайте точку монтирования и установите правильные разрешения:

mkdir /mnt/tmpfs
chown -R username:groupname /mnt/tmpfs

Далее откройте свой /etc/fstab файл и установите раздел tmpfs, который будет создан и смонтирован при загрузке:

#<fs>        <mountpoint>        <type>       <opts>                             <dump/pass>
tmpfs        /mnt/tmpfs          tmpfs        size=1G,nr_inodes=10k,mode=0700    0 0

Это создаст 1GB раздел tmpfs с 10'000 инодами. Конфигурация exim такая же, как и при создании виртуального диска - либо скажите exim, что местоположение нового каталога спула находится по адресу /mnt/tmpfs или привяжите существующий каталог очереди к /mnt/tmpfs точка крепления. В качестве альтернативы, вы можете просто смонтировать раздел tmpfs в существующий каталог спула exim с самого начала - так что вместо вышеуказанных изменений /etc/fstab файл, используйте эту строку вместо:

#<fs>        <mountpoint>        <type>       <opts>                             <dump/pass>
tmpfs        /var/spool/exim     tmpfs        size=1G,nr_inodes=10k,mode=0700    0 0

На этом сайте есть хорошая статья, объясняющая tmpfs и ramdisk, а также различия между ними.

Я бы просто использовал / dev / shm, который по умолчанию уже смонтирован в большинстве современных дистрибутивов Linux.

vz1:~# df -h /dev/shm
Filesystem            Size  Used Avail Use% Mounted on
tmpfs                  12G     0   12G   0% /dev/shm

vz1:~# mount |grep shm
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)

vz1:/dev/shm# dd if=/dev/zero of=5gb.dat bs=1M count=5000 conv=fsync
5000+0 records in
5000+0 records out
5242880000 bytes (5.2 GB) copied, 7.36568 s, 712 MB/s


vz1:/dev/shm# time dd if=5gb.dat of=/dev/null bs=1M
5000+0 records in
5000+0 records out
5242880000 bytes (5.2 GB) copied, 2.70614 s, 1.9 GB/s

Просто убедитесь, что вы контролируете это; заполнить его может быть плохо.

А затем просто обновите скрипт запуска exim init.d, чтобы переместить каталоги / var spool в / dev / shm / куда-нибудь.

Вы можете использовать tmpfs и смонтировать виртуальный диск, это не сложно.

есть это сообщение в блоге, в котором подробно описываются создание tmpfs и изменение сценария запуска exim, чтобы сделать его немного более устойчивым.

Как уже говорилось, размещение каталога спулинга в оперативной памяти tempfs рискованно, поскольку вы можете потерять все электронные письма в очереди, если сервер выйдет из строя. Я получил очень хорошее представление, разместив /var/spool/exim/input а также /var/spool/exim/msglog каталоги на SSD-накопителе (более 60000 отправленных писем в час на дешевом настольном оборудовании).

/var/spool/exim/db каталог может быть предпочтительно размещен на виртуальном диске (символическая ссылка, что каталог на /dev/shm - самый простой способ), так как потеря подсказок при повторных попытках не является фатальной.

Также факт, что exim будет очень плохо работать, если у вас в очереди будет несколько тысяч писем или больше, поскольку процессы, выполняющие очереди, будут тратить пропорционально больше времени, спотыкаясь друг на друга и изучая блокировки, чем фактически доставляя электронные письма. Быстрые диски (SSD или ram-based), безусловно, помогают, но держать короткую очередь всегда лучше!

Прежде чем продолжить, составьте сообщение, которое вы будете отправлять пользователям, обнаруженным при разборе журнала почтового сервера, информируя их о том, что ваш сервер только что потерял их сообщение из-за отключения питания / перезагрузки / сбоя / отключения человека по кабелю питания.

Почтовые серверы очень серьезно относятся к гарантиям сохранения данных. Они прилагают большие усилия, чтобы убедиться, что, когда они возьмут на себя ответственность за почту пользователя, это сообщение будет защищено на диске и будет переживать сбой / перезагрузку или любое другое событие, которое стирает содержимое оперативной памяти системы. Вы убедитесь, что их усилия будут напрасны. Вы уверены, что хотите это сделать?

Вы потеряете данные пользователя через множество сценариев здесь, включая чистую перезагрузку или выключение компьютера. Пожалуйста, ищите другие идеи по настройке производительности почтового сервера.