Проблемы с прокладкой
АрхивЭволюция и естественный отбор в мире серверов привели к тому, что до наших дней дожили только те экземпляры, архитектура которых очень неплохо сбалансирована.
— В вашей машине проблемы с прокладкой.
— Какой прокладкой?
— Между рулем и сиденьем.
Авторемонтный юмор
«Вас много, а я одна». — Большое количество клиентов, с аппетитом использующих серверные ресурсы, может запросто посадить производительность самой мощной машины ниже всякого приемлемого уровня. И знание проблемных участков серверной архитектуры бывает очень полезно. Прежде всего — для экономии денег. Вместо того чтобы бросаться покупать новый сервер, стоит попытаться расшить узкие места в существующей конфигурации. Результатов можно добиться просто фантастических. Народным «серверным эпосом» стала история, как некая команда разработчиков путем подкрутки опций компилятора сумела запросто повысить производительность своего приложения на порядок. А потом, после изменения несколько строчек кода, — еще раза в два.
Эволюция и естественный отбор в мире серверов привели к тому, что до наших дней дожили только те экземпляры, архитектура которых очень неплохо сбалансирована. Но «узким местом» может стать любой компонент, в зависимости от конкретных условий. Процессоры, память, шины, контроллеры, дисковая подсистема, сеть — любое из перечисленного годится в качестве тормоза на пути роста производительности.
Дисковая подсистема
Исторически проблемная часть, особенно у файловых серверов и серверов баз данных. В книжке «Sun Performance Tuning», посвященной настройке производительности серверов баз данных, гуру Адриан Кокрофт (Adrian Cockcroft) приводит десять советов по устранению узких мест. Совет номер один: если у вас все работает медленно, обратите внимание на диски. Попробуйте расшить это узкое место путем страйпинга — увеличения числа дисков, на которые параллельно ведется запись. Второй совет: если по-прежнему все работает плохо, повнимательнее посмотрите на диски. И так далее. Дискам посвящены первые четыре совета из десяти. И лишь потом идут рекомендации по выискиванию иных узких мест. Казалось бы, сегодня дисковая память дешева как никогда и каким бы то ни было проблемам здесь не место. Но нет, далеко не все последние тенденции радуют производителей серверов. Павел Анни, менеджер по продуктам Sun Microsystems, обращает внимание на то, что диски очень быстро растут в емкости, но почти не растут в производительности: «Любой домашний пользователь только рад, что сегодня он за те же деньги может купить диск вдвое большего объема, чем год назад. А для нас это проблема. Лет семь назад для базы данных объемом, скажем, в полтораста гигабайт мы делали дисковый массив из четырехгигабайтных дисков, и все работало очень быстро, потому что запись распараллеливалась на страйпах. Сегодня для этой базы данных клиент берет уже только два диска по восемьдесят гигабайт, думая, что у него все будет хорошо. А потом удивляется, что все так медленно работает». Дмитрий Пенязь, менеджер направления серверных решений департамента корпоративных решений компании Hewlett-Packard, советует «пустить воду в бассейн по всем трубам» — задействовать страйпинг везде, где только можно: «Например, можно сделать страйпинг внутри RAID-массива, посадить два RAID-контроллера на разные слоты PCI и устроить страйпинг между ними на уровне операционной системы, а также использовать средства распределения нагрузки на уровне приложения, например СУБД». Эта же рекомендация, кстати, распространяется и на память — ведь ее в сервер можно набить, используя модули разной емкости. Наивысшая производительность достигается, когда оказываются занятыми все слоты, — конечно, недостаток такой конфигурации заключается в невозможности далее наращивать объем памяти без замены модулей.
Шины машины
Исторически узкое место серверов — каналы ввода-вывода. Чем они шире, тем больший объем данных удается затащить в память или процессор за такт. Но тем больше накладные расходы на перекачку лишнего объема данных. Существует иерархия обращения к данным: наиболее быстро процессор берет их, естественно, из своих собственных регистров. Затем по скорости доступа следуют кэши первого-второго-третьего уровня, потом память на плате данного процессора (в NUMA-системах), память из другой процессорной ячейки, дисковая память, ленточные и CD-ROM-накопители. «Есть простое правило анализа производительности систем: для этого компьютер следует рассматривать как систему каналов, по которым передаются данные, — говорит глава аналитической компании Elashkin Research Михаил Елашкин. — Одно узкое место — и сразу затор. Если какой-то модуль имеет избыточную производительность, это означает выброшенные деньги: ты заплатил за то, что тебе не нужно. Поэтому современные системы, как правило, очень хорошо сбалансированы». Баланс достигается различными способами. Можно, например, оптимизировать работу выделенного контроллера памяти, а можно вовсе перенести этот контроллер в кристалл процессора, как сделано в новых процессорах Sun Microsystems. Однако у каждого хорошего решения есть оборотная сторона: объединенный с процессором контроллер налагает жесткие ограничения на тип используемой памяти, затрудняя ее апгрейд.
Сводя баланс
Подобно тому, как в сбалансированных на заводе весах все равно имеется винтик для точной настройки на месте, в серверах всегда найдется, что подкрутить для увеличения производительности. Все зависит от конкретной задачи, для решения которой используется сервер. Разные задачи — разные требования, в том числе и к аппаратной части. Например, к объему данных, выбираемых процессором из кэша за один такт — cache line. «Очень большое значение имеет нахождение баланса между размером cache line и полосой пропускания, которую дает чипсет, — подчеркивает Дмитрий Пенязь. — Если процессор оперирует с большими идущими подряд кусками памяти (такое встречается при обработке потоковых данных), выгоден большой размер cache line, потому что он позволяет увеличить полосу пропускания. Если нужно взять в нескольких местах памяти по одному байту — лучше малый размер cache line. Как правило, системы с большим cache line показывают очень хорошие результаты в индустриальных тестах TPC-С, но имеют неравномерную характеристику производительности в реальных задачах». Объем считываемых с диска данных за один раз — размер кластера — также нуждается в индивидуальном подборе в зависимости от задачи. Для «усредненного» сервера оптимальным считается размер кластера 16 Кбайт. Для SQL Server и других СУБД — 64 Кбайт. Все это настраивается на уровне как операционной системы, при форматировании томов, так и на более высоких уровнях, — СУБД также оперирует кластерами данных определенного объема. «Первое правило — нужно максимально выровнять размер записи и размер кластера, чтобы по возможности исключить ситуацию, когда граница записи приходится на середину кластера, в этом случае будет переноситься лишний объем информации», — отмечает Дмитрий Пенязь.
Проблему с настройкой и подгонкой размеров кэшей, кластеров, записей и прочих кусков информации обобщает Михаил Елашкин, выделяя из нее очень важный момент, на который мало кто обращает внимание: «Возьмем, к примеру, тест TPC-C, который показывает наивысшие результаты, если его задачи помещаются в кэш процессоров целиком. Это хорошо для стандартного теста, который изучен вдоль и поперек, но мало помогает в реальных задачах. При этом часто складывается интересная ситуация, когда программист искренне считает, что он все оптимизировал. Системный администратор тоже уверен в том, что он все настроил, но общая производительность системы может быть любой. Если задача поместилась в кэш, то система практически превратилась в кэш-машину, скорость которой зависит только от одного параметра. Гораздо сложнее, когда задача не может разместиться в кэше. А ведь современные серверы имеют множество процессоров, операционная система, обеспечивающая многозадачность, переключает процессоры. Кэши процессоров необходимо синхронизовать. И не забудьте, что современные серверные процессоры — и RISC и Itanuim — предсказывают дальнейшее поведение программы и соответственно оптимизируют исполнение. Вот это самое место — тонкая прослойка между софтом и «железом» — имеет очень большое значение для увеличения производительности серверов.
Конечно, производители серверов, процессоров, СУБД и компиляторов делают все возможное, чтобы эти проблемы разрешались автоматически, но нельзя предусмотреть все варианты. Только человек способен проанализировать все грани производительности системы в реальном приложении, но это очень трудная задача, требующая высочайшей квалификации».
Уходим в софт
Мягкая стыковка «железа» и ПО, позволяющая выжать максимум из ресурсов сервера, представляет собой серьезную проблему. Специалисты в области сайзинга — измерения производительности серверов — утверждают, что вопрос победы различных серверов в состязаниях по производительности (например, тестах TPC) во многом является вопросом настроек.
А что, если перенести проблему взаимодействия софта и «железа» большей частью (целиком, конечно, не получится) в софт? Именно по такому пути, но разными маршрутами, идут практически все разработчики серверных процессоров. Разработчики процессора Itanium — Hewlett-Packard и Intel — во многом перенесли акценты в увеличении производительности с кристалла на компилятор. А менять компилятор проще, чем блок в процессоре. И поле для экспериментов здесь несравненно шире: можно поправить кусок кода и посмотреть, что из этого выйдет, но нельзя ради любопытства изменить десяток регистров в кристалле.
Поскольку современная серверная архитектура — это конструктор, собираемый под конкретную задачу, то узкие места в нем создает тот, кто собирает данную конфигурацию. Использовал Ethernet там, где нужен Fiber Channel, — вот тебе и затык в производительности. Неправильно выставил размер кластера — сервер спотыкается на ровном месте. Самым узким местом в сервере является серое вещество разработчика. Только в отличие от массовых ПК этот критически важный участок находится гораздо ближе к заказчику.
