Как работать с большими почтовыми файлами

www-128.ibm.com/developerworks/lotus/library/notes-mail-files/

We used multiple iSeries server models for the tests described in this article. These servers included 830-2349 (8-way 540 MHz), 840-2461 (8 processors enabled), 840-2461 (24 processors enabled), and i5 POWER5 520 (two-way) and 550 (four-way) models. We also tested various Domino versions, including Domino 5, 6, and 7.0 (beta) code. The recommendations included at the end of this article apply to all of these Domino releases.

Результаты
Размер почтового файла
…Большие почтовые файлы требуют больше памяти, особенно в моменты старта пользовательских сессий и обработки ошибок (отказов). Понижение размера файла улучшает производительность индексов представлений, сжатия, резервного копирования и восстановления, а также журналирования транзакций... Мы не заметили резкого повышения в «устойчивом состоянии» CPU при увеличении размеров почтового файла (по крайней мере до 2 GB) Пик CPU растет линейно с большим коэффициентом, чем «устойчивое состояние» но опять же мы видим отсутствие «скачков»… Линейная зависимость образуется, когда множество пользователей осуществляют вход в течение короткого промежутка времени (напр., в понедельник утром)… При увеличении размера файла от 500 до 1000 MB прирост нагрузки на CPU для устойчивого состояния составляет 12%, а для пикового 55%.
Управление документами в Inbox
Если Inbox содержит 100% всех документов базы, то сохранение нового письма в почтовом файле в пиковые моменты требует на 50% больше CPU, а в устойчивом состоянии на 12% больше CPU по сравнению с ситуацией, когда та же база в Inbox содержит только 25% документов.
Если Inbox содержит 5000 документов, то в устойчивом состоянии увеличение CPU для файлов размером от 400 до 1000 MB во всех случаях составляет более 5% относительно таких же файлов, содержащих 1000 документов в Inbox. В пиковом же состоянии разница составляет от 13% до 22%...
Также наблюдается впечатляющая разница во времени ответа (response time) для этих двух категорий баз – почти вдвое…
По результатам тестов мы сделали вывод, что уменьшение числа документов в Inbox улучшает время ответа сервера и уменьшает нагрузку на серверные ресурсы (CPU, память, I/O, а также время старта и обработки отказов сервером)
Индексация и поиск
Поддержка полнотекстового индекса требует дополнительно около 1% CPU, в то время как полнотекстовый поиск может сэкономить около 20%... Если поиск осуществляется часто, рекомендуется создать полнотекстовый индекс. Если индекс не создан, то сервер в момент поиска попытается создать его «на лету», что может обойтись очень дорого. Это можно отключить установкой опции FT_FLY_INDEX_OFF=1 в файле Notes.ini
Количество и размер документов
Для почтовых файлов одинакового размера выяснилось, что файлы с меньшим количеством документов относительно большого размера требуют существенно меньше ресурсов, чем файлы с большим количеством «легких» документов (малого размера)

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

Рекомендации
Самым простым способом улучшения производительности является уменьшение количества документов в Inbox.

Для пользователей
1.    Архивирование
2.    Обновление клиента Notes
3.    Дополнительные инструменты (QuickPlace, Domino Document Manager)

Для администраторов
1.    Ограничение размера почтового файла
2.    Настройки памяти (Memory tuning. Large mail files use more memory. Memory bottlenecks can cause increased CPU, disk I/O, and slower response times. For our testing on iSeries, we were able to dramatically improve Domino response times by making sure the machine pool was large enough to keep page faulting under five faults per second. This is especially significant, since the default threshold for OS/400 auto performance adjuster is 10 faults per second in the machine pool. Reducing the memory faulting in the Base pool also has a significant benefit. Use other memory tuning mechanisms as applicable to your operating systems. )
3.    Обновление сервера
4.    Обновление клиентов
5.    Полнотекстовое индексирование
6.    Пользователи на сервере (Users per server. On iSeries servers, it is common practice to run multiple Domino partitions (DPARS) within a single instance of the operating system or Logical Partition (LPAR). Generally, the number of users on a given server is determined by the backup strategy and other administrative factors, such as physical location of the users, storage requirements, time to complete maintenance tasks, and failure tolerance. In terms of performance and utilization of resources, it is usually better to consolidate onto as few DPARS as possible.)
7.    Архивирование баз
8.    Сквозной мониторинг среды Domino (не только статистика, но и производительность)
Для планировщиков систем - ??