Четырехъядерные Xeon - первые впечатления в реальной жизни

Тестирование четырехъядерного серверного процессора, а именно Intel Xeon 53xx, задумывалось еще в конце 2006 г., когда он только появился в Украине. Эта тема весьма актуальна, поскольку между выпуском первых двухъядерных и новейших четырехъядерных образцов прошло совсем немного времени, и, кроме того, уже есть несколько совершенно различных подходов к "удвоению" количества ядер. Именно поэтому в материале рассмотрены оба поколения CPU, причем главная цель их испытаний - выявить наиболее примечательные моменты в работе тех и других, параллельно сравнив производительность. Также отдельной задачей было изучение взаимодействия связки "процессор-память". Поскольку в предыдущих тестированиях мы использовали только одну конфигурацию, включающую четыре линейки FB-DIMM, установленные по типовой схеме, в этом материале мы приняли решение проанализировать влияние разного количества модулей на производительность, сохраняя объем ОЗУ неизменным. Не меньший интерес представляло рассмотрение нескольких режимов работы с памятью (Interleave, Sequential) при различных вариантах установки модулей, в том числе как рекомендованных Intel, так и произвольно выбранных. Результаты исследований оказались достаточно интересными.

Начало современного развития многоядерности в серверном сегменте было положено успешной реализацией двухъядерных CPU в исполнении AMD - двухпроцессорные системы с ними демонстрировали почти линейный рост быстродействия и по параметру вычислительной мощности практически вплотную подошли к четырехпроцессорным одноядерным системам того же производителя. Затем компания Intel выпустила в целом неплохой, но имеющий некоторые "врожденные" недостатки Xeon 50xx (современное название серии). Фактически он представлял собой два типовых CPU, объединенных на одной подложке. Основная проблема такого подхода, кроме высокого тепловыделения, - конкуренция обоих независимых процессоров за доступ к общим ресурсам и особенно к оперативной памяти. Из-за этого они не могли продемонстрировать в полной мере всю свою вычислительную мощность в тех задачах, где имел место интенсивный обмен данными с ОЗУ (к их числу, например, относятся задачи, решаемые серверами баз данных и терминалов).

Для двухпроцессорных систем ситуация усугублялась работой обоих CPU на общей шине "процессор - северный мост". Ну а если вспомнить о технологии Hyper-Threading (HT) и посчитать потоки обработки данных в двухпроцессорных серверах на двухъядерных CPU с включенной функцией HT, то получаем целых восемь потоков на единственной шине и FSB.

Кардинально изменил ситуацию выход нового семейства серверных процессоров Intel Xeon 51xx, в основе которых лежит архитектура Core 2. Это были уже "честные" двухъядерные CPU, использующие весьма объемный общий кэш второго уровня для обоих ядер - 4 MB. Дабы не перечислять огромное количество нововведений этой архитектуры, что по большей части уже было сделано, переведем технологические подробности в область эмоций - автор "снимает шляпу" перед инженерами Intel.

Кроме архитектуры центрального процессора, изменилось и подключение CPU в двухпроцессорных системах к северному мосту - теперь каждый из них общается с чипсетом и памятью по собственной, независимой, буферизируемой шине. Казалось бы, все отлично, и результат должен быть просто прекрасным. Так и получилось, правда, с одним "но". При интенсивной работе с оперативной памятью и большом количестве переключений между сегментами памяти производительность сервера на новой платформе падала непропорционально увеличению нагрузки. Уже при первой попытке выяснить причины такого эффекта было отмечено, что очередь обращений к RAM полностью заполнена, а ядра CPU загружены всего на 70%. Дальнейшее исследование ситуации позволило определить главного "виновника" - новый тип памяти FB-DIMM, у которой при псевдопроизвольной выборке латентность доступа составляет приблизительно 160 мс, а при случайной - может достигать и 200 мс.

На фоне порядка 40 и 60 мс у конкурирующей архитектуры это выглядит не cлишком привлекательно. Конечно, при потоковом доступе к RAM архитектура FB-DIMM позволяет достичь просто колоссальных показателей - 21 GBps. Проблема в том, что многие серверные задачи - как раз не потоковые, а требующие доступа к различным сегментам памяти. Соответственно, в тестах получили ситуацию, при которой с ростом количества задач и потоков реальная производительность сервера уменьшается отнюдь не линейно.

