Проблемы с прокладкой 19.08.2003 Михаил Попов
Сводя баланс Подобно тому, как в сбалансированных на заводе весах все равно имеется винтик для точной настройки на месте, в серверах всегда найдется, что подкрутить для увеличения производительности. Все зависит от конкретной задачи, для решения которой используется сервер. Разные задачи — разные требования, в том числе и к аппаратной части. Например, к объему данных, выбираемых процессором из кэша за один такт — cache line. «Очень большое значение имеет нахождение баланса между размером cache line и полосой пропускания, которую дает чипсет, — подчеркивает Дмитрий Пенязь. — Если процессор оперирует с большими идущими подряд кусками памяти (такое встречается при обработке потоковых данных), выгоден большой размер cache line, потому что он позволяет увеличить полосу пропускания. Если нужно взять в нескольких местах памяти по одному байту — лучше малый размер cache line. Как правило, системы с большим cache line показывают очень хорошие результаты в индустриальных тестах TPC-С, но имеют неравномерную характеристику производительности в реальных задачах». Объем считываемых с диска данных за один раз — размер кластера — также нуждается в индивидуальном подборе в зависимости от задачи. Для «усредненного» сервера оптимальным считается размер кластера 16 Кбайт. Для SQL Server и других СУБД — 64 Кбайт. Все это настраивается на уровне как операционной системы, при форматировании томов, так и на более высоких уровнях, — СУБД также оперирует кластерами данных определенного объема. «Первое правило — нужно максимально выровнять размер записи и размер кластера, чтобы по возможности исключить ситуацию, когда граница записи приходится на середину кластера, в этом случае будет переноситься лишний объем информации», — отмечает Дмитрий Пенязь.
Конечно, производители серверов, процессоров, СУБД и компиляторов делают все возможное, чтобы эти проблемы разрешались автоматически, но нельзя предусмотреть все варианты. Только человек способен проанализировать все грани производительности системы в реальном приложении, но это очень трудная задача, требующая высочайшей квалификации». Уходим в софт Мягкая стыковка «железа» и ПО, позволяющая выжать максимум из ресурсов сервера, представляет собой серьезную проблему. Специалисты в области сайзинга — измерения производительности серверов — утверждают, что вопрос победы различных серверов в состязаниях по производительности (например, тестах TPC) во многом является вопросом настроек. А что, если перенести проблему взаимодействия софта и «железа» большей частью (целиком, конечно, не получится) в софт? Именно по такому пути, но разными маршрутами, идут практически все разработчики серверных процессоров. Разработчики процессора Itanium — Hewlett-Packard и Intel — во многом перенесли акценты в увеличении производительности с кристалла на компилятор. А менять компилятор проще, чем блок в процессоре. И поле для экспериментов здесь несравненно шире: можно поправить кусок кода и посмотреть, что из этого выйдет, но нельзя ради любопытства изменить десяток регистров в кристалле. Поскольку современная серверная архитектура — это конструктор, собираемый под конкретную задачу, то узкие места в нем создает тот, кто собирает данную конфигурацию. Использовал Ethernet там, где нужен Fiber Channel, — вот тебе и затык в производительности. Неправильно выставил размер кластера — сервер спотыкается на ровном месте. Самым узким местом в сервере является серое вещество разработчика. Только в отличие от массовых ПК этот критически важный участок находится гораздо ближе к заказчику.
|