Aleksanders
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Сегодня поднял базы на новом серваке. Полная конфигурация сервака:
Depo Storm 3170L2 2x3.2M2/4GII400/A2230S1/LP/2S73G10/HS6/FD/2US/1C/550W
Подробнее:
3.2ГГц ксеоны с HT - 2 шт.
Мать - SuperMicro X6DH8
Мозги DDR DIMM 3200 2ГБ - 2 шт.
Adaptec SCSI Raid 2230S (Ultra 320).
Винты 73Гб в зеркале RAID - 2 шт.
Сеть Intel Pro/1000 MT - 2 шт.
Стоит 2000 AS, на нем SQL 2000 SP3a, размер базы 2Гб. HT включен.
Тестирование.
Запускаю скрипт обработки БД (сложная обработка, участвует много таблиц, порядок запросов и обработки мне не известен) и наблюдаю забавное явление. Система видит 4 виртуальных процессора и нагружает их более-менее равномерно, средняя загрузка около 40%. Причем замечательно прослеживаются взаимные колебания загрузки двух пар процессоров. Когда 1 процессор загружается сильнее, 3 слабее, и аналогично со 2 и 4 процессорами. Средняя суммарная загрузка пар процессоров составляет примерно 80%. Использование физической памяти порядка 3.6-3.8ГБ.
Вывод. Когда идет работа с большой БД, технология HT не помогает, а только вредит работе, потому что проц обращается к большим объемам оперативной памяти, которые прокачиваются через один, общий на два виртуальных процессора, контроллер памяти. Данные подкачиваться не умпевают и проц больше половины времени висит, ожидая их закачки. Если два разных пользователя попадают на один физический проц, время выполнения запросов от каждого из них будет примерно в 2 раза больше, чем если бы HT не было.
Тестирование 2.
Отключаю HT и запускаю тот же самый скрипт обработки БД. Теперь в системе только 2 виртуальных процессора. Первый проц загружается на 95-100%, второй - примерно на 70-75%. В начале работы скрипта заметен схожий эффект "парности" процессоров, когда "вершинки" загрузки 1 процессора соответствуют "провалам" загрузки 2, но через некоторое время этот эффект практически сходит на нет. Либо менеджер памяти SQL сервера раскидывает страницы памяти более-менее хаотически, либо в начале идут выборки из больших таблиц, а потом - из мелких. В начале теста "средняя" загрузка процессора, которую показывает Windows Task Manager колеблется в районе 80%, далее - 85% и даже почти до 90%. Использование физической памяти порядка 3.4-3.6Гб.
Вывод. Для мультипроцессорных систем КРАЙНЕ нежелательно использовать маленькое количество модулей памяти. В таком случае, пока память сильно не фрагментируется, процессоры своими обращениями к памяти сильно мешают друг другу, вызывая очереди, простои процессоров и потерю производительности. Другой минус малого количества планок памяти - критичность выхода из строя. Если выйдет из строя 1 из 2 планка памяти, сервер становится полностью неработоспособным (странно, что поставщик DEPO так по-дебильному комплектует серверы).
Общие выводы.
В результате тестирования подтвердилось утверждение, что для серверов БД очень важна быстрая работа с памятью, особенно при "больших", не говоря уже про "реально большие" БД. В этом платформа Intel пролетает по сравнению с серверной платформой AMD, где контроллеры памяти присутствуют по количеству ядер, причем ядер не эмулируемых (которые в БД не только не дают прироста производительности, но и откровенно ее снижают -> http://www.zdnet.ru/?ID=502772&4Print=1 ). Правда,
это остается темой для будущих тестов, потому что серверы HP ProLiant ML385 еще только заказаны, и когда будут, тогда и будем писать.
----------
LINUX = Linux Is Not a UniX |
|