Из разъяснений технических специалистов Intel следовало, что причина такого поведения системы - в использовании всего четырех модулей FB-DIMM, в то время как, по их оценкам, для полного раскрытия потенциала платформы их требуется не менее восьми. И действительно, в наших тестах на базе "типовых, заказываемых покупателем" серверов, было установлено именно четыре FB-DIMM, а значит, этот вопрос следовало проверить отдельно.

Учитывая приведенные выше соображения, логично было предположить, что сервер на четырехъядерном процессоре Intel Xeon 53xx, построенный, как и серия 50хх, путем объединения в одном корпусе двух отдельных двухъядерных CPU, "унаследует" и недостатки серии 50хх при работе с памятью (конкуренция за доступ к ресурсам, в первую очередь - RAM). Ну а если учесть появление "узкого места" в виде одной шины передачи данных "процессор - северный мост" для четырех ядер в сочетании с применением памяти, обладающей высокой латентностью, то результат может оказаться далеко не лучшим. К тому же вопрос "сколько же модулей памяти ставить?" в этом контексте звучит более чем актуально, учитывая рекомендации производителя, с одной стороны, и цены на FB-DIMM - с другой.

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

Особенности тестов

Так выглядит упрощенная блок-схема включения процессоров Clovertown в двухпроцессорной конфигурации. Исследование взаимодействия процессоров с памятью в такой структуре (два банка - два канала) представляло особый интерес

Перед тем как приводить описание результатов, есть смысл дать ряд пояснений. Итак, фактор первый и основной: мы не ставили перед собой задачи определения, кто "лучше" и кто "хуже", и тем более не пытались "выяснить отношения" между двумя архитектурами - Intel и AMD. Посему платформа AMD в этих тестах участия не принимала сразу по нескольким причинам, основная из которых - отсутствие на рынке предложения вообще какого-либо CPU от AMD с четырьмя ядрами. Мы сравниваем исключительно двух- и четырехъядерные процессоры Intel Core 2, работающие на одинаковой серверной платформе, и пытаемся оценить, что нам дало очередное удвоение количества ядер в одном CPU.

Фактор второй. Нам показалось интересным получить результаты на уровне "что лучше соответствует задаче?" - двухъядерный процессор с более высокой частотой или четырехъядерный с меньшей. Вопрос отнюдь не праздный - на момент проведения тестов стоимость двухъядерного чипа Intel Xeon 5160, работающего на частоте 3,0 GHz, была практически равна цене четырехъядерного Intel Xeon 5345 с частотой 2,33 GHz. А также оценить, для каких задач лучше использовать двухъядерный и более высокочастотный процессор, а для каких - четырехъядерный с меньшей частотой.

Внешне процессоры серии 53хх ничем не отличаются от предшественников

Фактор третий. Раз уж возникла дискуссия об оптимальном количестве модулей FB-DIMM, имеет смысл посмотреть на реальную разницу в производительности двухпроцессорных серверов на двух- и четырехъядерных CPU с установленными четырьмя или восемью линейками. Для чистоты эксперимента мы провели еще и тестирование двухъядерных систем, у которых четыре линейки FB-DIMM размещены иначе, чем рекомендует Intel, - чтобы определить цену вопроса при "неправильной" установке модулей RAM в банки. Дабы уравнять шансы, применялись четыре модуля двухранговой (dual-range) памяти по 2 GB и восемь - по 1 GB.

Фактор четвертый. Как и предполагалось, используемая методика тестирования производительности серверов с помощью "1С:Предприятие 7.7" подошла к пределу своей применимости. К примеру, один из тестов, а именно "Создание элементов справочника", уже при запуске трех потоков ни разу не закончился корректно. И причина не в "железе" - программа присваивала двум разным элементам одинаковый внутренний номер (идентификатор в БД, генерируемый самой платформой "1С:Предприятие 7.7", скрытый от пользователей и прикладных программистов). Причем эксперимент ставился на релизах с 21 по 27, и ни один не заработал корректно. И этот случай не единичен - аналогичные проблемы возникали на разных этапах, хотя и не столь явно.

