The OpenNET Project / Index page

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



"Значительное снижение производительности MyISAM при включени..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от opennews (??) on 14-Фев-18, 00:19 
Разработчики СУБД 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.dev/opennews/art.shtml?num=48068

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


2. "Значительное снижение производительности MyISAM при включени..."  +15 +/
Сообщение от Ivan_83 (ok) on 14-Фев-18, 00:29 
MariaDB голосует за AMD.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Значительное снижение производительности MyISAM при включени..."  –28 +/
Сообщение от th3m3 (ok) on 14-Фев-18, 00:44 
У AMD, тоже самое.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

6. "Значительное снижение производительности MyISAM при включени..."  +8 +/
Сообщение от Ivan_83 (ok) on 14-Фев-18, 01:04 
С чего бы!?
На АМД эти патчи даже не включаются.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

21. "Значительное снижение производительности MyISAM при включени..."  –14 +/
Сообщение от iPony on 14-Фев-18, 06:38 
Наверно имелось в виду, что с этими патчами процессоры Intel по производительности превращаются в AMD
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

22. "Значительное снижение производительности MyISAM при включени..."  –15 +/
Сообщение от Аноним (??) on 14-Фев-18, 07:37 
Не включаются, потому что АМД старательно делают вид, будто у них этой проблемы нет.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

23. "Значительное снижение производительности MyISAM при включени..."  +5 +/
Сообщение от Аноним (??) on 14-Фев-18, 07:50 
Ждем от тебя пруфы что AMD подвержена Meltdown.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

28. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от Аноним (??) on 14-Фев-18, 08:42 
Исходная бумага по 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."

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

35. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от Аноним (??) on 14-Фев-18, 10:14 
Однако до тебя еще ни одной официальной новости по AMD не было.
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

38. "Значительное снижение производительности MyISAM при включени..."  +6 +/
Сообщение от amonymous on 14-Фев-18, 10:54 
Да, перформятся. Но в отличие от читерского штеуда - честно проверяют RPL и кэш не чешут - результат не взять. Посему на амд мылдауна нет.
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

5. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от Anoninus on 14-Фев-18, 00:52 
Проще окончательно похоронить, чем делать "полный редизайн MyISAM"...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Значительное снижение производительности MyISAM при включени..."  +9 +/
Сообщение от Аноним (??) on 14-Фев-18, 01:12 
Некоторым надо читать быстрее, чем писать.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

43. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от rshadow (ok) on 14-Фев-18, 12:53 
Проще не держать контейнеры пользователей и контейнеры БД на одном хосте. Не говоря уж про нормальные конторы в которых такой х*ни нет + DMZ.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

44. "Значительное снижение производительности MyISAM при включени..."  +2 +/
Сообщение от kk (??) on 14-Фев-18, 13:17 
т.е. если базу держишь отдельно то уже можно болт на безопасность на этом сервере положить?
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

53. "Значительное снижение производительности MyISAM при включени..."  +1 +/
Сообщение от пох on 14-Фев-18, 14:58 
> т.е. если базу держишь отдельно то уже можно болт на безопасность на этом сервере положить?

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

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

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

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

10. "Значительное снижение производительности MyISAM при включени..."  +2 +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 14-Фев-18, 02:00 
> Для избавления от подобного эффекта требуется полный редизайн MyISAM.

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

45. "Значительное снижение производительности MyISAM при включени..."  +2 +/
Сообщение от Sfinx (ok) on 14-Фев-18, 13:24 
и весь остально софт, несовместимый с багами штеуда. ждем от штеуда и даунов, купивших их процы, кампанию по проверке софта на совместимость ихним багам !
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

11. "Значительное снижение производительности MyISAM при включени..."  –6 +/
Сообщение от pavlinux (ok) on 14-Фев-18, 02:50 
Postgress кто тестировали подробно и графиками?

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Значительное снижение производительности MyISAM при включени..."  +2 +/
Сообщение от AMDGPUi915 on 14-Фев-18, 03:01 
https://www.postgresql.org/message-id/20180102222354.qikjmf7...
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

15. "Значительное снижение производительности MyISAM при включени..."  +2 +/
Сообщение от AMDGPUi915 on 14-Фев-18, 03:08 
С графиками

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

http://www.dataarchitect.cloud/victor-yegorov-postgresql-per.../

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "Значительное снижение производительности MyISAM при включени..."  +10 +/
Сообщение от KonstantinB (ok) on 14-Фев-18, 03:07 
Полный редизайн MyISAM требуется примерно с его появления.

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от Аноним (??) on 14-Фев-18, 04:34 
Так не включайте kpti, очевидно же. На сервере дб от него толку ноль.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

27. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от Аноним (??) on 14-Фев-18, 08:39 
от него вообще везде толку ноль, где нет проприетарного софта
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

31. "Значительное снижение производительности MyISAM при включени..."  +2 +/
Сообщение от пох on 14-Фев-18, 09:57 
> Так не включайте kpti, очевидно же. На сервере дб от него толку
> ноль.

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

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

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

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

33. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от Аноним (??) on 14-Фев-18, 10:09 
Оно и раньше требовало не выдавать права кому попало, сейчас что-то поменялось?
А если взять Oracle, то там вообще Java ;)
Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

49. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от пох on 14-Фев-18, 13:44 
> Оно и раньше требовало не выдавать права кому попало, сейчас что-то поменялось?

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

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

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

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

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

52. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от Аноним (??) on 14-Фев-18, 14:30 
> у владельцев postgres жизнь куда интереснее - хранимые процедуры, не говоря уже о сишных экстеншнах

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

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

54. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от пох on 14-Фев-18, 15:05 
> Так в MySQL по сути всё то же самое...

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

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

29. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от Аноним (??) on 14-Фев-18, 09:41 
InnoDB сжатая занимает в 2 раза больше места, чем несжатая MyISAM. Так что это совсем не альтернатива. Особенно для ssd.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

32. "Значительное снижение производительности MyISAM при включени..."  +1 +/
Сообщение от пох on 14-Фев-18, 10:00 
> InnoDB сжатая занимает в 2 раза больше места, чем несжатая MyISAM.

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

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


Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

34. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от Аноним (??) on 14-Фев-18, 10:10 
> InnoDB сжатая занимает в 2 раза больше места, чем несжатая MyISAM. Так
> что это совсем не альтернатива. Особенно для ssd.

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

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

50. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от Аноним (??) on 14-Фев-18, 13:46 
>> InnoDB сжатая занимает в 2 раза больше места, чем несжатая MyISAM. Так
>> что это совсем не альтернатива. Особенно для ssd.
> У InnoDB функционала "немного больше", какой смысл сравнивать...

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

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

36. "Значительное снижение производительности MyISAM при включени..."  +1 +/
Сообщение от Аноним (??) on 14-Фев-18, 10:28 
Так посмотрите на TokuDB, например, если цель сократить использование места на диске. В lzma прекрасно жмет. Продукт оттестированный, есть в Percona и MariaDB.
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

39. "Значительное снижение производительности MyISAM при включени..."  +2 +/
Сообщение от amonymous on 14-Фев-18, 10:55 
> InnoDB сжатая занимает в 2 раза больше места, чем несжатая MyISAM. Так
> что это совсем не альтернатива. Особенно для ssd.

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

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

57. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от _ (??) on 14-Фев-18, 18:50 
>Особенно для ssd.

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

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

37. "Значительное снижение производительности MyISAM при включени..."  +1 +/
Сообщение от amonymous on 14-Фев-18, 10:49 
MyISAM? Это оно ещё кто-то всерьёз использует, ну кроме как для системных таблиц?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

40. "Значительное снижение производительности MyISAM при включени..."  +1 +/
Сообщение от Аноним (??) on 14-Фев-18, 11:05 
Для системных не используют уже давно MySQL 5.7/8.0. Насчет MariaDB не знаю...
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

41. "Значительное снижение производительности MyISAM при включени..."  +1 +/
Сообщение от IZh. on 14-Фев-18, 12:08 
Интересно, почему такая разница? В смысле, что такого особенного с точки зрения алгоритмов в MyISAM, что производительность так сильно проседает?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Значительное снижение производительности MyISAM при включени..."  +1 +/
Сообщение от IZh. on 14-Фев-18, 12:10 
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!

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

55. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от J.L. on 14-Фев-18, 16:11 
> The relative slowdown is actually bigger when the row is already in the page cache!

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

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

46. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от Sfinx (ok) on 14-Фев-18, 13:28 
после такого позора штеуд должен жени^H^H^H^H купить Maria..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

48. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от Michael Shigorin email(ok) on 14-Фев-18, 13:44 
> после такого позора штеуд должен жени^H^H^H^H купить Maria..

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

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

51. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от Andrey Mitrofanov on 14-Фев-18, 13:58 
>> после такого позора штеуд должен жени^H^H^H^H купить Maria..
> _Столько_ жён ему шариа^H^Wбюджет не позволит.

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

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

59. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от Аноним (??) on 15-Фев-18, 18:10 
остались миллионы? это ж остатки того миллиарда который он получил с Sun?
благополучно слил в мусор?

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

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

61. "Значительное снижение производительности MyISAM при включени..."  +/
Сообщение от Andrey Mitrofanov on 16-Фев-18, 11:15 
>>> после такого позора штеуд должен жени^H^H^H^H купить Maria..
>> _Столько_ жён ему шариа^H^Wбюджет не позволит.
> Миша, не надо завидовать миллионам Монти. :-P

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

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

58. "Значительное снижение производительности MyISAM при включени..."  –1 +/
Сообщение от Ne01eX email(ok) on 15-Фев-18, 11:17 
Всех спасёт Флакон (Falcon) и Ария (Aria). А InnoDB и MyISAM должны уйти в историю. Серьёзно.

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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