У нас есть веб-сайт, который иногда работает медленно и / или полностью зависает. Я временно установил сборщик данных о производительности системы по умолчанию в Performance Monitor, чтобы посмотреть, может ли это пролить свет.
Однако набор сборщиков данных по умолчанию собирает огромное количество счетчиков, а также создает огромные файлы журналов. Всего за 8 часов данных получилось 4 ГБ данных.
Какие счетчики производительности имеют наибольшее значение при оценке нагрузки на сервер? Кроме того, будет ли проблема производительности, если такие сборщики данных будут работать бесконечно? Очевидно, я не буду знать, когда сервер испытает снижение производительности, поэтому мне нужны журналы, чтобы я мог их проверить. Приветствуются любые другие конкретные рекомендации по производительности сервера мониторинга.
ОС - это Windows Server 2008 R2 (Web Edition).
Какие счетчики производительности имеют наибольшее значение при оценке нагрузки на сервер?
Почти все из них, но вам, вероятно, следует начать с CPU%, частных рабочих наборов и IOPS.
Будет ли проблема производительности, если такие сборщики данных будут работать бесконечно?
Да, в основном ввод-вывод, память, процессор, дисковое пространство. В основном в таком порядке.
Я не буду знать, когда на сервере снизится производительность, поэтому мне нужны там журналы, чтобы я мог их проверить.
Теперь вы куда-то идете. Вам нужно сделать короткое анализ причин.
Перед тем, как вы это сделаете, реплика вашей производственной среды (вашей тестовой среды) должна быть протестирована, подвергнута пыткам, уничтожена, а затем подвергнута вскрытию, чтобы вам никогда не пришлось испытать это в производственной среде.
Производительность может означать миллиард разных вещей. Вы устанавливаете планку плохой или хорошей производительности, и это зависит от ваших услуг и ваших соглашений об уровне обслуживания. MS имеет очень хороший документ о счетчиках производительности
Если вы не знаете, что вызывает проблемы с производительностью, вы можете начать с изоляции своих сервисов и отладки их по очереди. У вас есть веб-сервер? Сначала проверьте свой процессор. Вы запускаете базу данных, проверяете количество операций ввода-вывода в секунду и так далее.
Очевидно, я не буду знать, когда на сервере снизится производительность, поэтому мне нужны журналы там, чтобы я мог их проверить.
Как правило, вам необходимо иметь как минимум следующий триплет: мониторинг, оповещение и агрегирование журналов.
Счетчики производительности работают отлично, но предлагают только последнее. Вот почему вам нужны оповещения (например, Nagios) с постоянным мониторингом (например, cacti, munin).
Я бы зарегистрировал как минимум следующие значения:
Если сервер работает медленно, проверьте эти значения и посмотрите, какое из них является проблемой. Если это диск, проверьте зафиксированные байты, чтобы увидеть, могла ли активность диска быть вызвана нехваткой оперативной памяти.
К сожалению, это не обнаружит переходные большие требования к ОЗУ, если вы не войдете в систему с очень маленьким интервалом. Лучшим показателем для этого является пиковая комиссия за принятие, но она не отображается через счетчики производительности.