Разработчики СУБД MariaDB предупредили (https://mariadb.org/myisam-table-scan-performance-kpti/) о существенном снижении производительности хранилища MyISAM при использовании ядра Linux с патчами KPTI, блокирующими уязвимость Meltdown. Замедление операций сканирования строк в MyISAM после применения патчей KPTI составляет около 40%, а при отсутствии поддержки PCID может достигать (https://jira.mariadb.org/browse/MDEV-15072) 90%. Для избавления от подобного эффекта требуется полный редизайн MyISAM.
В качестве обходного пути для избавления от потери производительности рекомендуется перейти на использование хранилищ InnoDB или ARIA, попутно убедившись, что выставлен достаточно большой размер кэша обработки записей (Buffer Pool для InnoDB и Page Cache для ARIA). При размере кэша в 128M (по умолчанию для ARIA) потеря производительности не выходит за пределы 1%.
Также можно отметить корректирующий выпуск (https://mariadb.org/mariadb-10-2-13-mariadb-connector-odbc-3.../) MariaDB 10.2.13, в котором хранилище InnoDB обновлено до выпуска 5.7.21 (перенесено из MySQL 5.7.21) и исправлено более 100 ошибок, в том числе устранено 6 уязвимостей (https://mariadb.com/kb/en/cve/), которые могли быть использованы для инициирования удалённого отказа в обслуживании. Началось формирование готовых пакетов c MariaDB для Fedora 27.URL: https://mariadb.org/myisam-table-scan-performance-kpti/
Новость: http://www.opennet.me/opennews/art.shtml?num=48068
MariaDB голосует за AMD.
У AMD, тоже самое.
С чего бы!?
На АМД эти патчи даже не включаются.
Наверно имелось в виду, что с этими патчами процессоры Intel по производительности превращаются в AMD
Не включаются, потому что АМД старательно делают вид, будто у них этой проблемы нет.
Ждем от тебя пруфы что AMD подвержена Meltdown.
Исходная бумага по 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."
Однако до тебя еще ни одной официальной новости по AMD не было.
Да, перформятся. Но в отличие от читерского штеуда - честно проверяют RPL и кэш не чешут - результат не взять. Посему на амд мылдауна нет.
Проще окончательно похоронить, чем делать "полный редизайн MyISAM"...
Некоторым надо читать быстрее, чем писать.
Проще не держать контейнеры пользователей и контейнеры БД на одном хосте. Не говоря уж про нормальные конторы в которых такой х*ни нет + DMZ.
т.е. если базу держишь отдельно то уже можно болт на безопасность на этом сервере положить?
> т.е. если базу держишь отдельно то уже можно болт на безопасность на этом сервере положить?болт на мифические угрозы - да, можно.
Но я рекомендую внимательно посмотреть на постгрезовые графики (постгрезовые - потому что других нет) и убедиться, что потери производительности будут даже с nopti - миллионы рантаймовых проверок "а не надо ли все же тут pti" понапиханные как попало в код ядра, явно не улучшают производительность, даже если все они возвращают "нет".
так что идите к финансистам, просите денег на апгрейд сервера.
> Для избавления от подобного эффекта требуется полный редизайн MyISAM.Наконец таки появится повод совсем выкинуть это гогно.
и весь остально софт, несовместимый с багами штеуда. ждем от штеуда и даунов, купивших их процы, кампанию по проверке софта на совместимость ихним багам !
Postgress кто тестировали подробно и графиками?[сообщение отредактировано модератором]
https://www.postgresql.org/message-id/20180102222354.qikjmf7...
С графикамиhttps://databricks.com/blog/2018/01/13/meltdown-and-spectre-...
http://www.dataarchitect.cloud/victor-yegorov-postgresql-per.../
Полный редизайн MyISAM требуется примерно с его появления.И в MariaDB он уже сделан - это и есть упомянутый ARIA Engine.
Так не включайте kpti, очевидно же. На сервере дб от него толку ноль.
от него вообще везде толку ноль, где нет проприетарного софта
> Так не включайте kpti, очевидно же. На сервере дб от него толку
> ноль.а если это сервер не только db?
на сервере mysql (да еще и myisam-only) толку, действительно, почти ноль, нечего тырить и нечем.
А если это lamp очередной - то внезапно ушлый юзер может обойтись, к примеру, без ненужного знания чужих паролей, чтобы почитать чужую базу (а там, глядишь, и парольчик найдется).у владельцев postgres жизнь куда интереснее - хранимые процедуры, не говоря уже о сишных экстеншнах (которые и раньше были опасны, но раньше они хотя бы не могли спереть/поломать что-то кроме самого постгреза) позволяют много интересного.
Оно и раньше требовало не выдавать права кому попало, сейчас что-то поменялось?
А если взять Oracle, то там вообще Java ;)
> Оно и раньше требовало не выдавать права кому попало, сейчас что-то поменялось?сейчас стало в разы опаснее. Что делать мелким массхостерам (наиболее частый сценарий "права у кого попало", хотя и далеко не единственный) - совершенно непонятно.
ну то есть понятно - поднять цены так, чтобы пользователи смирились и смигрировали в aws и аналоги, а самим объявить банкротство. Корпорации счастливы, на интересы остальных начхать.
а у ораклистов появился новый аргумент за покупку one-true-системы на спарке, а не интеле - все равно хорошо откормленные сервера под кластер оракла и их инфраструктура не шибко дешевле обходятся.
опять таки- ораклу щастье будет. Правда, все равно они умудряться все прощелкать.
> у владельцев postgres жизнь куда интереснее - хранимые процедуры, не говоря уже о сишных экстеншнахТак в MySQL по сути всё то же самое... https://dev.mysql.com/doc/refman/5.7/en/create-function-udf....
> Так в MySQL по сути всё то же самое...да, отстал я от жизни. Впрочем, эти фичи 5.7 вряд ли многие используют - те, кому оно было надо, давным-давно ушли на другие системы. (и нате вам еще один повод ;-)
InnoDB сжатая занимает в 2 раза больше места, чем несжатая MyISAM. Так что это совсем не альтернатива. Особенно для ssd.
> InnoDB сжатая занимает в 2 раза больше места, чем несжатая MyISAM.аллах с вами, это ж пустое место.
Оно никогда не читается и не пишется. (вообще-то и не надо ее сжимать, там адские потери на апдейте будут)ничего вашему ssd не сделается (если только вы уже в его объем не уперлись, но это в общем-то полная ерунда, если вообще база влезла в ssd)
> InnoDB сжатая занимает в 2 раза больше места, чем несжатая MyISAM. Так
> что это совсем не альтернатива. Особенно для ssd.У InnoDB функционала "немного больше", какой смысл сравнивать...
>> InnoDB сжатая занимает в 2 раза больше места, чем несжатая MyISAM. Так
>> что это совсем не альтернатива. Особенно для ssd.
> У InnoDB функционала "немного больше", какой смысл сравнивать...смысл что человека вполне устраивает функционал myisam, среди которого, если что - способность переварить изрядное количество i/s, которое тоже, знаете ли, "функционал".
Так посмотрите на TokuDB, например, если цель сократить использование места на диске. В lzma прекрасно жмет. Продукт оттестированный, есть в Percona и MariaDB.
> InnoDB сжатая занимает в 2 раза больше места, чем несжатая MyISAM. Так
> что это совсем не альтернатива. Особенно для ssd.Давно на репейр нарывались? Чессгря лучше местом пожертвовать или взять токудб.
>Особенно для ssd.1TB Samsung ~ $350.00
ты о чём вообще?!
MyISAM? Это оно ещё кто-то всерьёз использует, ну кроме как для системных таблиц?
Для системных не используют уже давно MySQL 5.7/8.0. Насчет MariaDB не знаю...
Интересно, почему такая разница? В смысле, что такого особенного с точки зрения алгоритмов в MyISAM, что производительность так сильно проседает?
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!
> The relative slowdown is actually bigger when the row is already in the page cache!отличный патч ?
после такого позора штеуд должен жени^H^H^H^H купить Maria..
> после такого позора штеуд должен жени^H^H^H^H купить Maria.._Столько_ жён ему шариа^H^Wбюджет не позволит.
>> после такого позора штеуд должен жени^H^H^H^H купить Maria..
> _Столько_ жён ему шариа^H^Wбюджет не позволит.Миша, не надо завидовать миллионам Монти. :-P
остались миллионы? это ж остатки того миллиарда который он получил с Sun?
благополучно слил в мусор?Хотя помню еще комьюнити подряжал отжать торговую марку назад, и перепродать еще раз..
видать совсем плохо с деньгами было.
>>> после такого позора штеуд должен жени^H^H^H^H купить Maria..
>> _Столько_ жён ему шариа^H^Wбюджет не позволит.
> Миша, не надо завидовать миллионам Монти. :-PТут некоторые не поняли, поястняю: прошлый раз https://www.opennet.me/opennews/art.shtml?num=13689 мыл миллион (не миллиард, детский сад, б**ёнть), вот тут у Интела бакшиш образовывается -- это будет _второй_ миллион. Первый и второй -- миллион_ы_. ><WMW>
Всех спасёт Флакон (Falcon) и Ария (Aria). А InnoDB и MyISAM должны уйти в историю. Серьёзно.Логично, что поддержке первых двух разрабы MariaDB уделяют максимум внимания, в отличии от... :-\ Родные типы (Ария во всяком случае), как никак...