Выбор количества модулей памяти стоит определять только на реальной задаче. При использовании четырех модулей общий объем памяти не обязательно станет меньше - так, в нашем тестировании мы применяли эти линейки FB-DIMM Corsair объемом 2 GB (предоставлены ASBIS).

Посредством определенных действий и некоторых модификаций пакета внешними модулями удалось добиться стабильного прохождения всех тестов. Но стоит отметить, что за это пришлось заплатить определенным замедлением работы в многопользовательском режиме - в различных ситуациях оно могло достигать 8%. Во избежание искажения результатов было принято решение все тесты проводить исключительно на модифицированной версии "1С:Предприятие 7.7", релиз 25.

Кроме этого, количество итераций в ряде тестов пришлось увеличить в 10 раз для получения адекватно измеряемого результата. Причина проста: если тест на генерацию 1000 элементов справочника начинает выполнятся менее чем за 3 с, произвести точный замер времени становится просто проблематично. И хотя за основу взята методика, описанная в предыдущих тестированиях, при сравнении результатов обязательно стоит учитывать число замеров и делать поправку на некоторое замедление в многопользовательском режиме.

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

Рассматривались следующие конфигурации:

Intel Xeon 5150 (2,67 GHz, 4 MB L2) + 8 FB-DIMM;
Intel Xeon 5150 (2,67 GHz, 4 MB L2) + 4 FB-DIMM Interleave (рекомендуемый);
Intel Xeon 5345 (2,33 GHz, 8 MB L2) + 8 FB-DIMM;
Intel Xeon 5345 (2,33 GHz, 8 MB L2) + 4 FB-DIMM Interleave (рекомендуемый);
Intel Xeon 5345 (2,33 GHz, 8 MB L2) + 4 FB-DIMM Sequential.

Остальные компоненты:

HDD SCSI 73 GB Cheetah ST373207LC 80pin/ 10K - 4 шт., Stripe RAID, write cache - "on";
Adaptec SCSI RAID 2130/128 SLP OEM.

Использовалось программное обеспечение Windows Server 2003 R2 Standard RU OEM 32 bit, MS SQL Server 2000 + SP4, "1С:Предприятие 7.7", SQL-версия, релиз 25.

С целью получения наиболее корректного результата тесты дублировались на двух платформах: Supermicro X7DB8+ (предоставлена Onix) и Tyan S5380 (Entry). Отметим, что расхождения в показателях оказались настолько незначительными, что ими можно вполне пренебречь.

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

Блок "сервисных" тестов

Выгрузка БД - стандартная операция архивирования, довольно регулярно (по крайней мере, так должно быть) выполняемая администратором. Ее особенностями являются потоковый характер и плохая распараллеливаемость (т. е. реально может быть задействован всего один процесс от "1С") .

На диаграмме хорошо заметно сразу несколько эффектов, опишем их подробнее. Действительно, масштабируемость архитектуры Core 2 в монопольном режиме (фактически работает только одно ядро) практически линейна для такого приложения, как "1С:Предприятие 7.7", - разница в результатах для процессоров на различных частотах пропорциональна разнице частот и составляет приблизительно 14%.

Для систем как на двух-, так и на четырехъядерных CPU, наблюдается прирост производительности при установке восьми модулей памяти (относительно четырех FB-DIMM), хотя значительным его назвать трудно - порядка 2%.

В данном тесте видно, что установка четырех модулей так, как рекомендует Intel, дает пусть небольшой, но прирост быстродействия - на уровне 1%.

Загрузка БД - стандартная операция, применяемая для восстановления из архива или создания копии БД. Из особенностей - плохое распараллеливание задачи и частые обращения к различным сегментам памяти. Соответственно, в этой задаче большее значение имеет не потоковая пропускная способность оперативной памяти, а ее реальная латентность в режиме псевдослучайной выборки.

Достаточно показательный и интересный результат.

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

Несколько неожиданный эффект был получен при сравнении систем на двух- и четырехъядерных CPU. Конфигурация на четырехъядерных процессорах с восемью модулями FB-DIMM оказалась быстрее на 3%, чем с четырьмя FB-DIMM. А вот для двухъядерных все получилось с точностью до наоборот - установка восьми линеек FB-DIMM привела к замедлению системы на 1% относительно конфигурации с четырьмя модулями. Результат для нас неожиданный, хотя и объяснимый.

Опять-таки видим, что рекомендации по поводу того, как правильно ставить линейки памяти, имеют под собой почву - "неправильная" установка четырех модулей FB-DIMM приводит к падению производительности более чем на 1%.

Тестирование и исправление БД - стандартная процедура, отличающаяся высокой ресурсоемкостью и продолжительностью. Для нее характерны большая расчетная нагрузка на процессор и частые обращения к различным сегментам памяти. Из тестов, выполняемых исключительно в монопольном режиме, этот - самый сложный и длительный.

В данном случае комментировать особо нечего: видим общую картинку - такую же, как и в тесте "Выгрузка данных". Масштабируемость систем на Intel Xeon 51хх и 53хх в монопольном режиме практически линейна для "1С:Предприятие 7.7" - разница в результатах для процессоров на различных частотах пропорциональна разнице частот.

Для систем и на двух-, и на четырехъядерных процессорах зафиксирован прирост производительности при установке восьми модулей памяти относительно четырех FB-DIMM чуть меньше 1% для двухъядерной конфигурации и более 4% - для четырехъядерной. Обратим внимание, что для систем на четырехъядерных CPU установка восьми линеек дает больший прирост быстродействия, чем для двухъядерных.

В тесте видно, что установка четырех модулей памяти так, как рекомендует Intel, увеличивает производительность на 2,5%.

Блок тестов "узкие места"

Специализированная обработка "Тиражирование справочников". Несложный тест, интересный прежде всего в многопользовательском режиме. Фактически это простейший вариант INSERT для одной таблицы. Именно его не смогла пройти на сервере с четырехъядерными процессорами стандартная поставка платформы "1С:Предприятие 7.7". Очевидно, что это уже повод покупателям серверов на четырехъядерных CPU всерьез задуматься о переходе на новую платформу "1С:Предприятие 8".

В монопольном режиме выигрыш от использования более высокочастотного процессора уже не столь очевиден - на уровне 11%. Установка восьми модулей памяти дает прирост производительности около 4 % для системы как на двухъядерных, так и на четырехъядерных CPU по сравнению с "рекомендованным" вариантом установки четырех FB-DIMM.

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

Хорошо заметно, что в режиме установки четырех FB-DIMM для систем и на двух-, и на четырехъядерных процессорах достигается боóльшая (на 2,5%) производительность. Да это и неудивительно - все-таки физическая латентность работы с памятью при четырех модулях ниже.

В режиме Sequential с четырьмя FB-DIMM удается получить еще около 1,5% прироста быстродействия, т. е. для данной задачи (прошу обратить внимание, в немалой степени искусственной и в реальной жизни встречающейся относительно редко) рекомендованный компанией Intel вариант установки четырех модулей оказался не оптимален. Причины же мы опишем в конце статьи.

Специализированная обработка "Тиражирование документов" - технология выполнения данного теста, имитирующего все тот же INSERT в потоковом режиме и по одной таблице, но при этом еще и SELECT по нескольким таблицам (буферизированный SQL-сервером). Главная его задача - проверить, не блокируется ли одна из основных таблиц БД - журнал документов.

В монопольном режиме получаем убедительную победу Xeon 5150 над Xeon 5345 с меньшей тактовой частотой, что вполне закономерно для однопотоковой задачи. Опять наблюдаем эффект, что cиcтемы на двух- и четырехъядерных CPU по-разному реагируют на установку восьми модулей памяти FB-DIMM. Система на двухъядерных процессорах при восьми модулях демонстрирует падение производительности в этом тесте приблизительно на 3%, а на четырехъядерных - прирост на уровне 1%. Отметим, что установка четырех модулей памяти по рекомендациям Intel (Interleave) нам добавила 1% быстродействия (относительно варианта Sequential).

