У нас есть выделенный сервер, который мы используем для размещения веб-сайтов (наш тестовый сервер). Производительность сервера сильно ухудшилась, и нам регулярно приходится его перезагружать. Когда производительность низкая, я проверил диспетчер задач на наличие процессов и памяти, но все выглядит нормально.
Мы используем систему управления контентом, и всегда при использовании раздела администратора этой CMS мы замечаем снижение производительности, что заставляет меня думать, что это может иметь какое-то отношение к вызовам DB, которые делает CMS.
Это звучит жизнеспособно? Есть ли другие предложения о том, как я могу это проверить?
Заранее спасибо...
Как сказал TomTom, это почти наверняка показатель того, что ваша система привязана к вводу-выводу, а не к процессору. Первопричиной может быть просто увеличенная нагрузка на базу данных за вашей CMS или что-то еще, но в любом случае PerfMon имеет несколько полезных счетчиков, на которые следует обратить внимание, которые могут точно сказать вам, является ли причиной дисковая подсистема.
\ LogicalDisk \ Avg. Disk Sec / Read и \ LogicalDisk \ Avg. Disk Sec / Write
Это ваши основные значения задержки для операций ввода-вывода чтения и записи, чем меньше, тем лучше. Каждый раз, когда эти числа превышают около 15 мс, производительность сервера будет заметно снижаться.
\ LogicalDisk \ Disk Bytes / Sec и \ LogicalDisk \ Disk Reads / Sec и Это покажет вам общую пропускную способность диска. Эти скорости могут превысить максимальную емкость дисковой подсистемы либо только из-за пропускной способности, либо из-за того, что вы достигли предела операций ввода-вывода в секунду для вашего шаблона чтения / записи. Из них может быть трудно вывести что-либо существенное, если вы не на 100% уверены, что у вас есть предсказуемый шаблон ввода-вывода. На самом деле нет действительно полезного способа указать здесь какое-либо конкретное число, но если вы видите 50-100 МБ / с или более на одном диске SATA, это будет примерно так хорошо, как вы могли бы ожидать. Более быстрые серверные диски (10 КБ, 15 КБ, SSD) могут превышать это количество, а подключенное к SAN хранилище может предоставить практически все, что вы хотите, при условии, что вы достаточно заплатите. При небольшом случайном вводе-выводе (типичном для операций с БД) это число всегда будет низким и мало что скажет.
\ LogicalDisk \ Disk Writes / Sec, \ LogicalDisk \ Disk Reads / Sec и \ LogicalDisk \ Disk Transfers / sec Они сообщат вам количество дискретных операций ввода-вывода в секунду и соотношение чтения / записи. Вращающиеся диски довольно ограничены в этом отношении - диски SATA 7,2 КБ могут выдерживать около 70-80 операций ввода-вывода в секунду, диски 10 КБ увеличивают это значение до диапазона 100-150, 15 КБ будет 200+. SSD будут на порядок-два выше. Группы RAID увеличивают это довольно линейно для чтения, но записи будут иметь штраф от 2 до 5. Пакет RAID 5 с 3 дисками (со штрафом записи 4) поддерживает примерно на 25% меньше операций ввода-вывода записи, чем, например, один диск.
Если это число имеет тенденцию к увеличению, когда задержка увеличивается до опасной области (например,> 15 мс), это явный признак того, что ваши диски достигли предела количества операций ввода-вывода в секунду, независимо от указанных конкретных значений.
\ LogicalDisk \ Split IO / sec Это покажет вам, сколько запросов ввода-вывода приводит к нескольким операциям, и даст вам представление о том, насколько фрагментация влияет на активность ввода-вывода.
PhysicalDisk: Текущая длина очереди диска и PhysicalDisk: Avg. Длина дисковой очереди. Это говорит вам, сколько невыполненных операций ввода-вывода ожидают завершения на уровне физического диска. Если это значение равно 2 или больше на одном диске или превышает количество дисков в группе RAID, из которой построен диск, то вы, возможно, вставляете на диск больше операций ввода-вывода, чем он может выполнить своевременно. Существуют сценарии, в которых это не имеет большого значения, но будет настоящим убийцей для систем, которым требуется дисковый ввод-вывод с низкой задержкой (базы данных, в которых кэширование памяти не может покрыть слабые места дисков). Первое - это мгновенное считывание, поэтому беспокойтесь о нем, только если он постоянно высокий или изменяется в соответствии со счетчиком% дискового времени. Если средн. Длина очереди диска слишком велика, значит, у вас определенно проблема.
PhysicalDisk:% времени на диске % Время на диске показывает, насколько занят диск. По мере приближения к 100% вам будет сложно заставить систему делать что-либо еще, что зависит от этого диска, поскольку все дополнительные операции ввода-вывода будут, как правило, помещаться в очередь. Даже числа, значительно меньшие 100%, могут указывать на проблему, и если они высоки или растут, а длина текущей дисковой очереди велика, это явный признак нагрузки ввода-вывода, превышающей емкость дисков. На самом деле это число вычисляется странным образом и в результате может оказаться не очень полезным при анализе производительности RAID.
Эта статья в блоге Technet более подробно рассматривается некоторые из этих счетчиков и некоторые сценарии, в которых вы можете использовать их для определения проблемы и определения способов ее устранения.
Это звучит жизнеспособно?
Да.
Есть ли другие предложения о том, как я могу это проверить?
Проверка работоспособности. Обратите внимание, что производительность зависит не только от процессора. Если вы считаете, что проблема связана с базой данных, возможно, это связано с ограничением ввода-вывода - в этом случае задержка / активность диска резко возрастут. Проверьте счетчики производительности дисков. Особенно, если вы заняты вводом-выводом, ЦП будет низким, поскольку ЦП в основном не обслуживает процессы, потому что он ждет завершения ввода-вывода.
При увеличении нагрузки, как правило, базы данных требуют значительных затрат на ввод-вывод, что означает довольно много дисков. У меня есть база данных, которая сейчас использует 6 дисков со скоростью вращения 10 тыс. Об / мин и скоро будет обновлена до 8 - ТОЛЬКО для данных. Типичный дешевый выделенный сервер часто имеет действительно дрянные бюджеты ввода-вывода - медленные большие диски конечного пользователя, некоторые из которых не являются быстрой подсистемой. Это работает довольно хорошо в некоторых сценариях, но в конце может быть перегружено.
Стоит ли рассматривать настройку пула веб-приложений для частого повторного использования рабочих процессов?