У нас есть выделенный сервер, который мы используем для размещения веб-сайтов (наш тестовый сервер). Производительность сервера стала очень плохой, и нам приходится регулярно его перезапускать. Когда производительность плохая, я проверяю диспетчер задач на предмет процессов и памяти, но все выглядит нормально.
Мы используем систему управления контентом, и именно при использовании раздела администратора этой CMS мы всегда замечаем снижение производительности, что наводит меня на мысль, что это может быть связано с вызовами базы данных, которые выполняет CMS.
Это звучит жизнеспособно? Есть ли еще какие-нибудь предложения, как я могу это протестировать?
Заранее спасибо...
решение1
Звучит ли это жизнеспособно?
Да.
Есть ли еще предложения, как я могу это протестировать?
Проверка производительности. Обратите внимание, что производительность — это не только CPU. Если вы думаете, что проблема в базе данных, она может быть связана с вводом-выводом — в этом случае задержка диска/процент активности резко возрастет. Проверьте счетчики производительности диска. Особенно если у вас ограничен ввод-вывод, CPU будет работать на низком уровне, поскольку CPU в основном не обслуживает процессы, поскольку он ждет завершения ввода-вывода.
Становясь более загруженными, базы данных обычно требуют значительных бюджетов ввода-вывода, что означает довольно много дисков. У меня есть база данных, которая сейчас использует 6 дисков 10k RPM, и скоро будет обновлена до 8 - ТОЛЬКО для данных. Типичный дешевый выделенный сервер часто имеет действительно паршивые бюджеты ввода-вывода - медленные большие диски для конечного пользователя, их мало, не делают быструю подсистему. Это работает довольно хорошо в некоторых сценариях, но в конце концов может быть перегружено.
решение2
Как сказал TomTom, это почти наверняка указывает на то, что ваша система ограничена вводом-выводом, а не процессором. Первопричиной может быть просто увеличенная нагрузка на базу данных за вашей CMS или что-то еще, но в любом случае PerfMon имеет несколько полезных счетчиков, которые можно посмотреть и которые могут точно сказать, является ли причиной дисковая подсистема.
\LogicalDisk\Среднее время чтения с диска (сек) и \LogicalDisk\Среднее время записи с диска (сек)
Это ваши основные показатели задержки для операций чтения и записи ввода-вывода, чем меньше, тем лучше. В любое время, когда эти показатели превышают около 15 мс, производительность сервера заметно снижается.
\LogicalDisk\Байт на диске/сек и \LogicalDisk\Чтений на диске/сек и Это покажет вам общую пропускную способность диска. Эти скорости могут насыщать максимальную емкость дисковой подсистемы либо из-за пропускной способности, либо из-за того, что вы достигли предела IOPs для вашего шаблона чтения\записи. Может быть трудно вывести что-либо существенное из этого, если вы не на 100% уверены, что у вас предсказуемый шаблон ввода-вывода. Однако нет действительно полезного способа указать какое-либо конкретное число, за которым нужно следить, но если вы видите 50-100 Мбайт/с или больше с одного диска SATA, это будет примерно так же хорошо, как вы могли бы ожидать. Более быстрые серверные диски (10k, 15k, SSD) могут превзойти это, а подключенное хранилище SAN может предоставить практически все, что вы хотите, если вы заплатите достаточно. При небольшом случайном вводе-выводе (типичном для операций БД) это число всегда будет низким и не скажет вам многого.
\LogicalDisk\Записей на диск/сек, \LogicalDisk\Чтений на диск/сек и \LogicalDisk\Передач на диск/сек Они покажут вам количество дискретных операций ввода-вывода в секунду и соотношение чтения/записи. Вращающиеся диски в этом отношении довольно ограничены - диски SATA на 7,2 тыс. могут поддерживать около 70-80 операций ввода-вывода в секунду, диски на 10 тыс. увеличивают этот показатель до 100-150, а диски на 15 тыс. будут составлять 200+. SSD будут на порядок или два выше. Группы RAID увеличивают этот показатель довольно линейно для чтения, но запись повлечет за собой штраф от 2 до 5. Пакет RAID 5 из 3 дисков (со штрафом записи 4) поддерживает примерно на 25% меньше операций ввода-вывода записи, чем, например, один диск.
Если это число имеет тенденцию к увеличению, а задержка достигает опасного значения (например, > 15 мс), это явный признак того, что ваши диски достигли предела IOPS, независимо от конкретных сообщаемых чисел.
\LogicalDisk\Split IO/сек Это покажет вам, сколько запросов ввода-вывода приводят к нескольким операциям, и даст представление о том, насколько фрагментация влияет на активность ввода-вывода.
PhysicalDisk: Текущая длина очереди диска и PhysicalDisk: Средняя длина очереди диска. Это говорит вам, сколько ожидающих выполнения операций ввода-вывода ожидают завершения на уровне физического диска. Если это 2 или больше на одном диске или превышает количество дисков в группе RAID, из которой состоит диск, то вы можете помещать на диск больше операций ввода-вывода, чем он может выполнить за определенное время. Есть сценарии, в которых это не имеет большого значения, но это будет настоящим убийцей для систем, которым требуется низкая задержка дискового ввода-вывода (базы данных, где кэширование памяти не может компенсировать слабость дисков). Первое — это мгновенное чтение, поэтому беспокойтесь об этом, только если оно постоянно высокое или изменяется в соответствии со счетчиком времени диска. Если средняя длина очереди диска слишком велика, то у вас определенно есть проблема.
Физический диск: % времени диска % Disk time показывает, насколько занят диск. По мере приближения к 100% вам будет трудно заставить систему делать что-либо еще, что зависит от этого диска, поскольку все дополнительные операции ввода-вывода будут, как правило, ставиться в очередь. Даже числа, значительно ниже 100%, могут указывать на проблему, и если они высокие или растут, а также длина текущей очереди диска высока, это является явным признаком нагрузки ввода-вывода, которая превышает емкость дисков. Это число на самом деле рассчитывается странным образом и, как следствие, может быть не таким уж полезным при анализе производительности RAID.
Эта статья в блоге Technetболее подробно рассматриваются некоторые из этих счетчиков и некоторые сценарии, в которых вы можете использовать их для выявления проблемы и определения способа ее устранения.
решение3
Стоит ли рассмотреть возможность настройки пула веб-приложений для частого повторного использования рабочих процессов?