У моего работодателя более тысячи серверов (с SQL Server 2005 x64 и парочкой других приложений) по всей стране. И, на мой взгляд, все они крайне неспособны к тому, что им нужно делать.
В частности, я считаю, что серверам просто не хватает оперативной памяти для того объема, который требуется от машин. Все серверы в настоящее время имеют 6 ГБ оперативной памяти. Пользователи почти всегда жалуются на производительность (в основном потому, что, immo, сервер довольно часто погружается в файл подкачки).
Я наконец убедил сильных мира сего попробовать хотя бы апгрейд памяти на одном приборе и посмотреть результаты. Однако им нужны показатели до и после, чтобы увидеть, что расходы будут оправданы.
Мой вопрос в том, какие показатели мне следует собрать, чтобы увидеть, действительно ли производительность коробки улучшилась? Я разработчик, поэтому не знаю, как и что собирать (я кое-что знаю о Perfmon).
РЕДАКТИРОВАТЬ: Я думаю, я ищу конкретные счетчики для тестирования.
Я бы порекомендовал вам провести нагрузочные тесты на коробке до и после обновления памяти через приложение. Смоделируйте нагрузку, вызывающую снижение производительности с точки зрения пользователя, а затем покажите улучшения после обновления памяти (что-то вроде jmeter может сделать это в веб-приложении). Если вы не можете этого сделать при нагрузочном тестировании приложения, возможно, вы сможете смоделировать запросы.
Затем при этом вы также можете запустить счетчики, рекомендованные Farseeker. Причина, по которой я думаю, вам следует делать это через интерфейс, заключается в том, что это деловые люди, и они, вероятно, не получат полного объяснения файла подкачки или времени запроса и т. Д. Однако они должны понимать время отклика приложения, поскольку это то, что все ищут улучшить.
Однако, если тесты стоят больше, чем сама память (составление планов тестирования, настройка серверов для генерации нагрузки и т. Д.), Возможно, вам стоит просто попросить их доверять вашему мнению или провести наилучшие тесты, которые вы можете.
Также может быть полезно собрать некоторую статистику perfmon для скорости страниц, очередей на диске и т. Д.
Проверить, нужно ли вам обновление памяти, обычно довольно просто. Некоторые perfmon счетчики сообщают вам, сколько раз ОС погружается в файл подкачки, а также об использовании памяти, страницах и т. д. Кроме того, поскольку это SQL Server, вы также можете использовать профилировщик, чтобы узнать, сколько операций чтения с диска выполняется точно запросы. Если использование памяти меньше 90%, то сервер SQL не настроен оптимально. Не используйте для этого диспетчер задач, поскольку столбец «свободной» памяти включает объем, выделенный для предварительной выборки.
Вы должны суметь убедить их (и себя) в том, что это необходимо, с помощью этих показателей, прежде чем вы даже потрудитесь делать до / после тестов. Тесты до / после обычно просто подтверждают ваше первоначальное доказательство. И если ваши показатели не предполагают, что вам нужно больше оперативной памяти, тогда это спасет вас.
Однако для запросов до / после я бы взял часто используемый запрос (не слишком простой, что-то реальное), бросил его в SQL Management Studio, включил план выполнения (чтобы вы могли убедиться, что он выполняет один и тот же план каждый время, и, таким образом, вы получите достоверные результаты), и время, сколько времени они займут.
Счетчики монитора производительности - это хорошо, но они не всегда рассказывают всю историю. Я думаю, вам также необходимо измерить это с точки зрения изменений в восприятии пользователями производительности приложения.
Есть ли у вас «SLA», определяющее приемлемую производительность для этого приложения в определенных задачах / сценариях (а если нет, то почему?).
Либо вы увидите «реальное» улучшение отзывчивости приложения, которое приведет к количественному снижению жалоб на производительность, и / или приложение будет лучше выполнять свои требования SLA, либо вы этого не сделаете.
Правильно ли "настроены" сервисы для системы? Может быть, процесс SQL использует много памяти, как ему нравится, и не имеет ограничения на то, что он может использовать, и это влияет на производительность для других компонентов за пределами части приложения, основанной на SQL ?
Вы установили, что это не узкое место диска или сети?
Если вы все же продолжите обновление, помните, что не вся оперативная память произведена идеально. Даже поршень ECC может быть изготовлен с дефектами, хотя серьезные дефекты будут более редкими. Если возможно, сделайте первоначальную проверку памяти, используя что-то вроде Memtest86 +, прежде чем устанавливать его на серверах. Еще лучше, если вы сможете запустить тот же тест после установки, но это означает большее время простоя.
Ваш клиент не будет доволен, если ваше «обновление» приведет к нестабильности серверов.