LINUX.ORG.RU

Патчи от Spectre\Meltdown на Oracle Linux снижают производительность в два раза при импорте баз данных с помощью impdp

 , , ,


1

3

Привет. Хочу поделиться своим горьким опытом установки патчей от Spectre\Meltdown на Oracle Linux. Возможно, у кого-то есть такой же негативный опыт и советы. Просто поплакаться, короче.

Для начала, железо:

Blade: HP-Blade ProLiant BL660c Gen9
CPU: 2x Intel(R) Xeon(R) CPU E5-4667 v3 @ 2.00GHz (2 сокета, в сумме 32 ядра и 64 потока)
RAM: 256 GB (16 планок по 16 GB)
Дисковая подсистема не имеет значения, думаю.  Ну там SSD (RAID 1) и овермного дисков приходят со стораджа по multipath.

ОС: Oracle Linux 7.3,  4.1.12-124.17.2.el7uek.x86_64.

На сервере, как не сложно догадаться, крутится много баз данных Oracle. Я не dba-специалист и не могу предоставить больше данных, но база 12 версии вроде.

Решил я обновить систему, значит. Для начала, поставил Service Pack for ProLiant (SPP) 2018.3.0 (это pack, включающий firmware upgrade для всего оборудования). Потом сверху накатил свежий ROM 2.60 (чтобы закрыть установить все доступные патчи от Spectre). Ядро обновляется автоматом (Oracle Uptrack).

Идея такая, что на сервере каждый день проходит рефреш базы данных (т.е. копируется дамп базы данных с другого сервера и заливается этот дамп с помощью impdp).

Ранее импорт базы данных занимал примерно 6 часов и 30 минут. После установки апдейтов рефреш стал длиться 12 часов. impdp работает в 8 потоков. Увеличение кол-ва потоков до 16-ти никак не помогли ускорить процесс рефреша.

Недолго думая (я немножко слежу за новостями и сразу понял, что проблема может быть в заплатках от MelDown) я отключил ibpb\ibrs патчи:

echo '0'>/sys/kernel/debug/x86/ibpb_enabled
echo '0'>/sys/kernel/debug/x86/ibrs_enabled

и длительность рефреша вернулась на прежний уровень, т.е. дело точно в ibpb_enabled и ibrs_enabled.

CPU Utilization\CPU Load на севрере низкое, т.е. свободных ресурсов полно на сервере.

Oracle Support не даёт никаких нормальных комментариев (у нас платный support на ОС и на базы данных), от HP-Support тоже внятных комментариев нет.

В общем, вот моя история. Хотелось бы услышать комментариев или советов. И ваш горький опыт.

★★★

Последнее исправление: iljuase (всего исправлений: 1)

Ответ на: комментарий от post-factum

думаю мне потом по шапке дадут на работе, типа раскрытие конфиденциальной информации и т.д. :-)

Так что извини.

iljuase ★★★
() автор топика
Ответ на: комментарий от anonymous

Данные с конкретного хоста, на котором начались проблемы после установки патчей.

iljuase ★★★
() автор топика
Ответ на: комментарий от Deleted

Ачо, куча всевозможных аппаратных дыр, найденных до этогоднего хайпа вокруг Spectre/Meltdown и соответствующего класса «уязвимостей» в целом, не считается? Их так-то обновлениями микрокода латали, но сути не меняет же.

bodqhrohro_promo
()
Последнее исправление: bodqhrohro_promo (всего исправлений: 1)
Ответ на: комментарий от bodqhrohro_promo

Единственный толк от поддержки — это лицензия на HardWare. Если сломалась батарея от RAID, диск, сет. карта или что-то ещё — можно создать тикет и инженеры всё бесплатно и быстро заменят в твоём DC удалённо.

Лицензия на RedHat Linux, скорее, нужна, чтобы успокоить кастомера. Лицензия на Oracle Linux тоже нужна, чтобы просто повысить свой авторитет перед кастомером. Типа 'смотрите, у нас вендор саппорт есть, если что-то сломается, то нам помогут, ыыыыыы', или 'я прав, смотрите, Вендорский саппорт подтвердил, я не идиот, ыыыыыыы'. Ну иногда лень гуглить, можно початится (в случае с HP).

Ну и когда работаешь по модели оутсорсинга, за всё платит кастомер, денег не жалко. Пусть платит, в RedHat тоже кушать хотят.

iljuase ★★★
() автор топика
Ответ на: комментарий от das_tier

Не, ну я знал, что капитализм — копроэкономика, но когда даже вещаемая GPL-фанатиками альтернативная монетизация опенсорса разбивается о суровую реальность — прецедент становится опасным.

bodqhrohro_promo
()
Ответ на: комментарий от iljuase

в твоём DC
удалённо

Это как? Сами припрутся? А если DC за тридевять земель?

Ну иногда лень гуглить, можно початится

Так это и на фриноде можно.

Ну и когда работаешь по модели оутсорсинга, за всё платит кастомер, денег не жалко. Пусть платит, в RedHat тоже кушать хотят.

Вот вам и теория заговора, на линуксоедов и так уже косо смотрят благодаря калишкольникам.

bodqhrohro_promo
()
Ответ на: комментарий от das_tier

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

anonymous
()

Это очень печально, если правда. Я на своем железе/софте на дебиане и убунте разницы вообще не заметил. Они правда в виртуалках.

Там жабософт крутится и мускуль.

Deleted
()
Ответ на: комментарий от Deleted

