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 тоже внятных комментариев нет.

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

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

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

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

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

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

Deleted ()

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

Bad_ptr ★★★★ ()
Последнее исправление: Bad_ptr (всего исправлений: 1)
Ответ на: комментарий от 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 ★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

iljuase ★★ ()