Увеличение использования оперативной памяти для сервера IIS
Я использую крупномасштабную систему ERP на следующей конфигурации сервера. Приложение разработано с использованием AngularJS и ASP.NET 4.5
Dell PowerEdge R730 (Quad Core 2,7 ГГц, 32 ГБ ОЗУ, 5 х 500 ГБ на жестком диске, сконфигурирован RAID5) Программное обеспечение: Хост-операцией является VMWare ESXi 6.0 Две виртуальные машины работают на VMWare ESXi . Одна - Windows Server 2012 R2 с выделенной памятью 16 ГБ... он содержит сервер IIS 8 с кодом моего приложения. Другая виртуальная машина - это также Windows Server 2012 R2 с SQL Server 2012 и 16 ГБ выделенной памяти.... это просто база данных моего приложения.
Видите ли, я разделили сервер приложений и сервер базы данных в целях балансировки нагрузки.
Мое приложение содержит модуль регистрации, где ожидается, что нагрузка будет очень высокой (около 10 000 посетителей за 10 минут).
Чтобы поддержать этот объем запросов, я сделал следующее на своем сервере IIS -> увеличил очередь запросов в пуле приложений до 5000 -> включил кэширование вывода для файлов aspx -> включил статическое и динамическое сжатие на сервере IIS -> установил виртуальную память предел и частная память каждого пула приложений до 0 -> Увеличить максимальный рабочий процесс каждого пула приложений до 6
Затем я использовал gatling для запуска нагрузочного тестирования моего приложения. Я ввел 500 пользователей сразу в мой регистрационный модуль.
Тем не менее, я вижу, что только 40% / 45% моей оперативной памяти используется. Каждый рабочий процесс использует только максимальный объем 130 МБ или около того.
И Гатлинг сообщает, что около 20% моих запросов получают ошибку 403, и более 60% всех HTTP-запросов имеют время ответа более 20 секунд.
Один пользователь отправляет 380 HTTP-запросов в течение 3 минут. Общий объем передачи данных одного пользователя составляет 1,5 МБ. Я смоделировал 500 пользователей, как это.
Чего-то не хватает в настройке моего сервера? Я уже настроил код своего приложения, чтобы минимизировать утечки памяти, увеличить время ожидания и так далее.
2 ответа
Существует известная проблема с новейшим поколением серверов PowerEdge, которые используют набор сетевых чипов Broadcom. По-видимому, функция "ВМ" для сети нарушена, что приводит к ужасной задержке сети на ВМ.
Отправляйтесь в Dell и получите самую свежую прошивку и драйверы для Windows для Broadcom.
Загрузите VMWare и получите последнюю версию драйвера Broadcom
Что касается параметров рабочих процессов, для максимальной производительности следует рассмотреть возможность запуска того же числа рабочих процессов, что и узлов NUMA, так что между рабочими процессами и узлами NUMA существует сходство 1: 1. Это можно сделать, установив для AppPool "Максимальное количество рабочих процессов" значение 0. В этом параметре IIS определяет, сколько узлов NUMA доступно на оборудовании, и запускает такое же количество рабочих процессов.
Я предполагаю, что 1 предостережение к полученному вами ответу будет заключаться в том, что если ваш сервер не поддерживает NUMA / использует симметричную обработку, вы не увидите эти параметры IIS в разделе CPU, но вышеупомянутый плакат, похоже, знает немного больше, чем я про машину. Извините, у меня недостаточно репутации, чтобы добавить это в качестве комментария. Что касается IIS, вы также можете убедиться, что ваш пул приложений не использует условия повторного использования по умолчанию, и выберите для повторного использования время, например, полночь. Если у вас применены настройки корневого уровня, перезапуск пула приложений по умолчанию через 29 часов может также вызвать сборку мусора для вашего дочернего пула / вызвать задержки даже в параллельном gc, где, похоже, вы можете немного выиграть от Gcserver=true. Хотя это довольно сложно оценить.
Оптимизирован ли ваш sql-сервер для такой нагрузки? Если ваши данные не имеют первостепенного значения, вы можете сократить время выполнения за счет отложенной устойчивости, а затем оценить запросы, которые возвращают слишком много информации для типов ожидания async io. В общем, здесь недостаточно, чтобы действительно оценить оптимизацию sql, но при неправильной настройке (параметры размера / роста) вы можете получить много тайм-аутов из-за роста, фрагментации vlf и т. Д.