В многопользовательском режиме получен довольно интересный результат - сервер на более высокочастотных двухъядерных процессорах лишь на 5% превзошел сервер на четырехъядерных CPU. Опять наблюдаем картину, когда увеличение количества модулей памяти приводит к замедлению работы систем. Расплата за установку памяти не по рекомендациям производителя - более 3%.

Блок тестов "производительность"

Специализированная обработка "Тиражирование последовательности документов с их проведением". Это самый тяжелый и наиболее близкий "к жизни" тест. Он особенно интересен в многопользовательском режиме, поскольку демонстрирует способность системы справиться с множественными запросами к различным связанным таблицам одновременно, а также является показателем для режима импорта данных из других (к примеру, периферийных) БД в распределенной базе данных. Напомним, что в таком режиме при тестировании применялась следующая методика: в первой и второй пользовательских сессиях запускался отчет "Движение партий", который очень интенсивно работает с регистром "Партии запасов", активно задействованным в проведении всех тиражируемых документов, а в третьей - сама обработка. Таким образом, удается достичь "наибольшего уровня помех" для выполняющейся процедуры и работы с блокированием данных, как это бывает и в реальной жизни.

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

Многопользовательский режим - в данном тесте самый высокий показатель для системы на двухъядерных процессорах: на все те же 14% лучше, чем аналогичный для четырехъядерной конфигурации. Даже как-то неожиданно. И вновь наблюдаем, что двухъядерная система достигает наивысших результатов с четырьмя линейками памяти, а четырехъядерная - с восемью. Знаково? Установка четырех модулей в режиме Sequential добавляет приблизительно 2% производительности.

Восстановление последовательности с перепроведением. Тяжелый тест, который имитирует восстановление корректного партионного учета за период. Как правило, выполняется один-два раза в месяц, но уж очень длительная и "болезненная" это процедура. Работает только в монопольном режиме. Наивысший результат системы на двухъядерных CPU - приблизительно на 14% превосходит тот же показатель конфигурации на четырехъядерных процессорах. Для системы на двухъядерных CPU лучшей производительности (на 2%) удается достичь при установке четырех линеек памяти FB-DIMM. И совершенно противоположная ситуация с системой на четырехъядерных процессорах - восемь модулей памяти добавляют 12% быстродействия, что более чем существенно. Для четырех планок выбранный режим, Interleave или Sequential, влияния на результат практически не оказывает.

Построение отчета "Взаиморасчеты" - простой SELECT по одной таблице, который выполняется одновременно многими пользователями и очень часто.

В монопольном режиме наивысший результат системы на двухъядерных процессорах на 14% превосходит аналогичный показатель конфигурации на четырехъядерных CPU. Ничего нового для этого режима - частота влияет на производительность существенно больше, чем наличие любого количества ядер, если они в тесте не задействованы. Наблюдается ситуация, в которой лучший результат для системы с двухъядерными процессорами достигается именно с восемью линейками FB-DIMM, а с четырехъядерными - с четырьмя модулями памяти. Потери при установке четырех модулей памяти в режиме Sequential - около 12%.

В многопользовательском режиме лучший результат системы на двухъядерных CPU приблизительно на 14% превосходит тот же показатель на четырехъядерных. Максимального значения конфигурация с двухъядерными процессорами достигает именно с четырьмя FB-DIMM, а с четырехъядерными - при восьми модулях. Установка четырех линеек памяти в режиме Sequential добавляет чуть больше 1% производительности.

Выполнение запроса в отчете "Движение партий" - тот же SELECT, но по двум таблицам. Выполняется только в монопольном режиме ввиду ресурсоемкости и способности блокировать таблицу данных. Лучший результат на двухъядерных CPU вновь приблизительно на 14% превосходит таковой для системы на четырехъядерных с меньшей на 14% частотой. Более высокий показатель у конфигурации с двухъядерными процессорами и четырьмя модулями FB-DIMM (2%), при этом система с четырехъядерными CPU, оснащенная четырьмя модулями, также достигает максимального результата. Использование четырех линеек памяти в режиме Sequential снижает производительность на 2,5%.

Что осталось "за кадром"

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

