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)
Ответ на: комментарий от Deleted

У нас AMD не любят, к сожалению. И в целом мы работает по модели оутсорсинг, т.е. просто обслуживаем готовые серверы. Влиять на процесс выбора железа мы не можем.

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

У нас AMD не любят, к сожалению

Тогда получайте удовольствие от глобального и надёжного Интела, что тут ещё можно сказать. Ну или отключайте заплатки этих дырищ и надейтесь, что никто не ломанёт))

Deleted
()

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

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

О ненайденных дырах поговори с адептами чайника Рассела и невидимых розовых единорогов.

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

Молодец, что наконец-то загуглил. А spectre?

router ★★★★★
()

У меня есть и хорошие новости. На оффтопике-10 всё тоже очень плохо. Особенно мелкоблочный I/O

anonymous
()

А если сравнить логи impdp до и после, то на что время стало уходить - на сам импорт или на создание индексов?

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

Так Spectre это вектор атак, у него куча конкретных версий.

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

вот логи рефреша (кастомный python-скрипт):

INFO     [2018-07-21 04:25:03,250]  ======================= START
[LINE:114]# INFO     [2018-07-21 04:25:03,251]  Refresh for TOP_SECRET
[LINE:118]# INFO     [2018-07-21 04:25:03,255]  Check if export completed successfully
[LINE:134]# INFO     [2018-07-21 04:25:03,690]  Export started at Fri Jul 20 21:00:01 2018
[LINE:135]# INFO     [2018-07-21 04:25:03,690]  Export finished successfully at Sat Jul 21 02:07:03 2018 elapsed 05:06:52
[LINE:136]# INFO     [2018-07-21 04:25:03,690]  We can proceed
[LINE:137]# INFO     [2018-07-21 04:25:03,691]  Starting dump file copy
[LINE:150]# INFO     [2018-07-21 04:47:38,942]  Dump file have copied sucssfully, elapsed time: 0:22:35
[LINE:151]# INFO     [2018-07-21 04:47:38,942]  Application deleting
[LINE:172]# INFO     [2018-07-21 04:47:38,943]  Deleting TOP_SECRET:
[LINE:173]# INFO     [2018-07-21 04:47:38,943]  Generate SQL script to delete SECRET
[LINE:179]# INFO     [2018-07-21 04:47:47,249]  Generate SQL script to delete SECRET completed, elapsed time: 0:00:08
[LINE:180]# INFO     [2018-07-21 04:47:47,249]  Generate SQL script to delete CONFEDINTIAL
[LINE:186]# INFO     [2018-07-21 04:47:52,206]  Generate SQL script to delete CONFEDINTIAL completed, elapsed time: 0:00:04
[LINE:188]# INFO     [2018-07-21 04:47:52,206]  Execute SQL script to delete SECRET
[LINE:199]# INFO     [2018-07-21 05:21:45,765]  SQL script to delete SECRET completed, elapsed time: 0:33:53
[LINE:200]# INFO     [2018-07-21 05:21:45,766]  Execute SQL script to delete CONFEDINTIAL
[LINE:211]# INFO     [2018-07-21 05:28:49,004]  SQL script to delete CONFEDINTIAL completed, elapsed time: 0:07:03
[LINE:248]# INFO     [2018-07-21 05:28:49,005]  Starting import
[LINE:264]# INFO     [2018-07-21 16:22:16,508]  Import finished at Sat Jul 21 16:22:11, elapsed 10:53:11
[LINE:267]# INFO     [2018-07-21 16:22:16,509]  Refresh completed
[LINE:293]# INFO     [2018-07-21 16:22:16,509]  Sending mail
[LINE:294]# INFO     [2018-07-21 16:22:16,509]  Refresh took: 11:57:13 sec
[LINE:295]# INFO     [2018-07-21 16:22:16,509]  ======================= FINISH


