|
|
|
4.21, iPony (?), 06:38, 14/02/2018 [^] [^^] [^^^] [ответить]
| –14 +/– |
Наверно имелось в виду, что с этими патчами процессоры Intel по производительности превращаются в AMD
| |
4.22, Аноним (-), 07:37, 14/02/2018 [^] [^^] [^^^] [ответить]
| –15 +/– |
Не включаются, потому что АМД старательно делают вид, будто у них этой проблемы нет.
| |
|
|
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.38, amonymous (?), 10:54, 14/02/2018 [^] [^^] [^^^] [ответить]
| +6 +/– |
Да, перформятся. Но в отличие от читерского штеуда - честно проверяют RPL и кэш не чешут - результат не взять. Посему на амд мылдауна нет.
| |
|
|
|
|
|
|
|
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" понапиханные как попало в код ядра, явно не улучшают производительность, даже если все они возвращают "нет".
так что идите к финансистам, просите денег на апгрейд сервера.
| |
|
|
|
|
2.45, Sfinx (ok), 13:24, 14/02/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
и весь остально софт, несовместимый с багами штеуда. ждем от штеуда и даунов, купивших их процы, кампанию по проверке софта на совместимость ихним багам !
| |
|
1.11, pavlinux (ok), 02:50, 14/02/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
Postgress кто тестировали подробно и графиками?
[сообщение отредактировано модератором]
| |
1.13, KonstantinB (ok), 03:07, 14/02/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +10 +/– |
Полный редизайн MyISAM требуется примерно с его появления.
И в MariaDB он уже сделан - это и есть упомянутый ARIA Engine.
| |
|
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-системы на спарке, а не интеле - все равно хорошо откормленные сервера под кластер оракла и их инфраструктура не шибко дешевле обходятся.
опять таки- ораклу щастье будет. Правда, все равно они умудряться все прощелкать.
| |
|
|
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
ты о чём вообще?!
| |
|
|
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!
отличный патч ?
| |
|
|
|
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 уделяют максимум внимания, в отличии от... :-\ Родные типы (Ария во всяком случае), как никак...
| |
|