а тебя не смущает тот факт, что обновления прошивок от hp на железо от hp, а виноват почему-то оракель? тем более что ведро редхатовкое, а не оракла.

anonymous
()
Ответ на: комментарий от anonymous

чёт протупил с утра насчёт ведра, тогда вопрос к тс, ты на другом ядре грузился, от редхата, например?

anonymous
()
Ответ на: комментарий от anonymous

Я тред не читал и мне все равно кто виноват. Печален сам факт заметных тормозов из-за фиксов всех этих фантомных(?) уязвимостей.

Deleted
()
Ответ на: комментарий от anonymous

Только так и работает. Иначе вообще нет смысла :)

das_tier ★★★★★
()
Ответ на: комментарий от anonymous

Нет. Чтобы ребутнуть севрер, надо договориться с ~20 людьми (большинство из них — менеджеры). И надо будет доказать, что с ядром Redhat не будет проблем или будут улучшения. Если будут доказательства, то, возможно, удастся ребутнуть.

Но пока доказательств нет. Нам нельзя просто ребутать серваки «для интереса», реалии оутсорсинга...

iljuase ★★★
() автор топика
Ответ на: комментарий от bodqhrohro_promo

Это как? Сами припрутся? А если DC за тридевять земель?

Да. Я работаю в России, а серверы в Европе находятся в DC. Если что-то ломается, создаю заявку на HP, приходит индус в DC и сам всё чинит.

iljuase ★★★
() автор топика
Ответ на: комментарий от iljuase

А тестовых окружений нет штоле?

Но пока доказательств нет. Нам нельзя просто ребутать серваки «для интереса», реалии оутсорсинга...

это реалии любого бизнеса серьёзнее чебуречной или очередного стартапчика, тестовый стенд надо иметь.

anonymous
()
Ответ на: комментарий от anonymous

Я про тесторвые среды и пишу. ROM и FirmWare были обновлены на тестовой среде, а не на прод

Но тут у нас люди такие, кхм, что даже для ребута тестовой среды надо получить одобрение ~20-ти человек. Типа тестовая среда критичная для бизнеса.

iljuase ★★★
() автор топика
Ответ на: комментарий от iljuase

Я имел ввиду тестовую среду с которой можно делать относительно что угодно, лаба, если так понятнее, чтобы вот таких историй не приключалось.

anonymous
()
Ответ на: комментарий от anonymous

На живой есть костылики, смягчающие боль. Там по ссылке вроде про отсутствие PCID писали, если я правильно понял.

anonymous
()
Ответ на: комментарий от anonymous

Ну и как, сильно мягче от костылей?

anonymous
()
Ответ на: комментарий от iljuase

Но тут у нас люди такие, кхм, что даже для ребута тестовой среды надо получить одобрение ~20-ти человек. Типа тестовая среда критичная для бизнеса.

И это вполне обоснованно. К примеру, пригласили они специалиста от вендора с почасовой оплатой. И он работает на тестовой системе. А тут вдруг раз - и системный администратор тестовую систему перезагрузил. И полдня работы дорогого специалиста псу под хвост.

bigbit ★★★★★
()
Последнее исправление: bigbit (всего исправлений: 1)
2 сентября 2018 г.

l1tf=off nopti nospectre_v2 nospec_store_bypass_disable

В параметры ядра, и задом перед левым кодом не вилять.

anonymous
()
Ответ на: комментарий от anonymous

Но это влияет только на сисвызовы, CPU-bound код работает как работал. Думаю тупо выпустят новую ревизию чётотам-лейка безо всяких просадок.

anonymous
()
2 ноября 2018 г.

upd: если кому интересно, то причина оказалось в типе миграции от Spectre V2. Вот эти миграции от Intel сильно сажают перфоманс: ibpb и ibrs. А есть более хороший тип миграции от разработчиков ядра (софтварный) — retpoline https://blogs.oracle.com/linux/an-update-on-retpoline-enabled-kernels-for-ora... Но чтобы он начал работать — нужно сделать так, чтобы все модули ядра были скомпилированы с помощью retpoline, иначе применится другой тип миграции. Пример:

[vodka@vodka-PC-CentOS ~]$ modinfo vmwgfx
filename:       /lib/modules/3.10.0-862.3.2.el7.x86_64/kernel/drivers/gpu/drm/vmwgfx/vmwgfx.ko.xz
[..]
author:         VMware Inc. and others
retpoline:      Y

У нас три модуля ядра, относящиеся к базам Oracle, были скомпилированы без этой поддержки, поэтому были проблемы с перфомансом. Оракл поркомендовал установить патч 28069955 чтобы решить проблему.

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

Если я буду ещё жив и работать в этой же конторе — я поделюсь результатми в марте 2019 после патчинга, если не забуду.

iljuase ★★★
() автор топика
Ответ на: комментарий от iljuase

upd: Retpoline работает только на процессорах до SkyLake. Но при этом ibpb и ibrs не так сильно влияют на перфоманс в CPU семейств SkyLake и выше. Поэтому деградация производительности примерно одиакновая на всех процессорах, если применён правильный тип.

iljuase ★★★
() автор топика
5 февраля 2019 г.
Ответ на: комментарий от iljuase

После установки патча 28069955 на Oracle Grid все модули ядра Linux стали поддерживать миграцию Retpoline и она активировалась после перезагрузки сама.

Производительность баз вернулась в норму. Проблема была в типе миграции к Spectre V2. Retpoline почти не влияет на перфоманс.

Если есть вопросы — спрашивайте.

iljuase ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.