Почему с нашей 64-битной сборкой Apache нет улучшения использования процессора?

Question

G'day,

Мы создали 64-битную сборку Apache 2.2.14 и развернули ее на различных серверах Sun, работающих под управлением Sol10. Для тестирования используются следующие типы серверов: Sun T2000 (32 ГБ памяти), 5120 (8 ГБ) и 5240 (16 ГБ).

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

Мы подтвердили это наблюдение, откатившись на 32-битную версию и затем снова вернувшись к 64-битной сборке. Поскольку это крупная веб-ферма, у нас имеется обширная инфраструктура мониторинга серверов с графиками RRD для всех видов измерений. Графики доступны для ежедневных, еженедельных, ежемесячных и годовых периодов. На этих графиках заметны небольшие изменения в загрузке процессора,

Частота обращений на наших серверах циклична в течение дня, но остается достаточно стабильной с пиками порядка 2 К / сек на сервер. Число детей также циклично в день и колеблется от 1 до 3 тыс. На сервер. Поскольку все серверы находятся за слоем баланса нагрузки, изменение шага не может быть связано с изменениями частоты обращений или дочерних элементов.

Мы использовали компилятор CC, который поставляется с Sunstudio 12.1, используя следующие флаги компиляции. Флаги ссылок аналогичны, но без определения -D.

export CFLAGS="-xopenmp=parallel -xalias_level=basic \
    -xtarget=ultraT1 -m64 -xarch=sparc -xbuiltin=%all \
    -xdepend -xmemalign=8s -xO5 -xprefetch=auto,explicit" \
    -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64

Мы не делаем ничего необычного в конфигурации Apache, и это довольно ванильно.

Редактировать: Производительность определялась по соотношению ЦП и запросов в сравнении с памятью (в этом порядке). 64-битный выполнял меньше запросов с тем же процессором и немного увеличил объем памяти. Разница была в пределах погрешности и стала заметной только при полной загрузке

Я прочитал вопрос " Как разрабатывать, чтобы использовать преимущества 64-битных систем? ", и там есть некоторая интересная информация. Похоже, это в основном проблемы, связанные с

1. адресация памяти вне предела 4 ГБ 32-битного адресного пространства,
2. манипулирование 64-битными значениями.

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

Какие-либо предложения относительно того, почему наша производительность не улучшилась?

Или предложения на что посмотреть?

Должны ли мы на самом деле увидеть улучшение производительности?

Answer 1

Помимо работы с большими объемами памяти, единственным преимуществом x86_64 по сравнению с 32-битным двоюродным братом является более богатый набор регистров. Это должно означать, что тяжелый код процессора может быть более эффективным, поскольку он должен поддерживать меньшее состояние в относительно медленной основной памяти. Однако этому часто противостоит повышенное использование памяти, поскольку все указатели теперь занимают вдвое больше места.

Как правило, при наличии достаточного количества памяти для этого я ожидаю, что проблемы с процессором будут работать лучше, чем 64-битные приложения. Однако веб-обслуживание часто является проблемой, связанной с вводом / выводом, и это не поможет (и, возможно, помешает, если машина находится под избыточным давлением памяти).

Вы, вероятно, хотите профилировать свой компьютер (oprofile в Linux, не уверен, что такое эквивалентный инструмент Solaris) и посмотреть, где на самом деле находятся горячие точки процессора.

Answer 2

Используете ли вы 64-битные оптимизированные алгоритмы? Оптимизирована ли ваша библиотека SSL под 64-битную версию, а библиотека ssl скомпилирована для этой архитектуры? Простая компиляция 32-битного кода в 64-битном не даст большого эффекта, потому что большинство 32-битного кода даже не использует оптимизируемые функции.