Вчера я (программист) и один из моих коллег из нашего отдела хостинга начали серию тестов для решения проблем с производительностью наших веб-сайтов. Мы запускаем сервер с Windows Server 2008 с 8 ГБ оперативной памяти. Мы собираемся обновить наш сервер дополнительной оперативной памятью 8 Гб, потому что наши клиенты испытывают низкую производительность бэкэнда (Sitecore). Мы думаем, что наши проблемы с производительностью связаны с тем, что на нашем сервере слишком много баз данных. Мы быстро изучили счетчики производительности на сервере, на котором мы тестируем, но наш тестовый сервер полностью отличается от нашего реального сервера. Мы изолировали некоторые веб-сайты на тестовом сервере и запустили некоторые стресс-тесты / тесты базы данных на этом сервере и попробовали выполнить некоторые измерения с помощью счетчиков, с которыми у нас нет опыта. Как мы можем решить проблему на нашем живом сервере, используя счетчики производительности? Есть ли какое-нибудь хорошее руководство о том, как решать такие проблемы с производительностью? Любые советы будут высоко ценится!
На предыдущей работе мне было поручено найти проблемы с производительностью и советуя пути исправления. Я всегда начинаю с рассмотрения некоторых основных счетчиков в perfmon.
%Disk Time
%Idle Time
Avg Disk Queue Length
Avg Disk sec/Transfer
Pages/sec
% Processor Time
Я также постараюсь выделить некоторые медленные страницы в приложении и просмотреть их запросы. Иногда страницы с большим количеством запросов, такие как главная страница, могут иметь медленные запросы, которые замедляют выполнение других правильно выполняемых запросов. После того, как я отследил некоторые запросы, я обычно выполняю их в студии управления и просматриваю их план запросов, чтобы выявить болевые точки, такие как отсутствующий или неправильный индекс. В конце концов, это довольно просто. Это было также легко для меня, поскольку это было приложение SAAS, в котором многие клиенты подключились к серверам сохранения, используя одно и то же программное обеспечение.
Медлительность может быть вызвана тем фактом, что вы достигли естественного переломного момента, когда ваш веб-трафик плюс ваш сервер базы данных слишком велик для одного ящика. Но прежде чем вы начнете вкладывать 5000 долларов в новый сервер базы данных, взгляните на данные perfmon и убедитесь, что что-то уже не выделяется. В моем случае проблема заключалась в большом количестве операций ввода-вывода диска в массиве хранения с прямым подключением. Одним из возможных решений было добавление дополнительных шпинделей. А также добавление дополнительной памяти для большего кэширования и выгрузка файлов журнала на другой RAID-массив на машине. В этом случае веб-уровень также не находился на сервере БД, поэтому для меня это не было проблемой.
Я не думаю, что счетчики производительности дадут полезный ответ на этот вопрос, поскольку они действительно говорят вам только о том, что часто происходили определенные вещи или какую пропускную способность вы получаете, но вы уже знаете, что пропускная способность невелика.
Я посмотрел на доступные счетчики производительности на нашем MS SQL Server, и ничто там не показалось мне особенно полезным для этого. Вы можете опробовать некоторые счетчики в категории SQLServer: Wait Statistics, чтобы получить некоторые сведения.
Однако я бы начал с обычных подозреваемых: