LINUX.ORG.RU
решено ФорумAdmin

Есть ли смысл 4.* ядер в продакшене?

 , , ,


0

2

Сабж коллеги, имею Centos который подготовил к битриксу, хотел бы ещё завести zswap+zram в lz4 но вот заметил некроядро и понял, что хрен вместо хотелок. Видел репы с 4.* ядрами, но смущает их адекватность.

Стоит ли? Или оставить zram чисто в lzo и не трогать ядро?

Deleted

ядро

к битриксу

Всё равно что рассуждать о ядерной физике в контексте «доедет ли то колесо до Москвы».

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Я имею ввиду linux ядро. Битрикс будет юзатся на этой машине конкретно много и сильно

На ноуте, например, мне похеру какое ядро, свое могу скрасноглазить и сам подниму если упадет.

А вот в продакшенах переживаю, вот и спрашиваю.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от no-such-file

Хорошо, супер. Друг-друга поняли.

Всё равно что рассуждать о ядерной физике в контексте «доедет ли то колесо до Москвы».

Это к чему?

Deleted
()

У красной шляпы свой подход к нумерации ядер. И 3.10.0-514.21.1 от 3.10.0-862.14.4 может отличатся как земля и небо. Особенно это бесит, когда надо собирать какую-нибудь дичь, ака Lustre

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

А вот Lz4 нет

Да и кстати, нихрена не работает. Вот попробуй его модпробнуть и задать какие-то параметры через /sys/module

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

Да, так и есть, но speed не такой как в lz4

А в highload'е думаю немного критичны эти микропроценты

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

Это к чему

К тому, что глупо обсуждать копеечные профиты (или просадки) от смены ядра имея условный «битрикс». Хочется тебе lz4? Ну вкати ты его и сделай A/B тестирование, если уж настолько у тебя паранойя разыгралась.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 4)
Ответ на: комментарий от Deleted

Думаешь, не видел? Про zram там не пишут.

В ходе дальнейших исследований (fullbench из состава LZ4 и lz4c vs lzop), было выяснено, что LZ4 теряет все свои свойства при блоках маленького размера, а проявляет заявленные свойства [5] только на больших блоках, к примеру в fullbench по умолчанию 4MiB, в lz4c 8MiB. Как выразился Эдуард Шишкин: «4MiB — это как-то многовато. LZO1 сжимает куски и много мельче..» [6]

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 1)

оно не поддерживается => смысла нет

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

Я тем временем погуглил.

http://forums.debian.net/viewtopic.php?f=20&t=134182

My retest result show lzo's (mem_used_total/orig_data_size) is better(smaller) than lz4.

Удивляет, что массы, не задумываюсь, включают lz4...

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

Немного другой случай — ARM платформа.

Swap on SBC

Interesting tests, especially the lzo vs lz4 outcomes. We found the same difference last year and went for lzo zram in the end because of the overall performance benefit and marginal difference in compression

Lzo was faster and less cpu intensive overall despite lz4 being better on paper (and from the opinions of almost every internet warrior). In our case the difference came from the compression overhead of lz4 being much higher than lzo and while the decompression of lz4 was faster it wasn't enough to claw back what it loses in compression time. Interestingly when we ran the same tests on Intel cpu's (Core m3 4.5W) instead of Arm64 then the situation was reversed with lz4 coming out on top

И...

Interestingly when we ran the same tests on Intel cpu's (Core m3 4.5W) instead of Arm64 then the situation was reversed with lz4 coming out on top

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 2)
Ответ на: комментарий от Deleted

Привык к благам цивилизаций. Ну и хрен с этим lz4, человек выше доказал что LZO в разы лучше сжимает мелкие куски, соответственно то, что мне нужно, воооооооооот

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

lz4 используют когда скорость сжатия или распаковки важнее качества, страницы с кучей нулей пожались и хорошо

annulen ★★★★★
()

Если встаёт такой вопрос, то нет.

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

Я не знаю баг это или нет, но zip deflate в 4 потока дольше всего сжимал при этом. У lz4 дефолтные параметры. Раньше я архивировал в zip deflate - fastest. Кстати он дал всего на 5 мб больше файл. Короче, сжимайте lz4 спокойно.

Хотя подождите, lz4 это тар, а это архивы. tar gzip дал 465,897 на дефолтных параметрах опять же. Это получается или 7zip говно или я не знаю?

В любом случае, я тут передумал жсон пожимать deflate — какой же он тормозной, блин.

https://i.imgur.com/nktIptb.png

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

После появления zstd deflate вообще потерял актуальность, т.к. zstd жмет лучше при большей скорости

annulen ★★★★★
()

Из 4.x ядер для седьмой центосы смотри на ядро Oracle UEK. Оно по крайней мере вылизывается ораклом до блеска так же, как родное редхатом.

AlexAT
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.