Диета против блокчейновых ожирений

Доброго времени суток, Голос.

Сегодня я расскажу, как выживать и даже местами себя комфортно чувствовать в условиях стабильно хорошего аппетита к аппаратным ресурсам блокчейнов.

Блокчейн Голоса весит 16ГБ (на момент проверки цифр в него прилетел блок #16489032), а файл sharedmemory.bin в максимально возможной комплектации (все плагины, опции сборщика CLEAR_VOTES и LOW_MEMORY_NODE выключены) подбирается к отметке 60ГБ. У Стима дела еще печальнее: blocklog занимает на момент блока #22477398 целых 107ГБ (и растёт, на минутку, по гигабайту без малого в сутки), shared_memory в начале года превысил 256ГБ.

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

Например, хранение shared_memory файла в tmpfs по адресу /dev/shm неизбежно в конечном итоге израсходует оперативную память сервера. Добавление файла/раздела подкачки swap приведет к росту iowait и снижению общей производительности сервера за счет перекладывания из пустого в порожнее в попытках освобождения ОЗУ за счет частичного вымещения данных на диск. Диск в системе всегда является узким местом, особенно в случае обычных накопителей на жестких магнитных дисках. В системе с SSD ситуация другая - скорость работы swap заметно выше, однако это приводит к накладным расходам на чтение/запись, чего твердотельные накопители так или иначе всё равно боятся в силу заложенного в архитектуру ресурса на циклы перезаписи.

На помощь в этом случае приходит zRam - модуль ядра Linux, создающий в оперативной памяти сжатое блочное устройство по типу swap. Фрагменты данных при использовании zram перемещаются не на жесткий диск, а сжимаются на лету и остаются лежать всё в той же оперативной памяти. Скорость работы ОЗУ заметно превышает операции чтения/записи дисков, поэтому подобная архивация даёт форы даже самым быстрым SSD за счет небольшой нагрузки процессора, возникающей при сжатии по алгоритмам LZO или LZ4 (всё равно ЦПУ, как правило, простаивет впустую).

Затрагивая данную тему, нельзя не упоминуть про схожий по структуре модуль zSwap. Для работы его необходимо уже иметь в системе swap-раздел (или файл на диске), в ОЗУ же создается пул, куда записывается сжатый кэш данных. При заполнении пула данные сбрасываются в swap. Очевидно, что с таким подходом, стоит забыть о долговечности SSD. А в случае использования медленных жестких дисков так и вовсе не ждать положительного эффекта.

Пример использования zRam: сервер с 4ГБ ОЗУ размещает вне дискового пространства файл размером 4,3ГБ, и это не предел (!)

Shared_memory.bin размером 4,3ГБ на сервере с 4ГБ ОЗУ

В случае с блокчейном, его непосредственно block_log также занимает немало места. Исправить ситуацию в этом случае можно, поместив крупные файлы в файловую систему ZFS. По сути, это симбиоз ФС и менеджера дисков (по типу LVM). При создании томов с использованием сжатия (например, всё то же LZ4) можно добиться снижения размера на 30-40%. Помимо этого, имеется встроенный функционал для создания снапшотов (клоны, реплики и просто снимки томов), который позволяет легко и быстро масштабировать систему как в пределах одного сервера, так и на другие. А еще zfs умеет в разного уровня RAID, создавалась с учетом ненадежности дисков и легко переносит повреждение данных (с некоторыми нюансами).

На разделе zfs со сжатием lz4 блокчейн Голоса занял всего 58% от размера (прирост 42%):

Реальный и фактические размеры блокчейна Голос

В случае с блокчейном Стим результаты чуть хуже (66% от реального размера или 33% выигрыш):

Аналогичный пример для Стима

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

Текст подготовлен в редакторе OnePlace.media. Если Вы хотите поддержать проект, голосуйте за делегата oneplace по ссылке или любым другим удобным способом