Сервера все разные, а нагрузки парой бывают такими, что даже при самом правильном распределении баланса это не спасает.
Почтовый сервер:
Сервер занимается только почтой и ни чем другим.
Два оставшихся сервера, держат всех пользователей, это порядка 300 в online. Это превышение нормы на 214% на сервер, не отработка правил составляет 0,4% в день. (Неотработанные Scheduled, или сбой в работе).
Сервер базы данных
Собрали кластерную систему
HP BL460c G1
Мод. памяти 6 Gb
Один процессор на 6 ядер
Диски поставили самые быстрые, базу с журналом не разносили, что, на мой взгляд, было сделано не правильно, т.к это своего рода тоже нагрузка на диски. Собственно вот и весь комплекс, который держит столь серьезную нагрузку.
По почте в день приходит более 5500 обращений + в каждом письме может находиться до 5 МБ файлов (картинки). 5500 это средняя цифра только новых обращений не считая ответы на запросы и обновление информации по обращениям, скажем это еще 1000 в день. Теперь давайте посчитаем 9 часов рабочего времени это примерно 10 обращений в минуту + 4 дополнительно.
Получается такая картинка. Нагрузки на почту.
Это я не считаю, нагрузку исходящий почты, которая составляет примерно 24000 писем в день.
Почта тоже разбросана на два сервера, та же балансировка, но на почтовом сервере. Если система зависнет по вине из одного APP сервера, то мы получаем остановку всех 3 серверов по графикам, а также полную остановку всего комплекса. Причины тому могут быть очень разные, основная причина, это позволять пользователям строить свои представления в системе, а также строить сложные условия для поиска по базе.
Выходит если пользователь построит сложных запрос к базе, то в этот момент SQL получает блокировки по процессам и пока не отработает запрос клиента «Тот, кто запустил его» все 300 человек сидят и как говориться курят бамбук. Основная ошибка, которую можно допустить в данный момент, это перезапустить службу того сервера на котором вызвана блокировка. Это приведет к большим проблемам, такие как не отработка правил, не отработка шедулов, съезжание статистики И.т.п.
Один из выходов в данной ситуации это уменьшение базы данных. Или ограничение на доступ к этим данным.
Балансировку по пользователям лучше строить один к одному. Обязательно нужно учесть тот фактор, что на сервере почты порт для подключения должен быть смещен на 1 вверх, и никаких клиентских запросов к нему не должно быть. Я видел в одной организации, как у них почтовый сервер принимал почту, а также направлял всех пользователей на другие сервера. Сам при этом их не держал на себе. Данная схема приводит к тому, что этот сервер не будет справляться со своими основными обязанностями и будет пере одически зависать.
Также хотел бы добавить, что нагрузку нужно рассчитывать также по таким показателям как, доступ к дискам, вычисляемая мощность Базы данных, насколько оптимизированы все представления в системе, если на базе данных присутствуют триггеры, то по возможности их лучше переводить в JOB (Если они мешают системе). В общем, подходить к каждому комплексу нужно с понимания какие нагрузки будут использоваться.
Вот собственно и все, что хотел рассказать, про нагрузку. Общей комплекс 3 сервера App + сервер WEB, а также 2 сервера SQL + FTP Итог 7 серверов.