INFO     [2018-07-22 02:35:01,916]  ======================= START
[LINE:114]# INFO     [2018-07-22 02:35:01,917]  Refresh for TOP_SECRET
[LINE:118]# INFO     [2018-07-22 02:35:01,919]  Check if export completed successfully
[LINE:134]# INFO     [2018-07-22 02:35:02,210]  Export started at Fri Jul 20 21:00:01 2018
[LINE:135]# INFO     [2018-07-22 02:35:02,211]  Export finished successfully at Sat Jul 21 02:07:03 2018 elapsed 05:06:52
[LINE:136]# INFO     [2018-07-22 02:35:02,211]  We can proceed
[LINE:137]# INFO     [2018-07-22 02:35:02,211]  Starting dump file copy
[LINE:150]# INFO     [2018-07-22 02:58:17,987]  Dump file have copied sucssfully, elapsed time: 0:23:15
[LINE:151]# INFO     [2018-07-22 02:58:17,987]  Application deleting
[LINE:172]# INFO     [2018-07-22 02:58:17,988]  Deleting TOP_SECRET:
[LINE:173]# INFO     [2018-07-22 02:58:17,988]  Generate SQL script to delete SECRET
[LINE:179]# INFO     [2018-07-22 02:58:23,222]  Generate SQL script to delete SECRET completed, elapsed time: 0:00:05
[LINE:180]# INFO     [2018-07-22 02:58:23,223]  Generate SQL script to delete CONFEDINTIAL
[LINE:186]# INFO     [2018-07-22 02:58:25,032]  Generate SQL script to delete CONFEDINTIAL completed, elapsed time: 0:00:01
[LINE:188]# INFO     [2018-07-22 02:58:25,033]  Execute SQL script to delete SECRET
[LINE:199]# INFO     [2018-07-22 03:24:47,691]  SQL script to delete SECRET completed, elapsed time: 0:26:22
[LINE:200]# INFO     [2018-07-22 03:24:47,691]  Execute SQL script to delete CONFEDINTIAL
[LINE:211]# INFO     [2018-07-22 03:29:44,536]  SQL script to delete CONFEDINTIAL completed, elapsed time: 0:04:56
[LINE:248]# INFO     [2018-07-22 03:29:44,536]  Starting import
[LINE:264]# INFO     [2018-07-22 09:24:07,172]  Import finished at Sun Jul 22 09:24:02, elapsed 05:54:02
[LINE:267]# INFO     [2018-07-22 09:24:07,172]  Refresh completed
[LINE:293]# INFO     [2018-07-22 09:24:07,172]  Sending mail
[LINE:294]# INFO     [2018-07-22 09:24:07,173]  Refresh took: 6:49:05 sec
[LINE:295]# INFO     [2018-07-22 09:24:07,173]  ======================= FINISH

Логи impdp постараюсь найти, но не гарантирую результат.

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

Насколько я знаю, база дампится (создаётся) на Exadata. А импорт идёт на Oracle Linux. Возможно, есть какие-то ограничения с совместимостью (Exadata старая). Поэтому используют impdp.

Я не DBA-специалист.

iljuase ★★★
() автор топика

Вот планируемое устаревание постучалось и к процессорам… Маркетинг рулит миром!
Уверен — в скором времени будут найдены уязвимости, для устранения которых нужно будет пожертвовать 70 % производительности ЦП.

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

RedHat support не лучше... Я как-то открыл тикет, мне ответили неправильно. Я начал спорить и оказался прав, RedHat support извинился потом. А я мог бы систему убить их советами...

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

Конкретно здесь он пишет о патчах против Spectre.

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

Не нужно ничего планировать, когда 80% всего - говно по дефолту.

anonymous
()

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

А что они могут прокомментировать то?

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

Возьместить ущерб. Ведь они рекламируют свои сервера как безопасные, высокопроизводительные и надёжные.

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

Ну хотя бы что-то типа 'да, сорян, это из-за патчей от Spectre, ничего сделать нельзя, сорян ещё раз' и т.д.