В первую очередь надо признать, что методика с использованием в качестве тестовой системы программного комплекса "1С:Предприятие 7.7" пока что дает адекватные результаты, хотя и находится на грани возможного. Так почему же применяется этот пакет? Как показала практика, результаты тестов с использованием данного ПО хорошо коррелируют с подобными же тестами в связке MySQL + PHP/Perl, что важно для динамических Web-сайтов. Также итоги весьма показательны и для таких задач с частым переключением между сегментами памяти (сетевые службы). Нагрузка на сервер БД и CPU в терминальном режиме от "1С:Предприятие 7.7", как правило, уж никак не меньше, чем у других ERP-подобных систем. Ну а если посчитать, на каком количестве инсталляций работает именно "1С:Предприятие 7.7", то получится весьма внушительный процент как для одно-, так и для двухпроцессорных серверов.

Снова возвращаясь к методике, сразу укажем на некоторую некорректность измерения производительности восьмиядерной системы четырьмя, а точнее, пятью основными потоками (без учета ОС) за счет сервера SQL. В защиту приведем всего два момента, побудивших не менять методику и не публиковать результаты тестов с боóльшим количеством потоков. Первый - необходимость иметь возможность все-таки сравнивать старые и новые тесты, чтобы составить представление, во сколько раз возрастет производительность в одинаковых задачах серверов разной архитектуры и разных поколений.

Второй - не всегда корректная работа (прошу обратить внимание, в искусственно ужесточенных условиях) самого приложения "1С:Предприятие 7.7" на многоядерных CPU по причине их "слишком высокого" быстродействия. Здесь имеет смысл еще раз напомнить, что платформа "1С:Предприятие 7" разрабатывалась еще под Windows 3.11, и столь почтенный возраст пакета вполне допускает некоторое недопонимание им многоядерных процессоров без дополнительных "лекарств", в свою очередь приводящих к замедлению работы платформы. Так что придется ограничиться именно оценками - без привлечения результатов, полученных в предыдущих тестированиях.

А вот оценки как раз и не совсем совпадают с результатами тестов. При увеличении количества потоков, если не происходит "вылет" скрипта "1С" по какой-либо причине (как правило, из-за накладок с внутренней нумерацией в таблицах БД), то уже на пяти потоках пакета практически во всех задачах, где четырехъядерный процессор уступил более высокочастотному двухъядерному, показатели выравниваются. И всего лишь в одной задаче при семи потоках "1С" у двухъядерного результаты чуть лучше, чем у четырехъядерного - в генерации элементов справочника. Исходя из опыта можно совершенно четко сказать, что в терминальных системах на 100-200 пользователей "1С: Предприятие 7.7" будет предпочтительнее сервер на четырехъядерных CPU, так как он меньше теряет в производительности при большом количестве потоков. На уровне тестов под "1С:Предприятие 7.7" этого показать не удалось, а вот на платформе "1С:Предприятие 8" это прослеживается довольно четко. Если же несколько отойти от темы "1С", то невооруженным глазом можно заметить прирост быстродействия того же MS SQL Server 2005 в системах с четырехъядерными процессорами относительно более высокочастотных двухъядерных, что было опять-таки отмечено в тестах с использованием "1С:Предприятие 8".

Так что как некое заключение можно дать две рекомендации пользователям "1С:Предприятие 7.7":

• готовьтесь к переходу на новую платформу "1С:Предприятие 8", потому как уже через пару лет может оказаться, что версии 7.7 не помогут никакие "лекарства" на CPU с большим количеством ядер, а двухъядерных просто не будет в продаже;
• планируя переход на "1С:Предприятие 8", учтите, что MS SQL Server 2005 великолепно умеет распараллеливать потоки между ядрами, и сервер с большим количеством ядер и меньшей частотой для задач MS SQL Server 2005 предпочтительнее. Кроме того, обновленная платформа (известная еще как 8.1) также очень хорошо распараллеливает вычислительные потоки, и при значительном количестве пользователей будет эффективнее работать на восьмиядерном сервере, а не на четырехъядерном, но с большей частотой.

