У нас есть машина под управлением Windows 7 Pro, на которой запущен Apache / php / postgres, обрабатывающий Ajax-запросы при постоянной нагрузке (несколько раз в секунду). На нем также работают различные другие приложения, которые выполняют много операций записи на диск.
Обычно ответы Ajax принимаются менее чем за секунду, но иногда (~ один раз в 24 часа) в течение периода до 15 секунд никакие ответы не отправляются, а затем все они отправляются в конце, то есть кажется, что сервер заблокирован для до 15 секунд. Это приводит к тайм-ауту Ajax на стороне клиента.
Это подтверждают журналы Apache и других приложений. Perfmon показывает, что различные счетчики падают до нуля / почти до нуля - активность HD, активность процессора, сетевая активность и т. Д. Httpd # 1, кажется, единственный процесс, у которого все еще есть некоторая активность процессора, хотя и уменьшенная.
Как определить причину зависания? Может ли perfmon или другой инструмент сказать мне, какой ресурс блокируется? (Подходит ли для этого «Windows Performance Toolkit» или «Process Monitor»?)
NB Apache имеет достаточно потоков, достаточное количество соединений postgres, ЦП и ОЗУ не исчерпаны, и мы пробовали параметры питания, драйверы, sfc / scannow, chkdsk / r, memtest и т. Д.
Обновление 22.03.2013, 10:26:
Спасибо за все ваши ответы. Больше информации:
Оборудование:
ОПЕРАЦИОННЫЕ СИСТЕМЫ:
Расширенные параметры производительности:
(Свойства системы> Дополнительно> Производительность> Настройки> Дополнительно)
Обновление 22.03.2013, 11:46:
Скриншот из perfmon:
http://i46.tinypic.com/fndyit.png (У меня недостаточно репутации, чтобы вставить это в пост)
Период, в течение которого сервер не отвечает, составляет 07:44:15 - 07:44:22, в то время как загрузка ЦП падает ниже 20%. (NB, это с другого сервера с более слабым процессором и старым неоптимизированным программным обеспечением - обычно процессор не такой высокий!)
Обновление 04.04.2013 16:53:
Мы нашли виновника - HDD. Всего месяц!
Как мы туда попали:
Монитор процессов подтвердил, что диск блокировал все операции записи во время инцидентов. Сначала мы попытались обновить драйверы RAID. Это улучшило ситуацию - процессор и т. Д. Не упал полностью до нуля, но диск все еще блокировался. Затем мы попытались отключить RAID - это не помогло. Мы попытались уменьшить использование диска, отключив различные журналы, и это помогло. Затем мы попытались заменить жесткий диск на другой (с более низкими характеристиками), используя образ из первого, и проблема полностью исчезла.
Так что же случилось с нашим HDD?
Мы использовали диск «Hitachi TravelStar 7k500 (вариант повышенной доступности)». Похоже, что рабочий цикл был ограничен для обеспечения «повышенной доступности» для этой модели, которая может не подходить для особо интенсивного использования диска. Согласно Resource Monitor, использование нашего диска составляет около 400 КБ / сек.
Это действительно похоже на проблему с хранилищем. Какое хранилище вы используете для файла подкачки?
В противном случае лучший инструмент, который я знаю для диагностики такого рода проблем, - это Прокмон от sysinternals (сейчас MS). Он также может выполнять длительные сеансы, но у вас должен быть способ определить точные временные рамки, когда вы столкнетесь с проблемой, в частности, если вы собираетесь использовать полный системный монитор. Если проблема не в файле подкачки, скорее всего, это позволит вам найти виновника.
Да, Perfmon может контролировать производительность практически всего. Проблема в том, что нужно знать, где искать. Значения по умолчанию - хорошая отправная точка, но для реальных проблем вам нужно немного поработать, чтобы понять это.
Предполагая локальное хранилище, проверьте PhysicalDisk \ Avg. Длина дисковой очереди в PerfMon. Если оно превышает количество шпинделей, ваша система хранения является (или) узким местом. Опишите нам и свое оборудование.
/ edit Вот и все. Длина вашей дисковой очереди довольно часто поднимается выше «2» (количество медленных шпинделей), и находится на этом уровне в течение указанного вами периода. Тогда загрузка ЦП падает, вероятно, потому, что он ожидает ввода-вывода и ничего не может сделать, поэтому он ждет.
Возможные улучшения:
Наивно перенести хранилище на большее количество и / или более быстрых дисков. Возможно, RAID 10.
Более умный - проверьте, что происходит с дисковой системой, и разделите их на разные шпиндели или на разные серверы целиком. Как правило, не требуется, чтобы веб-сайт или другие внешние интерфейсы совместно использовали слишком много ресурсов с серверной частью базы данных SQL; эти два типа процессов имеют совершенно разные характеристики производительности.