Сейчас они вообще не дают никаких комментариев, не могли подтвердить\опровергнуть, что это из-за патчей от Spectre (пришлось нам самостоятельно проделать ещё эксперименты на второй ноде кластера, чтобы подтвердить вышенаписанное). Также мы им задавали вопросы типа «есть ли у вас тесты производительности до применений патчей от Spectre и после», они не ответили.

+ неделю гнали на то, что проблема с утилитой impdp, а не из-за наших патчей.

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

Ну сервер у нас от HP, только ОС и ПО от Oracle. (да-да, я знаю, что Oracle Linux — это чуть переделанный RedHat).

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

Ну или вот мы используем их ядро (UEK), вдруг со стандартным ядром будет получше, мы же не знаем, что там Oracle накрутил... Или посоветовать UEK5.

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

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

Даже ответ 'сорян, но ничего поделать нельзя' нас бы устроил.

А, они даже этого не ответили?

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

поддержу оратора с rman, енти ваши expdp и impdp дампят всю базу, хотя достаточно инкрементала, это раз, создают кучу лишней нагрузки в виде чтения всех блоков базы, вместо чтения с бекапов (они ведь есть у вас?), это два, ну и на импорте генерится куча лишних логов. expdp хорош, когда надо схему/таблицу экспортнуть или или только ddl и dml без данных.

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

rman не подходит

ME, [22.07.18 23:50]
слушай, а зачем при рефреше базы [SECRET] вместо rman вы используете impdp и expdp?

DBA engineer, [23.07.18 00:02]
Потому что только схема одна меняется, а не вся база
iljuase ★★★
() автор топика

Oracle Support не даёт никаких нормальных комментариев

Какие ещё нужны комментарии? О том, что и почему производительность просядет все знали заранее.

Простой способ не переживать - не запускать на серверах недоверенный код. Вероятно, это означает запрет plsqlных и прочих jaвных процедур, Ну и правильно - цена ораклёвых лицензий намекает на это достаточно давно и недвусмысленно.

DonkeyHot ★★★★★
()

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

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

на оффтопике помоему файловый ио вообще всегда был жопой.

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

Еще impdp импортирует только данные, а индексы пересоздает заново. На это много времени может уходить. Поэтому я и спрашивал выше, на что стало уходить время - на создание индексов или на сам импорт.

bigbit ★★★★★
()
Ответ на: rman не подходит от iljuase

Обычно одна схема == одно приложение.
Но бывает, что пытаются сэкономить и запихивают в одну базу данных несколько Оракловых схем для нескольких инстансов приложения. Особенно если схемы маленькие (а потом они вырастают...) и особенно часто на тестовых серверах такое делают.

У вас случайно не такая ситуация? :) Если да, то можно предложить DBA нормально сделать для каждой схемы отдельную БД и тогда можно будет использовать RMAN.

bigbit ★★★★★
()
Последнее исправление: bigbit (всего исправлений: 7)

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

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

скорее всего случай такой, да. «Как сделать» решаем не мы, увы (мы просто обслуживаем готовое и выполняем приказы, оутсорсинг).

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

Вот сейчас может долдёмся хоть какого-нибудь ответа от Оракл саппорта и предложим кастомеру отключить патчи навсегда, если он возьмёт на себя риски, связанные с безопасностью. Сетка изолирвоанная, Серверы располагаются в арендуемом Дата-Центре.

Но это опят решаем не мы (оутсорсинг), мы можем дишь предложить 'наше экспертное мнение'.

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

В том же PostgreSQL можно использовать не только его диалект SQL, но и несколько других ЯП. Тут, возможно, тоже.

anonymous
()

Это жестоко, конечно... то есть сначала переплатили за производительность от Intel, а потом... дааа

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

Графики дисковой подсистемы: https://imgur.com/a/oWPyiW4

23-го июня было обновление. На графиках видны изменения, но, возможно, просто из-за замедления процессора кол-во I\O в промежуток времени уменьшился и из-за этого различия в графиках.

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