Следующее отступление касается вопроса установки модулей памяти - сколько и как ставить? Сразу же скажем, что в режиме Sequential, на котором иногда получались лучшие результаты, идет очень большой разброс этих показателей в индивидуальном плане - одна и та же операция может выполняться с разницей до 5%! Это не очень заметно по цифрам, так как крайние значения отбрасываются, и происходит усреднение результатов. Но прежде чем на своем сервере устраивать подобную "лотерею", есть смысл провести целую серию предварительных тестов на типовых задачах.

Еще одна особенность режима Sequential - "обучение" системы выполняемой операции и оптимизация. При трех запусках одного и того же теста подряд мы наверняка получим результаты вида: 27 с, 25 с, 23 с, т. е. каждая последующая операция выполняется быстрее предыдущей. Попробуем проанализировать эту ситуацию. Что мы имеем, когда все четыре модуля располагаются в четырех каналах (режим Interleave)? Высокую пропускную способность. А что мы имеем, когда четыре модуля размещены в двух каналах (режим Sequential)? Возможность параллельной записи и чтения, т. е. более низкую латентность подсистемы памяти при псевдослучайном обращении.

Далее все зависит от конкретной задачи (приложения, модели использования и т. п.) - к чему она чувствительна. На низком уровне мы имеем два контроллера памяти в микросхеме MCH, и каждый обслуживает по два канала. Если у нас четыре модуля в двух каналах, то один из контроллеров не работает. Исходя из вышесказанного, максимальная производительность системы должна достигаться при наличии восьми модулей. Но это в теории, в реальности же все не так хорошо. Тем не менее из тестов очевидно, что система на четырехъядерных процессорах заметно лучше утилизирует режим работы с восемью модулями.

Выводы

Главное, что четырехъядерный процессор Intel Xeon 53xx - несомненно, очень удачный продукт, в некоторой степени даже опередивший свое время. К сожалению, проявить себя в полной мере в таких пакетах, как "1С:Предприятие 7.7", он просто не имеет шансов. Так что покупать "четырехъядерник" под эту платформу может оказаться не совсем оправданным решением. Совсем другое дело "1С:Предприятие 8" - его современная, многопотоковая, распараллеливаемая клиент-серверная архитектура позволяет выжать максимум из увеличения количества ядер. То же касается и MS SQL Server 2005.

Таким образом, можно сделать первый, вполне логичный вывод - современные программные платформы для достижения максимальной эффективности требуют современных же аппаратных решений, и серверы на четырехъядерных процессорах Intel Xeon 53xx как раз и отвечают всем этим требованиям. Да, частота имеет значение, особенно в монопольном режиме. Но при большом количестве потоков она уже не является определяющим фактором - удвоенное число ядер дает лучший результат.

Вывод второй, относящийся не только к процессору, но и к платформе в целом. Intel учла все рекомендации, сделанные в адрес Pentium D и Xeon 50xx, так что новый четырехъядерный процессор, также созданный путем объединения двух CPU на одной подложке, фактически не имеет проблем с доступом к общим ресурсам оперативной памяти. Более того, он лучше, чем его двухъядерный собрат, умеет использовать ту же самую память, что хорошо заметно в режимах четырех и восьми модулей. И здесь рекомендации очевидны - если уж вы покупаете систему на четырехъядерных процессорах, не забудьте поставить как минимум четыре модуля памяти FB-DIMM, а лучше - восемь.

Вывод третий скорее относится к системам на двухъядерных процессорах. Как показывают наши тесты, установка восьми модулей памяти FB-DIMM отнюдь не всегда приводит к повышению производительности, что тоже нетрудно заметить по тестам. И здесь рекомендации традиционны - перед покупкой техники желательно провести на ней хотя бы минимальные тесты на ваших "живых" приложениях и "боевых" базах данных - вполне может оказаться, что такой апгрейд будет противопоказан их не самым современным версиям.

Ну и в заключение немного личных впечатлений. Более чем за три месяца "общения" с системами на четырехъядерных процессорах Intel Xeon 53xx и сравнения их с конфигурациями на двухъядерных Intel Xeon 51xx (и не только в пределах данного тестирования) у автора сложилось устойчивое мнение: "Для большинства задач "правильный" Xeon - четырехъядерный Xeon". Как минимум до появления на рынке новых моделей с еще большим количеством ядер.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365