Я использую Windows Server 2008, работающий на виртуальной машине Hyper-V. Система работает очень плохо. Мы уверены, что это из-за нехватки памяти. Я смотрел на Как узнать, требуется ли моему Windows Server 2003 больше памяти?, и я почти уверен, что, наблюдая за вводом> 300 страниц в секунду, проблема в памяти.
Однако я задаю более широкий вопрос. Я хотел бы обратить внимание руководства на количество времени, которое тратится на ожидание этих ошибок страниц. Есть ли способ определить, сколько времени тратится на ожидание подкачки или других ресурсов? Меня особенно интересует время, потраченное интерактивными пользователями, но было бы полезно и число, включающее неинтерактивное использование.
Чтобы уточнить, чтобы это не походило на нытье:
Эта система настолько медленная, что буквально минут, пока было активно одно окно notepad.exe, чтобы активировать второе окно notepad.exe, которое уже было открыто и отображалось. Это просто активация. Производительность неплохая. Я думаю, что это означает потерю десятков человеко-часов в день.
Я ищу способ дать понять руководству, сколько времени тратится впустую. Это происходит в то время, когда у нас фактически нет десяти человеко-часов, которые нужно тратить.
Извините, я не предоставил более подробной информации.
Этот сервер используется в разработке SharePoint (WSS 3.0). Он запускает IIS 7, настроенный как минимум с одним пулом приложений на разработчика. У каждого разработчика есть одно или несколько веб-приложений, каждое из которых настроено в AppPool, назначенном этим учетным данным разработчика. Мы работаем с Visual Studio 2008 SP1 и SQL Server 2008. Данные SQL Server находятся на отдельном виртуальном диске от ОС.
Я видел в системе до 8 разработчиков одновременно. Сервер настроен на 2 ГБ ОЗУ, и в настоящее время увеличение ОЗУ не является тривиальным из-за ограничений главного компьютера. Я надеюсь, что это будет исправлено, если я смогу представить достаточно причин, чтобы исправить это, в виде: сколько времени было потрачено впустую.
Спасибо за ответы и комментарии. Я согласен с решением - загрузите SharePoint на сервер размером 4–8 ГБ и переместите SQL Server на второй с 2–4 ГБ.
Но мой вопрос больше похож: есть ли какие-нибудь счетчики производительности или инструменты, которые могут сказать мне количество время потратили на ожидание чтения и записи страницы? Что может сказать мне, сколько времени было потрачено на ожидание ввода-вывода в очереди?
Можно получить счетчики производительности, такие как «Количество вводимых страниц в секунду», но труднее сказать, какие значения этого счетчика «слишком много». Для моей цели было бы лучше, если бы были «счетчики», которые могут сказать, сколько времени тратится из-за количество страниц, вводимых в секунду.
Этот сервер используется в разработке SharePoint (WSS 3.0). На нем запущен IIS 7, настроенный как минимум с одним пулом приложений на разработчика. У каждого разработчика есть одно или несколько веб-приложений, каждое из которых настроено в AppPool, присвоенном этим учетным данным разработчика. Мы работаем с Visual Studio 2008 SP1 и SQL Server 2008. Данные SQL Server находятся на отдельном виртуальном диске от ОС.
Я видел до 8 разработчиков одновременно в системе. Сервер сконфигурирован с 2 ГБ ОЗУ, и увеличить ОЗУ в настоящее время нетривиально из-за ограничений главного компьютера. Я надеюсь, что это будет исправлено, если я смогу представить достаточно причин, чтобы исправить это, в виде: сколько времени было потрачено впустую.
Даже не глядя на требования к оборудованию SharePoint 2007, имея до 8 разработчиков с собственными пулами приложений. я предполагать этот SQL Server - это еще одна виртуальная машина, но если это одна и та же машина с Win2k8, нет никаких сомнений в том, в чем проблема.
Пулы приложений для разработки VisualStudio (версии с 2005 по 2008 год) могут легко вырасти до 150–250 МБ на каждый пул приложений в зависимости от множества факторов. 250 МБ x 8 devs = используется 2 ГБ. Не будем забывать о памяти, которая требуется самой ОС и, возможно, SQL Server. В двух словах: вам просто не хватает оперативной памяти. Загрузите оперативную память, насколько это возможно. Я не удивлюсь, если он решит большую часть «медлительности» сервера, по крайней мере, с точки зрения фона и, возможно, переднего плана.
К сведению: Microsoft рекомендует минимум 4 ГБ для серверов приложений SharePoint 2007 (ссылка на сайт) но на самом деле все, что Microsoft съедает ресурсов максимально. Теперь в том же URL-адресе упоминается минимум 2 ГБ для автономных серверов SharePoint, но если разработчики прямо работают на этом сервере со своими собственный пул приложений, ясно, что IIS съедает всю доступную память для AppPools / Sites. Не используйте минимальный рекомендуемый объем оперативной памяти. Если возможно, попробуйте удвоить, утроить, учетверять требования к оперативной памяти (если позволяет бюджет).
Редактировать: Вы упомянули, что SQL Server данные находится на отдельном виртуальном диске, но установлен ли SQL Server на том же сервере SharePoint? Сколько бесплатного хранилища доступно на сервере SharePoint? Эти дополнительные факторы могут легко потреблять ресурсы сервера, и ими нельзя пренебрегать.
Отредактировано снова: Поскольку вы упомянули (а я не прочитал), что «ОЗУ в настоящее время не является тривиальным из-за ограничений главного компьютера», Здесь только один настоящий Решение: получите новый хост-компьютер. 2 ГБ недостаточно для запуска SharePoint / SQL / IIS / любого периода. Извините, но IMHO, машина, на которой это работает, должна иметь как минимум 8 ГБ ОЗУ.
Отредактировано после редактирования OP:
Но мой вопрос больше похож: есть ли какие-либо счетчики производительности или инструменты, которые могут сказать мне количество времени, потраченного на ожидание чтения и записи страницы? Что может сказать мне, сколько времени было потрачено на ожидание ввода-вывода в очереди?
Я не сталкивался с вашей конкретной ситуацией, но есть хорошая статья (ссылка на сайт) от Microsoft TechNet по основам мониторинга показателей. Я не уверен, что время, потраченное на ожидание ввода-вывода в очереди, является Лучший способ получить то, что вы хотите (я предполагаю поддержку руководства).
Можно получить счетчики производительности, такие как «Количество вводимых страниц в секунду», но труднее сказать, какие значения этого счетчика «слишком много». Для моей цели было бы лучше, если бы существовали «счетчики», которые могут сказать, сколько времени тратится из-за ввода страниц в секунду.
Статья из Сети Windows (ссылка на сайт) на Server 2003 объясняет эти счетчики лучше, чем я. FTA:
В Память \ Страниц / сек Счетчик указывает количество операций подкачки на диск в течение интервала измерения, и это основной счетчик, за которым следует следить для индикации возможной недостаточности ОЗУ для удовлетворения потребностей вашего сервера. Хорошей идеей здесь является настроить предупреждение perfmon, которое срабатывает, когда количество страниц в секунду превышает 50 на каждый диск подкачки в вашей системе. Еще один ключевой счетчик, на который стоит обратить внимание, это Память \ Доступные байты, и если этот счетчик превышает 10% фактического объема ОЗУ на вашем компьютере, то, вероятно, у вас более чем достаточно ОЗУ, и вам не о чем беспокоиться.
Вы должны сделать две вещи с Память \ Доступные байты счетчик: создайте журнал производительности для этого счетчика и регулярно отслеживайте его, чтобы увидеть, развивается ли тенденция к снижению, и установите предупреждение, срабатывающее, если оно упадет ниже 2% установленной ОЗУ. Если тенденция к снижению все же развивается, вы можете отслеживать Процесс (экземпляр) \ Рабочий набор для каждого экземпляра процесса, чтобы определить, какой процесс потребляет все больше и больше оперативной памяти. Процесс (экземпляр) \ Рабочий набор измеряет размер рабочего набора для каждого процесса, который указывает количество выделенных страниц, которые процесс может адресовать без создания ошибки страницы. Связанный счетчик Память \ Кэш Байт, который измеряет рабочий набор для системы, т. е. количество выделенных страниц, которые потоки ядра могут адресовать без генерации ошибки страницы.
Наконец, еще один подтверждающий индикатор нехватки оперативной памяти: Память \ Ошибок перехода / сек, который измеряет, как часто повторно ссылаются на недавно обрезанную страницу в списке ожидания. Если этот счетчик начинает медленно расти с течением времени, это также может указывать на то, что вы достигли точки, когда у вас больше не хватает оперативной памяти для нормальной работы вашего сервера.
Так что я бы сказал, что это объяснение действительно касается ваших показателей и понимания того, что на самом деле они значат для вас. Монитор производительности немного сложен, особенно если вы не до конца понимаете, что означают счетчики в общей схеме вещей. Я обычно читаю о счетчиках, поскольку их «реальное» значение легко забыть.
Похоже, вам нужно начать использовать perfmon. Вы захотите установить счетчики для таких вещей, как память (доступные мегабайты (я предполагаю, что это будет около или на 0),% используемых байтов) и, возможно, некоторые мониторы дисков. Ваш жесткий диск, скорее всего, безостановочно измельчает ваш файл подкачки до максимального размера. Однако я предлагаю эти предложения только для того, чтобы вы сами могли посмотреть производительность. Ответ на проблему был в первом ответе: память. Если ваши ограничения памяти для рассматриваемого сервера составляют 2 ГБ, вам необходимо приобрести или собрать дополнительный сервер. Я не уверен, есть ли у вас лицензии для другого, но 2 ГБ памяти недостаточно для запуска SharePoint, не говоря уже о множестве других приложений / сред, которые вы используете. При этом нет ничего лучше хорошего испытания. :) Удачи!
Сервер не оптимизирован для задач переднего плана, поэтому переключение между окнами блокнота на нем не будет допустимой метрикой производительности. Вам нужно запустить Process Explorer или диспетчер задач и посмотреть там некоторую статистику, а затем, возможно, сделать некоторые счетчики производительности и посмотреть, что они вам вернут. Также изучите другие задачи, выполняемые на сервере (вы не говорите, каковы его роли, поэтому невозможно быть более конкретным).