У меня есть собственное серверное приложение, работающее в Windows 2008 R2. Это домашняя служба Windows, написанная на .Net и поддерживающая ряд специализированных терминалов. У меня есть тестовая машина со спецификациями, аналогичными живому серверу, и у меня есть набор имитаторов клиентов, которые я могу использовать для создания нагрузки, которая является разумным приближением к реальной системе. Мне нужно поддерживать 12 000 из них, и в настоящее время серверу не хватает памяти (пейджинг идет через крышу).
Мой план состоял в том, чтобы запустить только 100 симуляторов, измерить использование памяти, затем снова запустить еще 100 измерений памяти и повторять, пока не начнется разбиение на страницы (на самом деле я буду брать более трех точек данных). Это должно дать мне цифру для объем дополнительной памяти, необходимой для 100 симуляторов, и позволяет мне спрогнозировать, сколько памяти требуется. Мне нужно только приблизительное представление +/- 30 ГБ, чтобы не покупать полные 2 ТБ (на сумму 150 000 долларов), которые займет сервер. Мой вопрос в том, является ли этот метод разумным для использования, и если да, то какие счетчики производительности вы бы отслеживали, чтобы определить объем фактически используемой памяти?
Я специально говорю здесь о памяти, поскольку меня смущает разница между рабочим набором, частными байтами, выделенным, общим, виртуальным и всеми другими терминами памяти. Я думаю, что смогу контролировать процессор, ввод-вывод и сеть самостоятельно. Еще я заметил, что .Net Cache регулирует использование памяти в зависимости от того, что доступно, что затрудняет выявление тенденции.
Честно? я НЕ.
Когда я определяю сервер, который будет видеть любую реальную рабочую нагрузку, я втисну столько ОЗУ, сколько смогу разумно себе позволить (системы с большей вероятностью будут ограничены ОЗУ, чем ЦП или диском - единственное другое гарантированное узкое место - это внешняя сторона автобус).
Если вы хотите выяснить, сколько оперативной памяти ваше приложение может использовать базовый нагрузочный тест, как вы предложили, это хорошее начало, но если вы уже иметь эта система находится в производстве (похоже, что вы это делаете), и ваша производственная система меняет местами, ваша задача проще: Выясните, сколько места подкачки вы используете -> Добавьте как минимум вдвое больше оперативной памяти (округлите в большую сторону, чтобы соответствовать ограничениям размера DIMM вашей системы).
Если вы выполняете нагрузочный тест, чтобы получить приблизительные цифры и экстраполировать их, не забудьте учесть несколько вещей:
Кривая памяти, вероятно, будет состоять из двух отдельных сегментов.
(начальное резкое увеличение по мере кэширования фреймворков / общих библиотек, затем немного менее крутая кривая, поскольку каждый новый код приложения, не предназначенный для совместного использования, помещается в память)
Вам по-прежнему требуется свободная оперативная память для кэширования диска и общей библиотеки, а также для ОС.
(Это должно быть как минимум на несколько гигов больше, чем нужно вашему приложению)
ВСЕ программное обеспечение дает утечку памяти (по крайней мере, все практическое программное обеспечение), поэтому следите за этим при тестировании и убедитесь, что у вас есть место для устранения утечки.
Ваша нагрузка, вероятно, увеличится в течение срока службы сервера. Планируйте соответственно.
(Если у вас нет точных показателей планирования мощности, удвойте сегодняшнюю рабочую нагрузку и запланируйте ее).
Покупка слишком большого количества оперативной памяти сегодня дешевле, чем отказ вашей среды завтра.
Спасибо, обновление хотя бы всем дает понять. То, что вы планируете использовать 2 ТБ памяти, означает, что вы играете не так, как обычные настройки. Большая система. Ненавижу думать о том, сколько тепла это будет выходить.
Учитывая, что это внутренний серверный процесс и у вас заканчивается память (вы не говорите, на каком уровне вы начинаете пейджинг), но я бы хотел исключить возможность того, что серверный процесс потребляет все большие объемы памяти, прежде чем что-либо дальше. Если это происходит, не имеет значения, что вы делаете, в какой-то момент система остановится.
Я не знаю каких-либо общих инструментов, которые вы могли бы использовать, чтобы дать вам гораздо больше, чем базовый обзор того, что происходит ... что поставляется с окнами. Сам процесс обслуживания - это черный ящик, и ваша команда разработчиков должна предоставить инструменты для мониторинга.
Быстрый расчет обратного конверта:
2Tb of memory = 1024Gb = 1024*1024Mb = 1048576Mb
1048576Mb / 13000 connections = around 80mb per session
Это не выходит за рамки обычного рабочего набора .net exe.
Есть ли у службы несколько потоков? Если они запускают поток для каждого соединения, стоит посмотреть, как они это делают. ProcExp.exe от Microsoft - это простой способ узнать, есть ли у вас несколько потоков и что они используют. Он не знает о .net, но даст вам счетчики win32.
Можете ли вы указать, сколько памяти и сколько подключений было у вас при тестировании до начала разбиения по страницам?
Итак, как определить, есть ли у серверного процесса проблемы с утечкой памяти? Он может накапливать больше памяти с каждым подключенным сеансом, или он может накапливать память и никогда не освобождать ее.
Что вы можете сделать, так это выбрать количество сеансов, которое не вызывает пейджинг, и имитировать это количество подключений. - Запустите моделирование в течение нескольких часов и используйте perfmon для просмотра основных счетчиков памяти. - Повторите эти тесты с сеансами, которые на короткое время подключаются и отключаются.
Идея состоит в том, чтобы увидеть, потребляет ли служба все больше и больше памяти с каждым сеансом, или открытые сеансы вызывают все большее использование памяти.