The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Значительное снижение производительности MyISAM при включении защиты от Meltdown

13.02.2018 23:54

Разработчики СУБД MariaDB предупредили о существенном снижении производительности хранилища MyISAM при использовании ядра Linux с патчами KPTI, блокирующими уязвимость Meltdown. Замедление операций сканирования строк в MyISAM после применения патчей KPTI составляет около 40%, а при отсутствии поддержки PCID может достигать 90%. Для избавления от подобного эффекта требуется полный редизайн MyISAM.

В качестве обходного пути для избавления от потери производительности рекомендуется перейти на использование хранилищ InnoDB или ARIA, попутно убедившись, что выставлен достаточно большой размер кэша обработки записей (Buffer Pool для InnoDB и Page Cache для ARIA). При размере кэша в 128M (по умолчанию для ARIA) потеря производительности не выходит за пределы 1%.

Также можно отметить корректирующий выпуск MariaDB 10.2.13, в котором хранилище InnoDB обновлено до выпуска 5.7.21 (перенесено из MySQL 5.7.21) и исправлено более 100 ошибок, в том числе устранено 6 уязвимостей, которые могли быть использованы для инициирования удалённого отказа в обслуживании. Началось формирование готовых пакетов c MariaDB для Fedora 27.

  1. Главная ссылка к новости (https://mariadb.org/myisam-tab...)
  2. OpenNews: Релиз ядра Linux 4.15
  3. OpenNews: Линус Торвальдс жестко раскритиковал связанные с микрокодом патчи Intel
  4. OpenNews: Эксплоиты и тесты производительности, связанные с уязвимостями Meltdown и Spectre
  5. OpenNews: Раскрыты подробности двух атак на процессоры Intel, AMD и ARM64
  6. OpenNews: Стабильный выпуск СУБД MariaDB 10.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/48068-meltdown
Ключевые слова: meltdown, mysql, myisam, mariadb
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (44) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Ivan_83 (ok), 00:29, 14/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +15 +/
    MariaDB голосует за AMD.
     
     
  • 2.3, th3m3 (ok), 00:44, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • –28 +/
    У AMD, тоже самое.
     
     
  • 3.6, Ivan_83 (ok), 01:04, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +8 +/
    С чего бы!?
    На АМД эти патчи даже не включаются.
     
     
  • 4.21, iPony (?), 06:38, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • –14 +/
    Наверно имелось в виду, что с этими патчами процессоры Intel по производительности превращаются в AMD
     
  • 4.22, Аноним (-), 07:37, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • –15 +/
    Не включаются, потому что АМД старательно делают вид, будто у них этой проблемы нет.
     
     
  • 5.23, Аноним (-), 07:50, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Ждем от тебя пруфы что AMD подвержена Meltdown.
     
     
  • 6.28, Аноним (-), 08:42, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Исходная бумага по Meltdown?

    "Similarly,
    if the processor lacks certain features, e.g., no re-order
    buffer, our current implementation might not be able to
    leak data. However, for both ARM and AMD, the toy
    example as described in Section 3 works reliably, indi-
    cating that out-of-order execution generally occurs and
    instructions past illegal memory accesses are also per-
    formed."

     
     
  • 7.35, Аноним (-), 10:14, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Однако до тебя еще ни одной официальной новости по AMD не было.
     
  • 7.38, amonymous (?), 10:54, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Да, перформятся. Но в отличие от читерского штеуда - честно проверяют RPL и кэш не чешут - результат не взять. Посему на амд мылдауна нет.
     

  • 1.5, Anoninus (?), 00:52, 14/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Проще окончательно похоронить, чем делать "полный редизайн MyISAM"...
     
     
  • 2.8, Аноним (-), 01:12, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Некоторым надо читать быстрее, чем писать.
     
  • 2.43, rshadow (ok), 12:53, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Проще не держать контейнеры пользователей и контейнеры БД на одном хосте. Не говоря уж про нормальные конторы в которых такой х*ни нет + DMZ.
     
     
  • 3.44, kk (??), 13:17, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    т.е. если базу держишь отдельно то уже можно болт на безопасность на этом сервере положить?
     
     
  • 4.53, пох (?), 14:58, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > т.е. если базу держишь отдельно то уже можно болт на безопасность на этом сервере положить?

    болт на мифические угрозы - да, можно.

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

    так что идите к финансистам, просите денег на апгрейд сервера.

     

  • 1.10, all_glory_to_the_hypnotoad (ok), 02:00, 14/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Для избавления от подобного эффекта требуется полный редизайн MyISAM.

    Наконец таки появится повод совсем выкинуть это гогно.

     
     
  • 2.45, Sfinx (ok), 13:24, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    и весь остально софт, несовместимый с багами штеуда. ждем от штеуда и даунов, купивших их процы, кампанию по проверке софта на совместимость ихним багам !
     

  • 1.11, pavlinux (ok), 02:50, 14/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Postgress кто тестировали подробно и графиками?

    [сообщение отредактировано модератором]

     
     
  • 2.12, AMDGPUi915 (?), 03:01, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe@ala
     
  • 2.15, AMDGPUi915 (?), 03:08, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    С графиками

    https://databricks.com/blog/2018/01/13/meltdown-and-spectre-performance-impact

    http://www.dataarchitect.cloud/victor-yegorov-postgresql-performance-meltdown

     

  • 1.13, KonstantinB (ok), 03:07, 14/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    Полный редизайн MyISAM требуется примерно с его появления.

    И в MariaDB он уже сделан - это и есть упомянутый ARIA Engine.

     
  • 1.18, Аноним (-), 04:34, 14/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так не включайте kpti, очевидно же. На сервере дб от него толку ноль.
     
     
  • 2.27, Аноним (-), 08:39, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    от него вообще везде толку ноль, где нет проприетарного софта
     
  • 2.31, пох (?), 09:57, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Так не включайте kpti, очевидно же. На сервере дб от него толку
    > ноль.

    а если это сервер не только db?

    на сервере mysql (да еще и myisam-only) толку, действительно, почти ноль, нечего тырить и нечем.
    А если это lamp очередной - то внезапно ушлый юзер может обойтись, к примеру, без ненужного знания чужих паролей, чтобы почитать чужую базу (а там, глядишь, и парольчик найдется).

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

     
     
  • 3.33, Аноним (-), 10:09, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Оно и раньше требовало не выдавать права кому попало, сейчас что-то поменялось?
    А если взять Oracle, то там вообще Java ;)
     
     
  • 4.49, пох (?), 13:44, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Оно и раньше требовало не выдавать права кому попало, сейчас что-то поменялось?

    сейчас стало в разы опаснее. Что делать мелким массхостерам (наиболее частый сценарий "права у кого попало", хотя и далеко не единственный) - совершенно непонятно.

    ну то есть понятно - поднять цены так, чтобы пользователи смирились и смигрировали в aws и аналоги, а самим объявить банкротство. Корпорации счастливы, на интересы остальных начхать.

    а у ораклистов появился новый аргумент за покупку one-true-системы на спарке, а не интеле - все равно хорошо откормленные сервера под кластер оракла и их инфраструктура не шибко дешевле обходятся.

    опять таки-  ораклу щастье будет. Правда, все равно они умудряться все прощелкать.

     
  • 3.52, Аноним (-), 14:30, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > у владельцев postgres жизнь куда интереснее - хранимые процедуры, не говоря уже о сишных экстеншнах

    Так в MySQL по сути всё то же самое... https://dev.mysql.com/doc/refman/5.7/en/create-function-udf.html

     
     
  • 4.54, пох (?), 15:05, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Так в MySQL по сути всё то же самое...

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

     

  • 1.29, Аноним (-), 09:41, 14/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    InnoDB сжатая занимает в 2 раза больше места, чем несжатая MyISAM. Так что это совсем не альтернатива. Особенно для ssd.
     
     
  • 2.32, пох (?), 10:00, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > InnoDB сжатая занимает в 2 раза больше места, чем несжатая MyISAM.

    аллах с вами, это ж пустое место.
    Оно никогда не читается и не пишется. (вообще-то и не надо ее сжимать, там адские потери на апдейте будут)

    ничего вашему ssd не сделается (если только вы уже в его объем не уперлись, но это в общем-то полная ерунда, если вообще база влезла в ssd)


     
  • 2.34, Аноним (-), 10:10, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > InnoDB сжатая занимает в 2 раза больше места, чем несжатая MyISAM. Так
    > что это совсем не альтернатива. Особенно для ssd.

    У InnoDB функционала "немного больше", какой смысл сравнивать...

     
     
  • 3.50, Аноним (-), 13:46, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> InnoDB сжатая занимает в 2 раза больше места, чем несжатая MyISAM. Так
    >> что это совсем не альтернатива. Особенно для ssd.
    > У InnoDB функционала "немного больше", какой смысл сравнивать...

    смысл что человека вполне устраивает функционал myisam, среди которого, если что - способность переварить изрядное количество i/s, которое тоже, знаете ли, "функционал".

     
  • 2.36, Аноним (-), 10:28, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так посмотрите на TokuDB, например, если цель сократить использование места на диске. В lzma прекрасно жмет. Продукт оттестированный, есть в Percona и MariaDB.
     
  • 2.39, amonymous (?), 10:55, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > InnoDB сжатая занимает в 2 раза больше места, чем несжатая MyISAM. Так
    > что это совсем не альтернатива. Особенно для ssd.

    Давно на репейр нарывались? Чессгря лучше местом пожертвовать или взять токудб.

     
  • 2.57, _ (??), 18:50, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Особенно для ssd.

    1TB Samsung ~ $350.00
    ты о чём вообще?!

     

  • 1.37, amonymous (?), 10:49, 14/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    MyISAM? Это оно ещё кто-то всерьёз использует, ну кроме как для системных таблиц?
     
     
  • 2.40, Аноним (-), 11:05, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для системных не используют уже давно MySQL 5.7/8.0. Насчет MariaDB не знаю...
     

  • 1.41, IZh. (?), 12:08, 14/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Интересно, почему такая разница? В смысле, что такого особенного с точки зрения алгоритмов в MyISAM, что производительность так сильно проседает?
     
     
  • 2.42, IZh. (?), 12:10, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    If we look at the handler status variables, we can see that for 8K rows the query does more than 50 million calls to Handler_read_rnd_next. For MyISAM such a handler call results in a call to fget() which in turn results in a __fget syscall.

    This is so, because the MyISAM engine does not have a row cache. While it caches index pages in the Key Buffer, there is no such cache for row data. For that it relies on the generic page cache in the operation system. That works pretty well, however since that cache is in the kernel, there is the syscall barrier between the MariaDB server and the cache.

    The page table isolation introduced with KPTI increases the cost for a syscall. Hence a workload like the one above, where many MyISAM rows are read in a tight loop, becomes notably slower. The relative slowdown is actually bigger when the row is already in the page cache!

     
     
  • 3.55, J.L. (?), 16:11, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > The relative slowdown is actually bigger when the row is already in the page cache!

    отличный патч ?

     

  • 1.46, Sfinx (ok), 13:28, 14/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    после такого позора штеуд должен жени^H^H^H^H купить Maria..
     
     
  • 2.48, Michael Shigorin (ok), 13:44, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > после такого позора штеуд должен жени^H^H^H^H купить Maria..

    _Столько_ жён ему шариа^H^Wбюджет не позволит.

     
     
  • 3.51, Andrey Mitrofanov (?), 13:58, 14/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> после такого позора штеуд должен жени^H^H^H^H купить Maria..
    > _Столько_ жён ему шариа^H^Wбюджет не позволит.

    Миша, не надо завидовать миллионам Монти. :-P

     
     
  • 4.59, Аноним (-), 18:10, 15/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    остались миллионы? это ж остатки того миллиарда который он получил с Sun?
    благополучно слил в мусор?

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

     
  • 4.61, Andrey Mitrofanov (?), 11:15, 16/02/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>> после такого позора штеуд должен жени^H^H^H^H купить Maria..
    >> _Столько_ жён ему шариа^H^Wбюджет не позволит.
    > Миша, не надо завидовать миллионам Монти. :-P

    Тут некоторые не поняли, поястняю: прошлый раз https://www.opennet.ru/opennews/art.shtml?num=13689 мыл миллион (не миллиард, детский сад, б**ёнть), вот тут у Интела бакшиш образовывается -- это будет _второй_ миллион.  Первый и второй -- миллион_ы_.  ><WMW>

     

  • 1.58, Ne01eX (ok), 11:17, 15/02/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Всех спасёт Флакон (Falcon) и Ария (Aria). А InnoDB и MyISAM должны уйти в историю. Серьёзно.

    Логично, что поддержке первых двух разрабы MariaDB уделяют максимум внимания, в отличии от... :-\ Родные типы (Ария во всяком случае), как никак...

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру