Лекция вторая, часть 1

О мониторинге производительности трехзвенной системы NSD, сервера приложений и баз данных под управлением MS Windows 2003. СУБД MS SQL 2005.
Автор, как водится, не я. Эту лекцию вчера прочел ведущий разработчик NSD.
Часть первая, как и сказано в заголовке.

Постановка задания
Задача изначально выглядит так, цитирую: у нас наблюдается значительное снижение производительности всей вашей системы, просьба посмотреть, разобраться и выработать решение по увеличению производительности.

Получается, что нельзя наверняка сказать, какой модуль системы медленно работает и нужно смотреть все параметры.


Имеющиеся средства

В случае, если нет удаленного доступа - нужно развивать способности в телепатии и навыки письменного общения, но смысл действий остается тем же.
Но у нас удаленный доступ есть.
Типичный набор для клиента centOS+oracle или Win2003+MSSQL2005, сегодня мы рассмотрим второй вариант. Для него характерен доступ по rdp.

То есть наши действия выглядят так:

rdesktop -u username -p password -d domain_name -r disk:share=/tmp/incoming -a 8 xxx.xxx.xxx.xxx -g 1280x800 -0

Подключаться по нуль сессии негуманно, зато эффективно.
Рекомендуется создать табличку, в которую аккуратно вносить информацию о системе клиента

1 Мы в системе клиента.



2 Записать название, разрядность и версию операционной системы
3 Записать марку, тактовую частоту процессора,
4 Записать объем оперативной памяти



5 Записать число ядер процессора
6 Записать процент доступной оперативной памяти. В данном применре 0.12/4.19 Gb, 4%
7 Записать объем системного кеша
8 Записать средний уровень загрузки процессора. В данном примере 4-20%
9 Записать уровень использования файла подкачки

а) В данном примере уровень загрузки процессора в пределах допустимого
б) Насчет уровня использования оперативной памяти: я так понимаю, должен оставаться небольшой запас, в данном случае - маловато, но допустимо.
в) В данном примере - использование файла подкачики - могло быть меньше, но нормально.



10 Записать количество импользуемой нашей системой оперативной памяти

г) Повниматльней рассмотреть всех потребителей памяти. В данном случае это собственно приложение (для сервера баз данных это будет процесс sqlserver), а также антивирусная система.



11 Записать размер разделов и количество свободного места.

д) В данном примере на диске c:/ маловато места и скоро будет необходима чистка или перенос данных. Но также можно заметить, что под логи выделен отдельный раздел. А логи, как известно, основной продукт сервера приложений.



12 Записать количество физических дисков и размещение разделов на них.

е) В данном примере бекапы, логи и приложение находится на одном диске, но оптимальным вариантом было бы логи и бекапы вынести на другой физический диск. Впрочем, скорость доступа к дисковой подсистеме для приложения не так критична, но приложения бывают разными и на это следует обращать внимание.
ё) Имеет смысл помещать файл подкачки на отдельный раздел или даже на отдельное устройство для ускорения работы системы. В данном случае файл подкачки находится на отдельном разделе.
ж) Следует обратить внимание, на место назначения резервного копирования сервера приложений. В данном примере оно происходит на другую машину и по ночам(выясняется не самостоятельно, а у системного администратора) когда нагрузка на сервер минимальна.

Антивирусная система

з) Некорректно настроеный антивирус может серьезно тормозить работу системы.



13 Следует обратить внимание на настройки регулярных полных проверок системы,они не должны по времени совпадать с другими плановыми операциями сервера
14 Необходимо сделать приложение нашей системы доверенным. Также в доверенные зоны прописать папки системы и логов. В случае сервера БД в зоны исключений должны быть включены места хранения бекапов субд и сами файлы баз данных.

и) Логи имеют серьезный объем и любая их проверка требует больших затрат ресурсов системы
к) Сервер приложений во сремя работы постоянно обращается к своим файлам и их проверка антивирусов может серьезно замедлить работу системы

15 Запросить у системного администратора данные по сторонним приложениям, выполняющимся на сервере.

Выводы делать еще рано, но предварительно можно выделить несколько пунктов:
а) Критическое значение загрузки процессора
б) Недостаточное количество оперативной памяти
в) Некорректное проектирование размещения файлов системы (логов, приложения, бекапов)
г) Некорректные настройки антивирусной системы
д) Некорректные настройки приложения в контексте использования им памяти
Эти данные скорее всего помогут в дальнейшем анализе, но изменение настроек антивируса и перенастройка размещения логов и бекапов могуд дать прирост производительности уже сейчас.

Те же действия проделать для сервера базы данных.

В результате данной работы должна появиться табличка из 15 пунктов. Рекомендуется занести ее в локальную вики для дальнейшего использования и ретроспективы.


Я не зря постоянно повторял слово "Записать", так как на первом этапе анализа ничего кроме этого делать вообще не нужно, у нас не крах системы, а медленная работа. Спокойствие, только спокойствие(цэ).

На этом часть первая считается завершенной. Предложения и замечания принимаются и приветствуются.
Во второй части лекции планирую рассмотреть доступные мне методы и средства анализа производительности СУБД MS SQL2005 и выводы.
Объясняю, почему здесь практически нет рекомендаций к действию: цель мониторинга - именно накопление данных. В моем случае - не больше. Эти данные и выводы будут переданы клиентам и специалистам после согласования изменений в системе клиента.