Nп/п : 67 из 100
 От   : Telegram Channels Robot             2:5055/182        19 сен 23 09:31:31
 К    : All                                                   19 сен 23 12:42:02
 Тема : [](https://telegra.ph/file/22bb83a794a40f14c2be4.jpg)**Превозмогая т...
----------------------------------------------------------------------------------
                                                                                 
@MSGID: 2:5055/182 feb85ce4
@PID: jNode ver. 1.5
@TID: jNode ver. 1.5
@CHRS: CP866 2
[](https://telegra.ph/file/22bb83a794a40f14c2be4.jpg)**Превозмогая трудности**

 Я тут закончил трехмесячный R&D по использованию zswap и zram. Имею,
что сказать.

 Первое. zswap - однопоточное дерьмо. Thread-safe (который не
равноценен thread-aware, если помните). При использовании тредового IO (который,
если вы в курсях, рекомендуется в виртуализированных средах с целью
повышения производительности этого самого IO) вызывает дикие и непредсказуемые
тупаки ВМок - а равно и самого гипервизора - на любом IO. И просадки
латентности вплоть до десятков секунд.

 Причина, разумеется, проста - тот самый lock contention, о котором я
уже язык до кости стер. При этом повышения утилизации CPU не происходит
- ну да, это же lock contention.

 Второе. zram, конечно же, тредовый. Но абсолютно бредовый инструмент.
Свопинг памяти делать в память - что за буллшит?! Переливать страницы в
пространство подкачки он не умеет. На какое-то время он маскирует внезапный
скачок свопинга в результате фрагментации, но потом наступает трындец.

 Оба костыля задумывались как подпорка для дебилов, делающих своп
размером 10% от оперативной памяти. Эй, вы ж сами кричали, что сторидж стоит
как лопата дерьма, верно? Что ж жаба-то задушила делать своп вменяемого
размера, а?

 Оба костыля абсолютно бесполезны для купирования этого самого
копеешного свопа. И лишь выкидывают оперативную память на ветер. Впрочем, у вас
ее много, лишней оперативной памяти. Некоторое сокращение за счет
использования zram и zswap лишь замедляет фрагментацию на некоторое время (да,
бОльшая память быстрее фрагментируется).

 Результат исследования следующий. Либо нужен вменяемого размера своп,
либо - тадааааам! - хороший аллокатор, предзагруженный глобально, который
не вызывает бешеной фрагментации памяти. Оба средства работают и
справляются со своей работой хорошо.

 Ну и оптимизацию делать, во-первых, надо всегда - это линукс, булка
хлеба, троллейбус из него сам не возникнет, а во-вторых, тюнинг надо делать
с пониманием того, что происходит и чего вы хотите добиться.

Такие дела.

 PS. __Для справки - сделать своп с транспарентным сжатием страниц,
хранящихся на диске, можно лишь на гетеросексуальной оси (это Солярис) с
гетеросексуальной файловой системой - ZFS. И лишь при условии ZFS root pool. И то,
у меня вопрос - надо ли это делать. Что касается пингвиноводов -
ничего подобного у них нет.__
http://fido.ortoped.org.ru/photo_2023-09-19_09-24-06.jpg

--- hssergey station
 * Origin: jNode ver. 1.5 (2:5055/182)
SEEN-BY: 301/1 460/58 4500/1 5001/100 5005/49
5015/255 5019/40 5020/715 848
SEEN-BY: 5020/1042 4441 12000 5030/49 1081 5055/182
5058/104 5061/133
SEEN-BY: 5083/444
@PATH: 5055/182 5020/1042 4441



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх