Home

Автор: Дмитрий Демченко

В этой статье я хочу поделиться своим опытом проведения тестирования терминальных серверов с целью определения их нагрузочной способности. Я не ставлю своей целью подробно описать технологию такого тестирования. Я лишь хочу сделать краткий обзор того, как это делали мы, какие результаты получили, какими инструментами пользовались.

Итак.

Введение

Я — руководитель группы тестирования в крупной российской компании. В компании сейчас идет внедрение ERP системы J.D. Edwards OneWorld. Предполагается, что часть конечных пользователей будут работать на «толстых клиентах», а часть — через «тонкие клиенты». Количество «тонких» клиентов, составляет порядка 200-300 пользователей. В связи с этим возникла необходимость оценить, какие сервера, какой конфигурации нужны и в каком количестве, чтобы можно было осуществить запуск ERP системы в промышленной эксплуатации.

Для целей настройки и внедрения ERP системы компания закупила сервер следующей конфигурации:
«2 x HP Proliant DL360 G3 (4xCPU Xeon 2.8Ghz, RAM 2GB, HDD 36GB (RAID1), 2 Fast Ethernet 1000/100Mbit), операционная система Windows 2000 AS»

Если по-простому, то это сервер Hewlett Packard с 4-мя процессорами 2 Гбайтами оперативной памяти и установленной на нём операционной системой Windows 2000. На этом сервере и предполагалось проведение дальнейшего тестирования.

Методология

После того, как была поставлена задача, появился вопрос, как провести такое тестирование? Я нашел несколько статей и сведения одной из них (http://citrix.pp.ru/conf/chap03.html) и взял за основу своего тестирования. Большое спасибо авторам статьи.

В статье рекомендовалось проделать примерно следующие шаги:

1. Запускаем несколько «тонких клиентов» на терминальном сервере в «нормальной нагрузке». Под «нормальной нагрузкой», в данном случае, я понимал нагрузку на сервер, которую создаст пользователь, когда будет работать в свой «обычный рабочий день», да простите мне такие бытовые определения.
2. Оцениваем загруженность процессора на терминальном сервере. Так как процессоров на одном сервере может быть много, то мы оцениваем общую загруженность процессоров. В дальнейшем я буду говорить «загрузка процессора».
3. Если загрузка процессора меньше 80%, то увеличиваем количество «тонких клиентов» до тех пор, пока общая загрузка процессоров на терминальном сервере не вырастет до 70-80%.
4. Когда загрузка процессора увеличится до 70-80%, подсчитываем количество одновременно работающих «тонких клиентов». Это и будет то количество пользователей, которые одновременно могут работать на терминальном сервере в «нормальной нагрузке».
5. Зная общее количество конечных пользователей, которые будут работать в ERP системе через «тонких клиентов» после запуска в промышленную эксплуатацию, разделим это число на количество «тонких клиентов», которые смогут работать на одном терминальном сервере. Таким образом мы получим количество терминальных серверов, которое нам необходимо для запуска ERP системы в промышленную эксплуатацию.

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

Практическое применение

Инструменты мониторинга загрузки процессора, дисковой активности, файла подкачки в общем-то известны — это «Диспетчер задач» (TaskManager) и «Производительность» (Performance Monitor). Ничем другим при таком тестировании мы не пользовались.

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

В ERP системе J.D Edwards есть целая линейка инструментов для полного тестирования системы, начиная от тестирования функциональности и заканчивая нагрузочным тестированием, включая инструменты анализа логов в различных срезах.

Один из таких инструментов — OneWorld scripting Tool (AutoPliot), наподобие Rational Robot, фирмы IBM, с помощью которого можно создать скрипт, эмулирующий работу конечного пользователя.

Было решено, написать скрипты, которые бы эмулировали работу конечных пользователей (создание заказов закупки) и запускать эти скрипты последовательно в различной комбинации.

Проведение тестирования 1. Результаты

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

Рисунок 1

За состоянием сервера следили постоянно, но «картинку» (скриншот) получили в тот момент, когда к серверу было подключено 24 пользователя, из которых активно работали 20. Четверо были соединены с сервером, но никаких операций на нем не выполняли. В этот момент сервер уже работал с заметным «торможением» так, что это визуально ощущалось на клиентском компьютере.

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

При этом используемая память превышала 3,5 Гб.

Динамику использования памяти можно увидеть на рис.2

Рисунок 2

Если посмотреть, какие процессы занимали больше всего места в памяти (см. рис. 3 — список отсортирован по убыванию)

Рисунок 3

то можно увидеть, что это ERP система (oexplore.exe).

По полученным результатам был сделан вывод, что терминальный сервер может обеспечить работу в «нормальном режиме» не более 20 активно работающих пользователей.

Под «нормальным режимом» я понимаю режим, когда не происходит заметного замедления работы клиентов по причине «торможения» терминального сервера.

В нашем случае было отмечено, что если число активных пользователей превышает 20, то сервер заметно замедляет свою работу.

Видно, что «узким местом» в работе терминального сервера является недостаток памяти — так как память используется на 100%, (зеленая линия на рис. 1), а процессор загружен в среднем на 20% (красная линия на рис.1). И, возможно, узким местом, является работа с диском. Но, для подтверждения этого предположения нужно было проводить отдельные тесты.

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

Цитата:

«По поводу загрузки памяти/дисков — тест подтвердил наши предположения о нехватке памяти на серверах. Дисковая активность является результатом свопирования.

Вывод:

1. Необходимо увеличить память на существующих серверах.
2. Осталось выяснить до какого значения увеличивать память (4-6-8 Гиг), 8 Гиг это предел».

Конец цитаты.

Проведение тестирования 2: Результаты

После проведения этого первого этапа тестирования стало ясно, что соотношение загрузки процессора и используемой памяти не является оптимальным, так как, условно говоря, процессор «простаивает», то есть используется не на полную мощность, а память используется на все 100 процентов, и идет процесс «свопирования» памяти с жесткого диска. Было принято решение провести повторное тестирование на этом же терминальном сервере, но с увеличенной оперативной памятью до размеров 4Гбайта. Другими словами, было принято решение «расширить» выявленное при первом тестировании «узкое место» и провести повторное тестирование.

Тест показал, что с увеличением размера памяти количество активно работающих пользователей, которые может обработать сервер, увеличилось в 1,5 раза и достигло 35 активно работающих пользователей. При увеличении количества активных пользователей больше 35, система начинает заметно замедлять свою работу. Во время тестирования я создал 39 активных пользователей. Всего же к серверу было подключено 52 пользователя.

При увеличении количества активных пользователей больше 35, система начинает заметно замедлять свою работу. Во время тестирования я создал 39 активных пользователей. Всего же к серверу было подключено 52 пользователя.

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

Рисунок 4

Следует обратить внимание, что размер используемой памяти более 6Гб, то есть полностью используется оперативная память, и еще 2Гбайта памяти было подгружено с жесткого диска. Если посмотреть еще одну диаграмму, то

Рисунок 5

можно увидеть, что загрузка процессора в среднем была 83% (на рисунке сверху это красная кривая). Напомню, что это было при подключении 52 пользователей, 39 из которых активно работали. При этом работа с диском была загружена на 100% (синяя линия на рисунке сверху). И файл подкачки постоянно увеличивался (на рисунке зеленая кривая).

Если посмотреть на список процессов, которые занимали больше всего места на диске, то это окажется программа oexplore.exe, то есть ERP система (список отсортирован по убыванию).

Рисунок 6

В общем, можно сделать вывод, что при увеличении размера памяти в 2 раза количество активно работающих пользователей, которые может обработать сервер без заметного торможения системы, увеличилось в 1,5 — 2 раза.

Почему я не даю жесткого коэффициента, например, 1,5 или 2? Потому что для этого, понятие «заметное торможение системы» надо измерять конкретными значениями. Так как таких измерений проведено не было, то оценка торможения системы производилась, что называется «на глазок».

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

ЦИТАТА:

«Из проведенного тестирования стало видно, что критическое число активных пользователей, после которых заметно снижалась реактивность системы:

1. Для сервера с ОЗУ 2 Гигабайта = 17
2. Для сервера с ОЗУ 4 Гигабайта = 35

При конфигурации сервера с 4 Гигабайтами памяти мы приблизились (по сравнению с 2 Гигабайтами памяти) к оптимальной загрузке сервера по соотношению «Загрузка ЦПУ» / «Заргузка ОЗУ».

Вполне вероятно, что при установке 6 либо 8 Гигабайт памяти мы приблизимся еще ближе или же пройдем этот порог и будем иметь лишнюю неиспользуемую память. К сожалению это тестирование произвести весьма затруднительно, в связи с отсутствием такой памяти в городе».

Конец ЦИТАТЫ.

Заключение

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

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