2.9.2. Оптимизация производительности

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

В качестве примера рассмотрим почтовый сервер. На сервере может быть размещен один каталог spool c файлами пользователей (mbox) или отдельные каталоги пользователей с файлами сообщений (maildir). Если для доступа к почте используется протокол IMAP, эффективность работы можно повысить, связав пользователя с конкретным узлом. Таким образом, запросы чтения и удаления писем будут обслуживаться из кэша на одном узле. В случае сбоя узла сеанс можно будет начать заново на другом узле.

Если же для получения почты используется SMTP, можно настроить передачу почты пользователя конкретному узлу. Если узел не подключен, сообщение будет сохранено в spool на узле получателя. Это позволяет кэшировать файлы на одном узле, но в то же время разрешает прямой доступ к почте в случае его сбоя.

Такая организация позволяет эффективно использовать кэш страниц и делает сбои прозрачными для imap и smtp.

Отдельно можно оптимизировать процесс резервного копирования, по возможности создавая копии данных напрямую с кэширующего узла. Если сценарий копирования запускается регулярно в одно и то же время, и в это же время регистрируется задержка ответа приложений, это может служить знаком неэффективного использования кэша страниц.

Если вы можете остановить работу приложения, чтобы беспрепятственно завершить резервное копирование, отлично — вас эта проблема не коснется. Но если такой возможности нет, и копирование запущено с одного узла, то после его окончания в его кэше будет находиться значительная часть содержимого файловой системы. Это существенно замедлит время ответа этого узла при обращении к нему с других узлов. Последствия можно смягчить, очистив кэш:

echo -n 3 >/proc/sys/vm/drop_caches

Но это тоже не является идеальным вариантом — лучше разрешить совместный доступ к рабочим данным в режиме чтения или обращаться к ним с одного узла.