Настраиваем ZSWAP для улучшения производительности системы
Вчера мы рассказывали о ZRAM, как эффективном способе улучшить производительность ПК с небольшим объемом оперативной памяти за счет ее сжатия.
Сегодня расскажем о другой технологии – ZSWAP, которая позволяет создать также в оперативной памяти сжатый кеш страниц для файла подкачки.
Многие путают эти технологии, которые имеют разный принцип действия и разные назначения. Поэтому начнем с краткого ликбеза.
🔹 ZRAM – создает в памяти отдельное блочное устройство, которое использует как пространство подкачки с наивысшим приоритетом. Выгода получается за счет сжатия помещаемых в него данных.
Скажем у нас есть ПК с 2 ГБ ОЗУ, мы оставляем 1 ГБ, а на еще 1 ГБ создаем устройство ZRAM. Памяти остается мало, и система начинает свопить на устройство ZRAM. Но это та же оперативная память, поэтому происходит это практически также быстро, как доступ в память напрямую.
Но за счет сжатия мы можем поместить туда больше данных, так при типичном коэффициенте сжатия 2-3 мы получаем аналог ПК с 3-4 ГБ ОЗУ, что существенно улучшает быстродействие.
🔹 Теперь о ZSWAP, это именно сжатый горячий кеш дискового пространства подкачки в ОЗУ, и работает он именно как кеш. Холодные данные из него разжимаются и сбрасываются на диск.
Его основная цель – улучшить взаимодействие системы и пространства подкачки сократив дисковые операции, тем самым получив повышение производительности.
Но это не означает, что сначала будет до упора использоваться кеш, а только потом диск. Нет, кеш работает по принципу веса и частоты обращения к данным, поэтому это не прямой аналог и не замена ZRAM.
Перед тем как включать данную технологию посмотрим какие возможности поддерживаются, в первую очередь нас интересуют доступные алгоритмы сжатия. Для этого выполните:
В выводе будет что-то вида:
Первая строка обозначает что ZSWAP поддерживается ядром, далее идут перечисления доступных алгоритмов сжатия, мы видим, что по умолчанию включен LZO, однако в настоящее время наиболее оптимально использовать представляющий лучшее сочетание скорости и сжатия ZSTD.
В качестве аллокатора используется zsmalloc, который оптимален для управления сильно фрагментированными наборами малых файлов.
Теперь включим сам ZSWAP, для этого откроем
Через пробел добавим еще несколько, приведя строку к виду:
Разберем добавленные параметры:
▫️zswap.enabled=1 – включает ZSWAP
▫️zswap.compressor=zstd – выбирает механизм компрессии, в нашем случае zstd
▫️zswap.max_pool_percent=10 – указывает доступный процент памяти для использования, по умолчанию 20
▫️zswap.zpool=zsmalloc – определяет используемый аллокатор, в нашем случае можно не указывать, так как zsmalloc стоит по умолчанию.
После чего обновляем параметры загрузчика ядра:
И перезагружаем компьютер.
Проверяем:
В ответ должны получить Y, zstd, 10 и zsmalloc.
Посмотреть использование и эффективность можно командой:
Указанные параметры – не догма, вы можете (и должны) их выбирать исходя из реальных параметров и показателей вашей системы.
Вчера мы рассказывали о ZRAM, как эффективном способе улучшить производительность ПК с небольшим объемом оперативной памяти за счет ее сжатия.
Сегодня расскажем о другой технологии – ZSWAP, которая позволяет создать также в оперативной памяти сжатый кеш страниц для файла подкачки.
Многие путают эти технологии, которые имеют разный принцип действия и разные назначения. Поэтому начнем с краткого ликбеза.
🔹 ZRAM – создает в памяти отдельное блочное устройство, которое использует как пространство подкачки с наивысшим приоритетом. Выгода получается за счет сжатия помещаемых в него данных.
Скажем у нас есть ПК с 2 ГБ ОЗУ, мы оставляем 1 ГБ, а на еще 1 ГБ создаем устройство ZRAM. Памяти остается мало, и система начинает свопить на устройство ZRAM. Но это та же оперативная память, поэтому происходит это практически также быстро, как доступ в память напрямую.
Но за счет сжатия мы можем поместить туда больше данных, так при типичном коэффициенте сжатия 2-3 мы получаем аналог ПК с 3-4 ГБ ОЗУ, что существенно улучшает быстродействие.
🔹 Теперь о ZSWAP, это именно сжатый горячий кеш дискового пространства подкачки в ОЗУ, и работает он именно как кеш. Холодные данные из него разжимаются и сбрасываются на диск.
Его основная цель – улучшить взаимодействие системы и пространства подкачки сократив дисковые операции, тем самым получив повышение производительности.
Но это не означает, что сначала будет до упора использоваться кеш, а только потом диск. Нет, кеш работает по принципу веса и частоты обращения к данным, поэтому это не прямой аналог и не замена ZRAM.
Перед тем как включать данную технологию посмотрим какие возможности поддерживаются, в первую очередь нас интересуют доступные алгоритмы сжатия. Для этого выполните:
cat /boot/config-`uname -r` | grep -i zswap
В выводе будет что-то вида:
CONFIG_ZSWAP=y
# CONFIG_ZSWAP_DEFAULT_ON is not set
CONFIG_ZSWAP_SHRINKER_DEFAULT_ON=y
# CONFIG_ZSWAP_COMPRESSOR_DEFAULT_DEFLATE is not set
CONFIG_ZSWAP_COMPRESSOR_DEFAULT_LZO=y
# CONFIG_ZSWAP_COMPRESSOR_DEFAULT_842 is not set
# CONFIG_ZSWAP_COMPRESSOR_DEFAULT_LZ4 is not set
# CONFIG_ZSWAP_COMPRESSOR_DEFAULT_LZ4HC is not set
# CONFIG_ZSWAP_COMPRESSOR_DEFAULT_ZSTD is not set
CONFIG_ZSWAP_COMPRESSOR_DEFAULT="lzo"
CONFIG_ZSWAP_ZPOOL_DEFAULT_ZSMALLOC=y
CONFIG_ZSWAP_ZPOOL_DEFAULT="zsmalloc"
Первая строка обозначает что ZSWAP поддерживается ядром, далее идут перечисления доступных алгоритмов сжатия, мы видим, что по умолчанию включен LZO, однако в настоящее время наиболее оптимально использовать представляющий лучшее сочетание скорости и сжатия ZSTD.
В качестве аллокатора используется zsmalloc, который оптимален для управления сильно фрагментированными наборами малых файлов.
Теперь включим сам ZSWAP, для этого откроем
/etc/default/grub и найдем там строку GRUB_CMDLINE_LINUX_DEFAULT, обычно в ней уже есть параметры, например: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
Через пробел добавим еще несколько, приведя строку к виду:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash zswap.enabled=1 zswap.compressor=zstd zswap.max_pool_percent=10 zswap.zpool=zsmalloc"
Разберем добавленные параметры:
▫️zswap.enabled=1 – включает ZSWAP
▫️zswap.compressor=zstd – выбирает механизм компрессии, в нашем случае zstd
▫️zswap.max_pool_percent=10 – указывает доступный процент памяти для использования, по умолчанию 20
▫️zswap.zpool=zsmalloc – определяет используемый аллокатор, в нашем случае можно не указывать, так как zsmalloc стоит по умолчанию.
После чего обновляем параметры загрузчика ядра:
update-grub
И перезагружаем компьютер.
Проверяем:
cat /sys/module/zswap/parameters/enabled
cat /sys/module/zswap/parameters/compressor
cat /sys/module/zswap/parameters/max_pool_percent
cat /sys/module/zswap/parameters/zpool
В ответ должны получить Y, zstd, 10 и zsmalloc.
Посмотреть использование и эффективность можно командой:
grep -i zswap /proc/meminfo
Указанные параметры – не догма, вы можете (и должны) их выбирать исходя из реальных параметров и показателей вашей системы.
👍28
Как на самом деле работает KSM sharing, ожидание и реальность.
Сегодня с коллегой решали одну задачу, а именно уплотнение количества виртуальных машин на нодах. Временно понадобилось увеличить количество работающих виртуалок практически на половину, при условии использования наличных ресурсов.
Такая задача поставлена была не спроста, потому как уплотнение нужно на небольшой переходный период по переносу рабочей нагрузки со старых виртуалок на новые с последующим выводом старых из эксплуатации. После чего свободных ресурсов окажется снова более чем достаточно.
При расчетах исходили из того, что в среднем одна нода имеет 16 ГБ оперативной памяти и 6 виртуальных машин с потреблением ОЗУ примерно на уровне 10 ГБ. Все виртуальные машины однотипны.
Таким образом максимально мы можем поместить на ноду 9 виртуальных машин и память закончится, но у нас есть KSM sharing, и мы на него рассчитывали.
Сразу скажем – он не подвел и при запущенных 9 виртуальных машинах потребление памяти не превысило 12 ГБ при уплотненном объеме в районе 3 ГБ.
Результат неплохой, полностью соответствующий ожиданиям, но наш коллега остался несколько разочарованным. О чем мы его прямо и спросили.
Как выяснилось, он ожидал, что KSM sharing как сейчас все оптимизирует, да как все освободит, ну даром что ли у нас 9 одинаковых виртуалок. А он всего лишь поджал память к лимитам.
И это достаточно распространенные ожидания, которые не оправдываются реальной работой технологии. Но на самом деле все работает именно так, как задумывается.
Начнем с того, что свободная память – это не самоцель, а ресурс, который мы должны использовать наиболее выгодно. Уплотненная память ресурс гораздо более дорогой, чем обычная и если можно память не уплотнять, то уплотнять ее не нужно. ‼️
Поэтому KSM включается по умолчанию достаточно поздно, при превышении порога занятой памяти в 80%. Это некоторый критический порог, за которым начнется конкуренция за свободную память между приложениями и буферами / кешем, что ни к чему хорошему с точки зрения производительности и стабильности не приведет.
Поэтому система начинает уплотнять память, но делать это грамотно, стараясь использовать уплотненную память по минимуму.
При превышении заданного порога система добавляет к уплотнению некоторое количество страниц, добиваясь возвращения потребления памяти к заданному порогу. Если после этого свободной памяти окажется больше, то из уплотнения будет вычтено некоторое количество страниц.
При повторном превышении снова будут добавлены страницы, при понижении вычтены и через некоторое время система придет в некоторое положение равновесия, когда уплотнено будет ровно столько страниц, сколько нужно для удержания количества свободной памяти рядом с установленным порогом или чуть ниже.
Потому как нет смысла загонять процессы в уплотненную и дорогую память ради выделения неиспользуемой дешевой. Это глупое разбазаривание ценного ресурса, память должна работать.
И настройки KSM по умолчанию неплохо соответствуют этой парадигме. При желании изменить такое поведение и покрутить руками можете воспользоваться нашими рекомендациями из статьи:
https://interface31.ru/tech_it/2022/07/nastraivaem-ispolzovanie-ram-pri-rabote-s-zfs-v-proxmox-ve.html
Но будьте благоразумны и не один раз подумайте, а для чего вам свободная оперативная память.
А реальную работу KSM sharing можно посмотреть на скриншоте ниже, где видно как по мере ввода новой рабочей нагрузки производилась оптимизация и подбор количества уплотняемых страниц и как этот процесс стабилизировался на отметке близкой к порогу.
Сегодня с коллегой решали одну задачу, а именно уплотнение количества виртуальных машин на нодах. Временно понадобилось увеличить количество работающих виртуалок практически на половину, при условии использования наличных ресурсов.
Такая задача поставлена была не спроста, потому как уплотнение нужно на небольшой переходный период по переносу рабочей нагрузки со старых виртуалок на новые с последующим выводом старых из эксплуатации. После чего свободных ресурсов окажется снова более чем достаточно.
При расчетах исходили из того, что в среднем одна нода имеет 16 ГБ оперативной памяти и 6 виртуальных машин с потреблением ОЗУ примерно на уровне 10 ГБ. Все виртуальные машины однотипны.
Таким образом максимально мы можем поместить на ноду 9 виртуальных машин и память закончится, но у нас есть KSM sharing, и мы на него рассчитывали.
Сразу скажем – он не подвел и при запущенных 9 виртуальных машинах потребление памяти не превысило 12 ГБ при уплотненном объеме в районе 3 ГБ.
Результат неплохой, полностью соответствующий ожиданиям, но наш коллега остался несколько разочарованным. О чем мы его прямо и спросили.
Как выяснилось, он ожидал, что KSM sharing как сейчас все оптимизирует, да как все освободит, ну даром что ли у нас 9 одинаковых виртуалок. А он всего лишь поджал память к лимитам.
И это достаточно распространенные ожидания, которые не оправдываются реальной работой технологии. Но на самом деле все работает именно так, как задумывается.
Начнем с того, что свободная память – это не самоцель, а ресурс, который мы должны использовать наиболее выгодно. Уплотненная память ресурс гораздо более дорогой, чем обычная и если можно память не уплотнять, то уплотнять ее не нужно. ‼️
Поэтому KSM включается по умолчанию достаточно поздно, при превышении порога занятой памяти в 80%. Это некоторый критический порог, за которым начнется конкуренция за свободную память между приложениями и буферами / кешем, что ни к чему хорошему с точки зрения производительности и стабильности не приведет.
Поэтому система начинает уплотнять память, но делать это грамотно, стараясь использовать уплотненную память по минимуму.
При превышении заданного порога система добавляет к уплотнению некоторое количество страниц, добиваясь возвращения потребления памяти к заданному порогу. Если после этого свободной памяти окажется больше, то из уплотнения будет вычтено некоторое количество страниц.
При повторном превышении снова будут добавлены страницы, при понижении вычтены и через некоторое время система придет в некоторое положение равновесия, когда уплотнено будет ровно столько страниц, сколько нужно для удержания количества свободной памяти рядом с установленным порогом или чуть ниже.
Потому как нет смысла загонять процессы в уплотненную и дорогую память ради выделения неиспользуемой дешевой. Это глупое разбазаривание ценного ресурса, память должна работать.
И настройки KSM по умолчанию неплохо соответствуют этой парадигме. При желании изменить такое поведение и покрутить руками можете воспользоваться нашими рекомендациями из статьи:
https://interface31.ru/tech_it/2022/07/nastraivaem-ispolzovanie-ram-pri-rabote-s-zfs-v-proxmox-ve.html
Но будьте благоразумны и не один раз подумайте, а для чего вам свободная оперативная память.
А реальную работу KSM sharing можно посмотреть на скриншоте ниже, где видно как по мере ввода новой рабочей нагрузки производилась оптимизация и подбор количества уплотняемых страниц и как этот процесс стабилизировался на отметке близкой к порогу.
👍15❤3🤮3🔥2
В чем сходство и в чем различие ZRAM и ZSWAP
Каждый раз при упоминании этих технологий возникает ряд стандартных вопросов по их сходству и различию, а также совместному применению, поэтому давайте отдельно разберемся в этом вопросе.
1️⃣ Начнем с ZRAM. Эта технология создает в оперативной памяти блочное устройство и использует его в качестве пространства подкачки. Выделенная оперативная память сразу резервируется и не может быть использована системой.
Цель ZRAM – за счет сжатия предоставить системе большее количество доступной оперативной памяти, чем есть на самом деле. Это достигается за счет сжатия.
Средний коэффициент сжатия для LZ4 – 2,5, это значит, что, выделив для ZRAM 1 ГБ оперативной памяти мы получаем в свое распоряжение 2,5 ГБ очень быстрого swap, что позволяет достаточно эффективно решить вопрос нехватки ОЗУ.
Например, для машины с 4 ГБ ОЗУ, что по нынешним временам критический минимум, мы можем, разделив память пополам получить эквивалент 6-8 ГБ ОЗУ что радикально поменяет в лучшую сторону пользовательский опыт работы с системой.
Но за все нужно платить, за ZRAM мы платим процессорными ресурсами и ухудшением параметров доступа к сжатой памяти. Если сравнивать латентность доступа, то мы получим следующие цифры:
▫️Обычная RAM ~80–120 нс
▫️ZRAM (LZ4) ~1–5 мкс
▫️NVMe swap ~50–150 мкс
▫️SATA SSD swap ~200–500 мкс
▫️HDD swap миллисекунды
Как видим, ZRAM дает существенный рост латентности (в 10-50 раз), но все еще остается самым быстрым пространством подкачки, потому что даже при использовании быстрого NVMe разница будет уже на порядок.
Ну и ситуация, когда где-то что-то немного подтормаживает гораздо лучше ситуации, когда все стало колом из-за нехватки памяти.
Но если средняя латентность растет относительно незначительно, то вот рост tail latency (Tail latency (p95 / p99)) оказывается гораздо более высоким, что может приводить к заметным фризам и каскадному росту задержек.
Поэтому не следует использовать ZRAM в системах критичных к p95 / p99 – это большинство серверных применений, виртуализация и особенно СУБД, а также любые задачи критичные к задержкам, игры.
2️⃣ Теперь перейдем к ZSWAP, это Write Back кеш для пространств подкачки, общего с ZRAM у него только то, что он тоже использует сжатую память. В остальном это совершенно другая технология.
Так как это кеш, то выделенная память не резервируется сразу, а используется по мере необходимости, также кеш всегда может быть сброшен ядром.
Задача ZSWAP кеша – уменьшить количество обращений к пространствам подкачки на дисках, а выгода здесь также получается от сжатия данных.
Например, в системе с 16 ГБ памяти для ZSWAP по умолчанию резервируется 20% или 3,2 ГБ, что эквивалентно (для LZ4) примерно 8 ГБ несжатой памяти. Т.е. получаем неплохой такой раздел подкачки прямо в ОЗУ.
Что касается латентности, то она ничем не отличается от ZRAM, но в случае ZSWAP это только плюс, так как латентность сжатой памяти в 50-100 раз ниже, чем латентность быстрых NVME и на порядок лучше обычных дисков.
Это позволяет эффективно сглаживать пиковые нагрузки и уменьшает рост p95 / p99, что позитивно сказывается на чувствительных к задержкам рабочих процессах.
👉 Вот здесь внимательный читатель может удивиться, как так, одна и таже технология дает прямо противоположные результаты. Но ничего странного в этом нет.
Потому что в случае с ZRAM мы используем сжатую память вместо обычной, что ухудшает ее параметры. А ZSWAP использует сжатую память вместо дискового swap, который в любом случае гораздо более медленный.
‼️ Что касается совместного применения ZRAM и ZSWAP, то это не только лишено всякого смысла, но и серьезно ухудшает латентность, а также увеличивает нагрузку на CPU за счет двойного сжатия, потому что в этом случае у нас получится цепочка:
RAM – ZSWAP – ZRAM – SWAP
Поэтому так делать не нужно. А рекомендации просты:
🔹Мало памяти, нет особых требований к латентности – ZRAM
🔹Достаточно памяти, но требуется сгладить пики и улучшить производительность - ZSWAP
Каждый раз при упоминании этих технологий возникает ряд стандартных вопросов по их сходству и различию, а также совместному применению, поэтому давайте отдельно разберемся в этом вопросе.
1️⃣ Начнем с ZRAM. Эта технология создает в оперативной памяти блочное устройство и использует его в качестве пространства подкачки. Выделенная оперативная память сразу резервируется и не может быть использована системой.
Цель ZRAM – за счет сжатия предоставить системе большее количество доступной оперативной памяти, чем есть на самом деле. Это достигается за счет сжатия.
Средний коэффициент сжатия для LZ4 – 2,5, это значит, что, выделив для ZRAM 1 ГБ оперативной памяти мы получаем в свое распоряжение 2,5 ГБ очень быстрого swap, что позволяет достаточно эффективно решить вопрос нехватки ОЗУ.
Например, для машины с 4 ГБ ОЗУ, что по нынешним временам критический минимум, мы можем, разделив память пополам получить эквивалент 6-8 ГБ ОЗУ что радикально поменяет в лучшую сторону пользовательский опыт работы с системой.
Но за все нужно платить, за ZRAM мы платим процессорными ресурсами и ухудшением параметров доступа к сжатой памяти. Если сравнивать латентность доступа, то мы получим следующие цифры:
▫️Обычная RAM ~80–120 нс
▫️ZRAM (LZ4) ~1–5 мкс
▫️NVMe swap ~50–150 мкс
▫️SATA SSD swap ~200–500 мкс
▫️HDD swap миллисекунды
Как видим, ZRAM дает существенный рост латентности (в 10-50 раз), но все еще остается самым быстрым пространством подкачки, потому что даже при использовании быстрого NVMe разница будет уже на порядок.
Ну и ситуация, когда где-то что-то немного подтормаживает гораздо лучше ситуации, когда все стало колом из-за нехватки памяти.
Но если средняя латентность растет относительно незначительно, то вот рост tail latency (Tail latency (p95 / p99)) оказывается гораздо более высоким, что может приводить к заметным фризам и каскадному росту задержек.
Поэтому не следует использовать ZRAM в системах критичных к p95 / p99 – это большинство серверных применений, виртуализация и особенно СУБД, а также любые задачи критичные к задержкам, игры.
2️⃣ Теперь перейдем к ZSWAP, это Write Back кеш для пространств подкачки, общего с ZRAM у него только то, что он тоже использует сжатую память. В остальном это совершенно другая технология.
Так как это кеш, то выделенная память не резервируется сразу, а используется по мере необходимости, также кеш всегда может быть сброшен ядром.
Задача ZSWAP кеша – уменьшить количество обращений к пространствам подкачки на дисках, а выгода здесь также получается от сжатия данных.
Например, в системе с 16 ГБ памяти для ZSWAP по умолчанию резервируется 20% или 3,2 ГБ, что эквивалентно (для LZ4) примерно 8 ГБ несжатой памяти. Т.е. получаем неплохой такой раздел подкачки прямо в ОЗУ.
Что касается латентности, то она ничем не отличается от ZRAM, но в случае ZSWAP это только плюс, так как латентность сжатой памяти в 50-100 раз ниже, чем латентность быстрых NVME и на порядок лучше обычных дисков.
Это позволяет эффективно сглаживать пиковые нагрузки и уменьшает рост p95 / p99, что позитивно сказывается на чувствительных к задержкам рабочих процессах.
👉 Вот здесь внимательный читатель может удивиться, как так, одна и таже технология дает прямо противоположные результаты. Но ничего странного в этом нет.
Потому что в случае с ZRAM мы используем сжатую память вместо обычной, что ухудшает ее параметры. А ZSWAP использует сжатую память вместо дискового swap, который в любом случае гораздо более медленный.
‼️ Что касается совместного применения ZRAM и ZSWAP, то это не только лишено всякого смысла, но и серьезно ухудшает латентность, а также увеличивает нагрузку на CPU за счет двойного сжатия, потому что в этом случае у нас получится цепочка:
RAM – ZSWAP – ZRAM – SWAP
Поэтому так делать не нужно. А рекомендации просты:
🔹Мало памяти, нет особых требований к латентности – ZRAM
🔹Достаточно памяти, но требуется сгладить пики и улучшить производительность - ZSWAP
👍24🔥5❤1👌1🥱1
ZRAM и ZSWAP в Proxmox VE
В прошлой заметке мы подробно разобрали как работают ZRAM и ZSWAP, в чем их основное отличие и рекомендуемые сценарии использования. Но это касалось систем общего назначения, а когда мы переходим к специализированным системам, то расклад может измениться.
Поэтому мы отдельно остановимся на популярном средстве виртуализации Proxmox VE.
Казалось бы, а что там думать, серверная виртуализация, ZSWAP и всех делов. Но не все так просто. ZSWAP – функция ядра и для многих расположенных выше слоев системы она работает прозрачно. Приложение думает, что оно пишет в дисковый swap, а на самом деле оно пишет в кеш, расположенный в сжатой памяти.
И если с виртуалками проблем не возникает, то LXC-контейнеры начинают вести себя своеобразно. Напомним, что у контейнеров нет ни своей памяти, ни своей подкачки, они используют ресурсы хоста в пределах установленных для них лимитов.
Но для LXC использование SWAP-кеша не учитывается ни в одном лимите, в результате контейнер свободно выходит за пределы установленного лимита на подкачку.
На первый взгляд – ничего страшного, кеш в памяти, он быстрее любого, даже самого быстрого диска, пусть работает.
А теперь вспомним, что ZSWAP – это именно кеш, он может быть очищен ядром, он может начать вытеснять холодные данные на диск. Если коротко – это не гарантированное хранилище, а динамически выделяемый ресурс.
В итоге может оказаться так, что кеш придется сбросить, а места в дисковой подкачке у вас недостаточно, что вполне реально, если несколько контейнеров выйдут за лимиты. И тогда – привет OOM-Killer.
Либо, если вы выставили критичным службам защиту от указанного товарища, а именно они и сожрали память, то ваш сервер просто станет колом и потребуется принудительная перезагрузка.
Поэтому Proxmox не рекомендует использовать ZSWAP, а предлагает, неожиданно, ZRAM.
Но как так, спросит внимательный читатель, ведь только что вы писали, что ZRAM плохо влияет на производительность, особенно для виртуализации и СУБД.
Все верно, но это в том случае, если мы используем его в качестве расширителя объема ОЗУ.
Но если у нас достаточно памяти, то мы можем создать ZRAM устройство исключительно на замену swap. При этом, в Proxmox это отдельно подчеркивают, использование подкачки является временной мерой для защиты от OOM-Killer и использовать ее в качестве расширения памяти категорически не рекомендуется.
Т.е. здесь мы приходим к тому, что памяти у нас для виртуальных машин и контейнеров достаточно, а подкачка нужна для сглаживания пиков, но не для повседневной работы.
В этом случае перенос подкачки в ZRAM вполне оправдан, а так как это отдельное блочное устройство и настоящее пространство подкачки, то лимиты LXC здесь работают, как и задумано, считая несжатые данные.
Ну и совершенно понятно, что выделять в таком случае под ZRAM не следует ни 25%, ни, тем более 50% ОЗУ. Исходим из того, сколько реально подкачки нам надо и делим на коэффициент сжатия. Для LZ4 это 2,5, для ZSTD около 4.
Таким образом, если у нас есть хост с 64 ГБ ОЗУ, то отрезав всего 4 ГБ при помощи ZRAM и zstd мы спокойно организовываем пространство подкачки на 16 ГБ. Причем – быстрой подкачки.
При этом Proxmox настоятельно советует дисковую подкачку отключить, так как совместное использование ZRAM и дисковой подкачки может вызвать неконтролируемый рост задержек и привести к катастрофической дестабилизации системы.
В данном случае ZRAM предлагается использовать не как расширение памяти при ее недостатке, а как альтернативу дисковому swap, но в более предсказуемом виде, нежели ZSWAP-кеш.
Это еще раз показывает, что любая технология может приносить пользу, если ее применяют правильно, или стать источником проблем при бездумном использовании.
В прошлой заметке мы подробно разобрали как работают ZRAM и ZSWAP, в чем их основное отличие и рекомендуемые сценарии использования. Но это касалось систем общего назначения, а когда мы переходим к специализированным системам, то расклад может измениться.
Поэтому мы отдельно остановимся на популярном средстве виртуализации Proxmox VE.
Казалось бы, а что там думать, серверная виртуализация, ZSWAP и всех делов. Но не все так просто. ZSWAP – функция ядра и для многих расположенных выше слоев системы она работает прозрачно. Приложение думает, что оно пишет в дисковый swap, а на самом деле оно пишет в кеш, расположенный в сжатой памяти.
И если с виртуалками проблем не возникает, то LXC-контейнеры начинают вести себя своеобразно. Напомним, что у контейнеров нет ни своей памяти, ни своей подкачки, они используют ресурсы хоста в пределах установленных для них лимитов.
Но для LXC использование SWAP-кеша не учитывается ни в одном лимите, в результате контейнер свободно выходит за пределы установленного лимита на подкачку.
На первый взгляд – ничего страшного, кеш в памяти, он быстрее любого, даже самого быстрого диска, пусть работает.
А теперь вспомним, что ZSWAP – это именно кеш, он может быть очищен ядром, он может начать вытеснять холодные данные на диск. Если коротко – это не гарантированное хранилище, а динамически выделяемый ресурс.
В итоге может оказаться так, что кеш придется сбросить, а места в дисковой подкачке у вас недостаточно, что вполне реально, если несколько контейнеров выйдут за лимиты. И тогда – привет OOM-Killer.
Либо, если вы выставили критичным службам защиту от указанного товарища, а именно они и сожрали память, то ваш сервер просто станет колом и потребуется принудительная перезагрузка.
Поэтому Proxmox не рекомендует использовать ZSWAP, а предлагает, неожиданно, ZRAM.
Но как так, спросит внимательный читатель, ведь только что вы писали, что ZRAM плохо влияет на производительность, особенно для виртуализации и СУБД.
Все верно, но это в том случае, если мы используем его в качестве расширителя объема ОЗУ.
Но если у нас достаточно памяти, то мы можем создать ZRAM устройство исключительно на замену swap. При этом, в Proxmox это отдельно подчеркивают, использование подкачки является временной мерой для защиты от OOM-Killer и использовать ее в качестве расширения памяти категорически не рекомендуется.
Т.е. здесь мы приходим к тому, что памяти у нас для виртуальных машин и контейнеров достаточно, а подкачка нужна для сглаживания пиков, но не для повседневной работы.
В этом случае перенос подкачки в ZRAM вполне оправдан, а так как это отдельное блочное устройство и настоящее пространство подкачки, то лимиты LXC здесь работают, как и задумано, считая несжатые данные.
Ну и совершенно понятно, что выделять в таком случае под ZRAM не следует ни 25%, ни, тем более 50% ОЗУ. Исходим из того, сколько реально подкачки нам надо и делим на коэффициент сжатия. Для LZ4 это 2,5, для ZSTD около 4.
Таким образом, если у нас есть хост с 64 ГБ ОЗУ, то отрезав всего 4 ГБ при помощи ZRAM и zstd мы спокойно организовываем пространство подкачки на 16 ГБ. Причем – быстрой подкачки.
При этом Proxmox настоятельно советует дисковую подкачку отключить, так как совместное использование ZRAM и дисковой подкачки может вызвать неконтролируемый рост задержек и привести к катастрофической дестабилизации системы.
В данном случае ZRAM предлагается использовать не как расширение памяти при ее недостатке, а как альтернативу дисковому swap, но в более предсказуемом виде, нежели ZSWAP-кеш.
Это еще раз показывает, что любая технология может приносить пользу, если ее применяют правильно, или стать источником проблем при бездумном использовании.
👍38🔥6❤5🥱1
Как правильно определить количество свободной памяти в Linux
Классика жанра – почему у меня в системе не хватает памяти, если системный монитор или панель говорят, что памяти еще достаточно.
Сегодня снова задали такой вопрос, мол если верить Proxmox, то памяти еще хватает (занято 70%), но Zabbix начал сигналить о катастрофической нехватке памяти (занято свыше 90%). Кто не прав?
Чтобы это понять выполним в консоли команду:
И изучим ее вывод, он содержит несколько столбцов:
▫️ total: Общее количество установленной физической памяти.
▫️ used: Количество памяти, которое в настоящее время используется.
▫️ free: Свободная физической памяти, доступная для немедленного использования.
▫️shared: Память, которая разделяется между процессами, например, библиотеки, которые могут быть использованы несколькими процессами одновременно.
▫️ buffers/cache: Память, которая используется в качестве буферов для операций ввода-вывода и в качестве кэша для операций
▫️ available: Количество памяти, которая доступна для использования, учитывая, что часть памяти, используемая как buffers/cache может быть освобождена при необходимости.
Если сравнить то, что показывает Proxmox, системный монитор и т.д., то он показывает именно available. Так может нечего переживать? Все норм и Zabbiх зря нагоняет панику?
А вот и нет. Во-первых, не все буферы можно сбросить, во-вторых, сброс буферов – дорогая операция, так как в последующем вместо быстрого доступа к нужным данным из памяти мы получим медленное чтение и с диска.
И система, если процесс попросит памяти больше, чем free еще десять раз подумает, а сбрасывать ли буфер?
А помогать ей в этом будет OOM Killer, который ведет строгий учет всех запущенных процессов, оценивая их по множеству критериев и присваивая «очки негодности».
И альтернативой сброса буферов может оказаться убийство «негодного» процесса. И скорее всего так оно и произойдет. Хотя со стороны кажется, что память еще есть и можно развернуться.
На нашей практике примерно в такой же ситуации регулярно выключалась неактивная виртуалка. И администратор долго не мог понять почему, пока не посмотрел на вывод free, а не дашборды Proxmox.
Поэтому не следует верить тому, что показывают графики или индикаторы, все, на что вы можете железобетонно рассчитывать – это free, а available – это то, что могут дать, а могут догнать и еще раз дать. Учитывайте это.
И Zabbix в этом случае не нагоняет жути, а по сути прав, так как учитывает описанные выше особенности.
А на закуску можем посоветовать почитать наши статьи:
🔹 Что такое пространства подкачки и как они работают
🔹 Что такое OOM Killer и как он работает
Классика жанра – почему у меня в системе не хватает памяти, если системный монитор или панель говорят, что памяти еще достаточно.
Сегодня снова задали такой вопрос, мол если верить Proxmox, то памяти еще хватает (занято 70%), но Zabbix начал сигналить о катастрофической нехватке памяти (занято свыше 90%). Кто не прав?
Чтобы это понять выполним в консоли команду:
free – h
И изучим ее вывод, он содержит несколько столбцов:
▫️ total: Общее количество установленной физической памяти.
▫️ used: Количество памяти, которое в настоящее время используется.
▫️ free: Свободная физической памяти, доступная для немедленного использования.
▫️shared: Память, которая разделяется между процессами, например, библиотеки, которые могут быть использованы несколькими процессами одновременно.
▫️ buffers/cache: Память, которая используется в качестве буферов для операций ввода-вывода и в качестве кэша для операций
▫️ available: Количество памяти, которая доступна для использования, учитывая, что часть памяти, используемая как buffers/cache может быть освобождена при необходимости.
Если сравнить то, что показывает Proxmox, системный монитор и т.д., то он показывает именно available. Так может нечего переживать? Все норм и Zabbiх зря нагоняет панику?
А вот и нет. Во-первых, не все буферы можно сбросить, во-вторых, сброс буферов – дорогая операция, так как в последующем вместо быстрого доступа к нужным данным из памяти мы получим медленное чтение и с диска.
И система, если процесс попросит памяти больше, чем free еще десять раз подумает, а сбрасывать ли буфер?
А помогать ей в этом будет OOM Killer, который ведет строгий учет всех запущенных процессов, оценивая их по множеству критериев и присваивая «очки негодности».
И альтернативой сброса буферов может оказаться убийство «негодного» процесса. И скорее всего так оно и произойдет. Хотя со стороны кажется, что память еще есть и можно развернуться.
На нашей практике примерно в такой же ситуации регулярно выключалась неактивная виртуалка. И администратор долго не мог понять почему, пока не посмотрел на вывод free, а не дашборды Proxmox.
Поэтому не следует верить тому, что показывают графики или индикаторы, все, на что вы можете железобетонно рассчитывать – это free, а available – это то, что могут дать, а могут догнать и еще раз дать. Учитывайте это.
И Zabbix в этом случае не нагоняет жути, а по сути прав, так как учитывает описанные выше особенности.
А на закуску можем посоветовать почитать наши статьи:
🔹 Что такое пространства подкачки и как они работают
🔹 Что такое OOM Killer и как он работает
👍30❤6🥱3
KSM Sharing или почему не стоит разводить зоопарк виртуальных машин
KSM (Kernel Same-page Merging) - специальная технология ядра Linux, позволяющая объединять страницы памяти разных процессов, тем самым добиваясь ее экономии.
Фактически данный процесс можно назвать дедупликацией оперативной памяти. При наличии большого количества однотипных виртуальных машин эффект от использования KSM может быть достаточно ощутимым.
Важно понимать, что KSM работает только с виртуальными машинами и с контейнерами она неприменима.
Оценить эффект от применения KSM можно при наличии некоторого количества однотипных виртуалок. Буквально на днях мы ввели в эксплуатацию два новых гипервизора по 6 виртуальных машин на каждой.
Каждая ВМ представляет установку Debian 12 и УТМ ЕГАИС. Номинальное потребление ОЗУ каждой виртуальной машиной: 1,41-1,43 ГБ, т.е. суммарно мы должны получить 1,42 х 6 = 8,52 ГБ.
И это только виртуалки, не считая хоста. По факту имеем объем общей KMS памяти 4,99 ГБ, т.е. экономия составила примерно 58%. И общее потребление, вместе с гипервизором – 6,54 ГБ.
На наш взгляд – это отличный результат. Так как именно оперативная память, несмотря не ее дешевизну, является наиболее ограниченным ресурсом при виртуализации.
Для используемой платформы максимальный объем памяти – 16 ГБ и мы по факту увеличили доступную память примерно на 25-30%, что очень и очень неплохо.
Но чтобы добиться подобного результата нужна серьезная унификация. Все виртуалки должны иметь одну версию ОС, одну версию ядра и основных системных библиотек.
Хотя мы не раз встречали ситуацию, когда админы использовали в виртуалках разные ОС под разные задачи. Ну просто потому, что им так нравится, привыкли и т.д. и т.п. Без внятных аргументов в пользу такой позиции.
В тоже время KSM Sharing – это серьезный аргумент пересмотреть свои взгляды и отказаться от зоопарка систем в виртуальных машинах.
А прочитать более подробно о его настройках можно в нашей статье: https://interface31.ru/tech_it/2022/07/nastraivaem-ispolzovanie-ram-pri-rabote-s-zfs-v-proxmox-ve.html
KSM (Kernel Same-page Merging) - специальная технология ядра Linux, позволяющая объединять страницы памяти разных процессов, тем самым добиваясь ее экономии.
Фактически данный процесс можно назвать дедупликацией оперативной памяти. При наличии большого количества однотипных виртуальных машин эффект от использования KSM может быть достаточно ощутимым.
Важно понимать, что KSM работает только с виртуальными машинами и с контейнерами она неприменима.
Оценить эффект от применения KSM можно при наличии некоторого количества однотипных виртуалок. Буквально на днях мы ввели в эксплуатацию два новых гипервизора по 6 виртуальных машин на каждой.
Каждая ВМ представляет установку Debian 12 и УТМ ЕГАИС. Номинальное потребление ОЗУ каждой виртуальной машиной: 1,41-1,43 ГБ, т.е. суммарно мы должны получить 1,42 х 6 = 8,52 ГБ.
И это только виртуалки, не считая хоста. По факту имеем объем общей KMS памяти 4,99 ГБ, т.е. экономия составила примерно 58%. И общее потребление, вместе с гипервизором – 6,54 ГБ.
На наш взгляд – это отличный результат. Так как именно оперативная память, несмотря не ее дешевизну, является наиболее ограниченным ресурсом при виртуализации.
Для используемой платформы максимальный объем памяти – 16 ГБ и мы по факту увеличили доступную память примерно на 25-30%, что очень и очень неплохо.
Но чтобы добиться подобного результата нужна серьезная унификация. Все виртуалки должны иметь одну версию ОС, одну версию ядра и основных системных библиотек.
Хотя мы не раз встречали ситуацию, когда админы использовали в виртуалках разные ОС под разные задачи. Ну просто потому, что им так нравится, привыкли и т.д. и т.п. Без внятных аргументов в пользу такой позиции.
В тоже время KSM Sharing – это серьезный аргумент пересмотреть свои взгляды и отказаться от зоопарка систем в виртуальных машинах.
А прочитать более подробно о его настройках можно в нашей статье: https://interface31.ru/tech_it/2022/07/nastraivaem-ispolzovanie-ram-pri-rabote-s-zfs-v-proxmox-ve.html
👍19❤3🥱2
Как получить полный дистрибутив конфигурации 1С:Предприятие
Многие коллеги активно пользуются Порталом 1C:Обновление программ для получения обновлений. Но когда требуется скачать полный дистрибутив начинаются определенные сложности.
Обычно в этом случае рекомендуют обратиться к обслуживающему франчайзи, некоторые начинают искать дистрибутивы в широко известных «злачных местах», но на самом деле все гораздо проще.
Достаточно просто скопировать ссылку на дистрибутив обновления и в самом ее конце заменить:
На
B результате вы получите ссылку на скачивание полного дистрибутива и это не какой-нибудь лайфхак, а штатная, документированная возможность.
Для подтверждения скачивания вам потребуется дополнительная аутентификация с помощью одноразового пароля, который будет выслан на номер телефона указанный в профиле.
Многие коллеги активно пользуются Порталом 1C:Обновление программ для получения обновлений. Но когда требуется скачать полный дистрибутив начинаются определенные сложности.
Обычно в этом случае рекомендуют обратиться к обслуживающему франчайзи, некоторые начинают искать дистрибутивы в широко известных «злачных местах», но на самом деле все гораздо проще.
Достаточно просто скопировать ссылку на дистрибутив обновления и в самом ее конце заменить:
_updsetup.zip
На
_setup1c.zip
B результате вы получите ссылку на скачивание полного дистрибутива и это не какой-нибудь лайфхак, а штатная, документированная возможность.
Для подтверждения скачивания вам потребуется дополнительная аутентификация с помощью одноразового пароля, который будет выслан на номер телефона указанный в профиле.
👍35🔥11👌5🤮2❤1
Отказоустойчивость или высокая доступность?
Каждый раз, когда речь заходит о кластерных решениях начинает звучать термин «отказоустойчивый». В связи с этим у многих, особенно не посвященных в тонкости технологии возникают неверные ожидания, которые приводят к негативному опыту эксплуатации подобных систем.
Почему? Потому что «как вы лодку назовете, так она и поплывет». Начнем с понятия «отказоустойчивость». В русском языке он не допускает двойного толкования и обозначает устойчивость системы к отказу части ее компонентов.
Отказоустойчивость, как инженерное понятие, предусматривает сохранение работоспособности системы, возможно с ухудшением эксплуатационных характеристик, при отказе одного или нескольких компонентов.
Примером отказоустойчивой системы можно считать RAID (кроме RAID 0), который сохраняет работоспособность, несмотря на ухудшение характеристик для уровней с четностью, при выходе из строя заданного числа дисков.
При этом сам отказ происходит без видимых последствий для системы и пользователя. На том же RAID1 (зеркало) вы можете вообще не заметить выход из строя одного из дисков.
Теперь вернемся к кластеризации. Является ли кластер отказоустойчивым? Если говорить о современной кластеризации, когда мы говорим о виртуальных средах – то нет. Но то же самое касается и классической кластеризации приложений.
Приложение ничего не знает о внутренней кухне кластера, и оно работает с некоторым сервисом, который запущен не в сферическом вакууме, а на одной из нод кластера или на виртуальной машине, которая выполняется на одной из нод.
При этом все сетевые подключения принимает именно конкретная нода и именно в ее оперативной памяти находится обрабатываемая экземпляром сервиса информация.
Что будет при отказе этой ноды? Все открытые сеансы будут закрыты, вся несохраненная информация в оперативной памяти потеряна, все незафиксированные транзакции будут в последствии откачены.
Так о какой отказоустойчивости идет речь? Понятно, что отказоустойчивостью в классическом ее понимании тут и не пахнет. Все дело в неправильном и неудачном переводе термина «failover», в английском языке, в отличие от русского, имеющего несколько значений.
Одно из них действительно «отказоустойчивый», но в другом контексте это же слово переводится как «с обработкой отказа», что более точно отражает происходящие в кластере процессы.
Что делает кластер в случае отказа одной из нод? Он запускает отказавшие сервисы на оставшихся нодах, либо перенаправляет сеансы пользователей на работающие экземпляры служб.
Это и называется «обработка отказа», т.е. при отказе одной из нод кластер автоматически выполняет восстановление отказавшего сервиса. Но это не отказоустойчивость, а именно быстрое восстановление.
А можно ли передать рабочие процессы с одной ноды на другую без прерывания их работы? В целом да, но только при условии нормально функционирующего кластера. В этом случае одна нода передает другой содержимое оперативной памяти процесса и переключает на нее сетевые соединения.
Что касается виртуализации, то миграция без остановки работы доступна только для виртуальных машин и недоступна для контейнеров. Почему? Потому что контейнер использует ядро и окружение хостовой системы, которое невозможно передать на другой хост, поэтому контейнер обязательно потребуется перезапустить после передачи на другую ноду.
В случае отказа ноды содержимое памяти как виртуальной машины, так и контейнера теряется, и мы можем только выполнить холодный перезапуск на другом узле.
В связи с чем сегодня употребление термина «failover» считается нежелательным, как и русскоязычного «отказоустойчивый». Для того, чтобы избежать путаницы рекомендуется использовать термин «high availability» или «высокая доступность» по-русски.
Этот термин не вызывает неоправданных ожиданий и абсолютно верно отражает основную характеристику системы – доступность. Потому что даже при отказе одного или нескольких узлов ваши сервисы будут в течении короткого времени восстановлены и снова окажутся доступны для пользователей.
Каждый раз, когда речь заходит о кластерных решениях начинает звучать термин «отказоустойчивый». В связи с этим у многих, особенно не посвященных в тонкости технологии возникают неверные ожидания, которые приводят к негативному опыту эксплуатации подобных систем.
Почему? Потому что «как вы лодку назовете, так она и поплывет». Начнем с понятия «отказоустойчивость». В русском языке он не допускает двойного толкования и обозначает устойчивость системы к отказу части ее компонентов.
Отказоустойчивость, как инженерное понятие, предусматривает сохранение работоспособности системы, возможно с ухудшением эксплуатационных характеристик, при отказе одного или нескольких компонентов.
Примером отказоустойчивой системы можно считать RAID (кроме RAID 0), который сохраняет работоспособность, несмотря на ухудшение характеристик для уровней с четностью, при выходе из строя заданного числа дисков.
При этом сам отказ происходит без видимых последствий для системы и пользователя. На том же RAID1 (зеркало) вы можете вообще не заметить выход из строя одного из дисков.
Теперь вернемся к кластеризации. Является ли кластер отказоустойчивым? Если говорить о современной кластеризации, когда мы говорим о виртуальных средах – то нет. Но то же самое касается и классической кластеризации приложений.
Приложение ничего не знает о внутренней кухне кластера, и оно работает с некоторым сервисом, который запущен не в сферическом вакууме, а на одной из нод кластера или на виртуальной машине, которая выполняется на одной из нод.
При этом все сетевые подключения принимает именно конкретная нода и именно в ее оперативной памяти находится обрабатываемая экземпляром сервиса информация.
Что будет при отказе этой ноды? Все открытые сеансы будут закрыты, вся несохраненная информация в оперативной памяти потеряна, все незафиксированные транзакции будут в последствии откачены.
Так о какой отказоустойчивости идет речь? Понятно, что отказоустойчивостью в классическом ее понимании тут и не пахнет. Все дело в неправильном и неудачном переводе термина «failover», в английском языке, в отличие от русского, имеющего несколько значений.
Одно из них действительно «отказоустойчивый», но в другом контексте это же слово переводится как «с обработкой отказа», что более точно отражает происходящие в кластере процессы.
Что делает кластер в случае отказа одной из нод? Он запускает отказавшие сервисы на оставшихся нодах, либо перенаправляет сеансы пользователей на работающие экземпляры служб.
Это и называется «обработка отказа», т.е. при отказе одной из нод кластер автоматически выполняет восстановление отказавшего сервиса. Но это не отказоустойчивость, а именно быстрое восстановление.
А можно ли передать рабочие процессы с одной ноды на другую без прерывания их работы? В целом да, но только при условии нормально функционирующего кластера. В этом случае одна нода передает другой содержимое оперативной памяти процесса и переключает на нее сетевые соединения.
Что касается виртуализации, то миграция без остановки работы доступна только для виртуальных машин и недоступна для контейнеров. Почему? Потому что контейнер использует ядро и окружение хостовой системы, которое невозможно передать на другой хост, поэтому контейнер обязательно потребуется перезапустить после передачи на другую ноду.
В случае отказа ноды содержимое памяти как виртуальной машины, так и контейнера теряется, и мы можем только выполнить холодный перезапуск на другом узле.
В связи с чем сегодня употребление термина «failover» считается нежелательным, как и русскоязычного «отказоустойчивый». Для того, чтобы избежать путаницы рекомендуется использовать термин «high availability» или «высокая доступность» по-русски.
Этот термин не вызывает неоправданных ожиданий и абсолютно верно отражает основную характеристику системы – доступность. Потому что даже при отказе одного или нескольких узлов ваши сервисы будут в течении короткого времени восстановлены и снова окажутся доступны для пользователей.
👍49
Proxmox Datacenter Manager – что это за зверь и кому он нужен
Не так давно вышел новый продукт в экосистеме Proxmox - Datacenter Manager, но предназначен для централизованного управления инфраструктурой и поддерживает как кластеры PVE, так и отдельные ноды.
На первый взгляд может оказаться непонятно, что это за зверь и с чем его есть нужно. Поэтому попробуем разобраться. Системные требования невелики: 1 ядро, 1 ГБ ОЗУ и 10 ГБ на диске. Рекомендуемые немного повыше: от 2 ядер, 4 ГБ ОЗУ и 40 ГБ дискового пространства.
Установить можно как с официального ISO образа, так и подключив репозитории к Debian 13. Ввиду того, что это, по сути, обычная панель управления она так и напрашивается на виртуализацию, что мы и сделали.
Никаких сложностей при установке не возникло, по инструкции подключили репозитории, скачали ключ, установили пакеты. Всего с зависимостями продукт занимает 1,7 ГБ.
Затем переходим по адресу
Мы добавили два отдельных гипервизора PVE и один сервер резервного копирования PBS и уже через некоторое время в дашборде мы можем увидеть основные показатели. Сколько нод запушено, сколько на них виртуалок и контейнеров, что запущено, что остановлено.
Ниже начинает собираться статистика по нагрузке CPU гостевых систем и нод, а также использование оперативной памяти на нодах, списки сортируются по наиболее высокой загрузке.
В целом достаточно удобно, позволяет быстро оценить состояние инфраструктуры в целом.
Перейдем к управлению нодой, на первый взгляд тут все похоже на родной интерфейс PVE, за одним только исключением что кроме как посмотреть графики мы практически ничего не можем.
Для самой ноды доступна только функция обновления, а для виртуальных машин старт, стоп и миграция. Миграцию можно производить как в кластере, так и для отдельных гипервизоров. Но это далеко не новинка, данная функция доступна в командной строке начиная с версии 7.3
Если мы перейдем в саму виртуальную машину или контейнер, то мы также увидим основную статистику и сможем прочитать конфигурацию, никаких других действий недоступно.
Для Proxmox Backup Server можно только обновить узел и посмотреть, никаких иных функций управления не предусмотрено.
Поэтому рассматривать Proxmox Datacenter Manager как инструмент управления на данном этапе его развития мы бы не стали. Потому что управлять там, по сути, нечем.
А вот как инструмент контроля и базового мониторинга – да, чтобы не прыгать по веб-интерфейсам гипервизоров, а получить всю основную информацию в одном месте.
Естественно, на этом разработчики не ограничатся и планы у них достаточно обширные, но на текущий момент какой-либо насущной необходимости в Proxmox Datacenter Manager для большинства пользователей нет.
Не так давно вышел новый продукт в экосистеме Proxmox - Datacenter Manager, но предназначен для централизованного управления инфраструктурой и поддерживает как кластеры PVE, так и отдельные ноды.
На первый взгляд может оказаться непонятно, что это за зверь и с чем его есть нужно. Поэтому попробуем разобраться. Системные требования невелики: 1 ядро, 1 ГБ ОЗУ и 10 ГБ на диске. Рекомендуемые немного повыше: от 2 ядер, 4 ГБ ОЗУ и 40 ГБ дискового пространства.
Установить можно как с официального ISO образа, так и подключив репозитории к Debian 13. Ввиду того, что это, по сути, обычная панель управления она так и напрашивается на виртуализацию, что мы и сделали.
Никаких сложностей при установке не возникло, по инструкции подключили репозитории, скачали ключ, установили пакеты. Всего с зависимостями продукт занимает 1,7 ГБ.
Затем переходим по адресу
https://youripaddress:8443 и попадаем в графический веб-интерфейс, он вполне привычен для пользователей Proxmox, разве что отличается более современным стилем. Теперь можно добавлять узлы.Мы добавили два отдельных гипервизора PVE и один сервер резервного копирования PBS и уже через некоторое время в дашборде мы можем увидеть основные показатели. Сколько нод запушено, сколько на них виртуалок и контейнеров, что запущено, что остановлено.
Ниже начинает собираться статистика по нагрузке CPU гостевых систем и нод, а также использование оперативной памяти на нодах, списки сортируются по наиболее высокой загрузке.
В целом достаточно удобно, позволяет быстро оценить состояние инфраструктуры в целом.
Перейдем к управлению нодой, на первый взгляд тут все похоже на родной интерфейс PVE, за одним только исключением что кроме как посмотреть графики мы практически ничего не можем.
Для самой ноды доступна только функция обновления, а для виртуальных машин старт, стоп и миграция. Миграцию можно производить как в кластере, так и для отдельных гипервизоров. Но это далеко не новинка, данная функция доступна в командной строке начиная с версии 7.3
Если мы перейдем в саму виртуальную машину или контейнер, то мы также увидим основную статистику и сможем прочитать конфигурацию, никаких других действий недоступно.
Для Proxmox Backup Server можно только обновить узел и посмотреть, никаких иных функций управления не предусмотрено.
Поэтому рассматривать Proxmox Datacenter Manager как инструмент управления на данном этапе его развития мы бы не стали. Потому что управлять там, по сути, нечем.
А вот как инструмент контроля и базового мониторинга – да, чтобы не прыгать по веб-интерфейсам гипервизоров, а получить всю основную информацию в одном месте.
Естественно, на этом разработчики не ограничатся и планы у них достаточно обширные, но на текущий момент какой-либо насущной необходимости в Proxmox Datacenter Manager для большинства пользователей нет.
👍44❤3
Онлайн миграция виртуальных машин и контейнеров Proxmox VE между узлами при помощи remote-migrate
Миграция виртуальных машин и контейнеров между узлами, не входящими в один кластер, достаточно часто встречающаяся задача. Наиболее простой способ - через выгрузку-загрузку резервной копии, но он может занять продолжительное время и не решает вопроса миграции с минимальным простоем.
Начиная с Proxmox VE 7.3 мы можем использовать штатную утилиту remote-migrate, которая позволяет выполнить это задачу в кратчайшие сроки и даже поддерживает онлайн-миграцию.
Сразу начнем с того, что утилита remote-migrate до сих пор является экспериментальной, а это значит, что не все возможности могут поддерживаться на текущий момент или в работе утилиты могут происходить ошибки. Поэтому используем ее на свой страх и риск.
Начнем с ограничений, они выявлены нами эмпирическим путем, часть из них подтверждена на официальном форуме. Поэтому данный список не является исчерпывающим.
▫️ Миграция виртуальных машин и контейнеров с ZFS-хранилища возможна только в ZFS-хранилище
▫️Миграция дисков формата Qcow2 возможна только в хранилище с поддержкой данного формата
▫️Версия QEMU принимающего узла должна быть не ниже версии отправляющего узла
Если обобщить, то самым универсальным для миграции форматом диска является RAW, который используется в том числе и для LVM-томов. Так как физически протестировать все варианты хранилищ у нас не было никакой возможности, то на практике вы можете столкнуться и с иными ограничениями.
В этом случае вам следует выполнить конвертацию диска перенеся его в хранилище нужного типа. После этого не забудьте удалить старый диск, иначе миграция окончится неудачей.
✅ Читать далее
Миграция виртуальных машин и контейнеров между узлами, не входящими в один кластер, достаточно часто встречающаяся задача. Наиболее простой способ - через выгрузку-загрузку резервной копии, но он может занять продолжительное время и не решает вопроса миграции с минимальным простоем.
Начиная с Proxmox VE 7.3 мы можем использовать штатную утилиту remote-migrate, которая позволяет выполнить это задачу в кратчайшие сроки и даже поддерживает онлайн-миграцию.
Сразу начнем с того, что утилита remote-migrate до сих пор является экспериментальной, а это значит, что не все возможности могут поддерживаться на текущий момент или в работе утилиты могут происходить ошибки. Поэтому используем ее на свой страх и риск.
Начнем с ограничений, они выявлены нами эмпирическим путем, часть из них подтверждена на официальном форуме. Поэтому данный список не является исчерпывающим.
▫️ Миграция виртуальных машин и контейнеров с ZFS-хранилища возможна только в ZFS-хранилище
▫️Миграция дисков формата Qcow2 возможна только в хранилище с поддержкой данного формата
▫️Версия QEMU принимающего узла должна быть не ниже версии отправляющего узла
Если обобщить, то самым универсальным для миграции форматом диска является RAW, который используется в том числе и для LVM-томов. Так как физически протестировать все варианты хранилищ у нас не было никакой возможности, то на практике вы можете столкнуться и с иными ограничениями.
В этом случае вам следует выполнить конвертацию диска перенеся его в хранилище нужного типа. После этого не забудьте удалить старый диск, иначе миграция окончится неудачей.
✅ Читать далее
1👍30🔥2🥱1🤝1
Тонкая настройка systemd-journald
Классическая ситуация – все место на диске занято логами, либо логи создают излишнюю нагрузку на систему ввода вывода.
Чтобы этого не случилось – логирование нужно настроить в соответствии с реальными потребностями и сегодня мы посмотрим, как это сделать для systemd-journald.
Прежде всего посмотрим текущие настройки, это можно сделать командой:
По умолчанию все значение в нем закомментированы и представляют настройки службы по умолчанию. Для изменения вы можете использовать данный файл, но официально рекомендуется использовать технологию "drop-ins" и хранить настройки в отдельных файлах.
Создадим для этого директорию:
А в нем один или несколько файлов с изменениями конфигурации, в нашем случае это будет
Начнем с места хранения логов. Для сохранения на диск используйте:
Это более надежно, чем auto, которое может иногда приводить к сюрпризам. Если же вам не нужна запись логов на диск, но вы хотите иметь их для диагностики и отладки используйте хранение в оперативной памяти. Такой метод рекомендуется для виртуальных машин и контейнеров, а также встраиваемых устройств и мини-ПК.
Затем проверьте опции:
Первая из них включает сжатие логов, вторая – криптографическую защиту, обычно обе включены по умолчанию.
Хранить логи – это хорошо, но не ограничивать размер – очень плохо, поэтому сразу озаботимся этим:
Первая опция задает максимальный размер хранилища логов, а второй нижний предел свободного места. Таким образом мы будем хранить не более одного гигабайта логов, но при условии, что в системе остается не менее 2 ГБ свободного места.
Если вы храните данные в ОЗУ, то используйте следующие опции аналогичного назначения:
Опции
Задают максимальный размер одного файла журнала и их общее количество, по умолчанию systemd-journald создает файлы размером 8 МБ.
Для хранения в оперативной памяти аналогичные опции:
Следующие важные настройки – это уровни логирования, в продуктивных средах нет необходимости хранить логи уровня debug, будет вполне достаточно info или notice. Поэтому замените debug на более низкий уровень логирования в этих трех опциях:
Данный набор опций отвечает за пересылку логов в syslog, kernel buffer, консоль и отправку сообщения пользователям.
Настройки по умолчанию (указаны выше) оптимальны и без необходимости пересылку включать не следует. Единственная включенная пересылка – это отправка пользователям сообщений уровня emerg (катастрофический сбой).
Еще одна важная опция – это лимиты, позволяющие избегать засорения логов однотипными сообщениями. По умолчанию имеет следующие значения:
Это означает, что в течении 30 секунд можно отправить в лог не более 10 000 сообщений. Обратите внимание, что данный лимит действует для каждого источника событий, а не для всей системы.
В высоконагруженных системах лимит можно повысить, например, для гипервизоров, где виртуалки при старте могут быть достаточно «разговорчивы». В виртуальных средах, наоборот, имеет смысл понизить этот лимит, чтобы избежать массового спама логов сбойным сервисом.
Классическая ситуация – все место на диске занято логами, либо логи создают излишнюю нагрузку на систему ввода вывода.
Чтобы этого не случилось – логирование нужно настроить в соответствии с реальными потребностями и сегодня мы посмотрим, как это сделать для systemd-journald.
Прежде всего посмотрим текущие настройки, это можно сделать командой:
cat /etc/systemd/journald.conf
По умолчанию все значение в нем закомментированы и представляют настройки службы по умолчанию. Для изменения вы можете использовать данный файл, но официально рекомендуется использовать технологию "drop-ins" и хранить настройки в отдельных файлах.
Создадим для этого директорию:
mkdir -p /etc/systemd/journald.conf.d
А в нем один или несколько файлов с изменениями конфигурации, в нашем случае это будет
00-journal.conf куда мы будем вносить изменившиеся опции.Начнем с места хранения логов. Для сохранения на диск используйте:
Storage=persistent
Это более надежно, чем auto, которое может иногда приводить к сюрпризам. Если же вам не нужна запись логов на диск, но вы хотите иметь их для диагностики и отладки используйте хранение в оперативной памяти. Такой метод рекомендуется для виртуальных машин и контейнеров, а также встраиваемых устройств и мини-ПК.
Storage=volatile
Затем проверьте опции:
Compress=yes
Seal=yes
Первая из них включает сжатие логов, вторая – криптографическую защиту, обычно обе включены по умолчанию.
Хранить логи – это хорошо, но не ограничивать размер – очень плохо, поэтому сразу озаботимся этим:
SystemMaxUse=1G
SystemKeepFree=2G
Первая опция задает максимальный размер хранилища логов, а второй нижний предел свободного места. Таким образом мы будем хранить не более одного гигабайта логов, но при условии, что в системе остается не менее 2 ГБ свободного места.
Если вы храните данные в ОЗУ, то используйте следующие опции аналогичного назначения:
RuntimeMaxUse=64M
RuntimeKeepFree=256M
Опции
SystemMaxFileSize=
SystemMaxFiles=100
Задают максимальный размер одного файла журнала и их общее количество, по умолчанию systemd-journald создает файлы размером 8 МБ.
Для хранения в оперативной памяти аналогичные опции:
RuntimeMaxFileSize=
RuntimeMaxFiles=100
Следующие важные настройки – это уровни логирования, в продуктивных средах нет необходимости хранить логи уровня debug, будет вполне достаточно info или notice. Поэтому замените debug на более низкий уровень логирования в этих трех опциях:
MaxLevelStore=debug
MaxLevelSyslog=debug
MaxLevelSocket=debug
Данный набор опций отвечает за пересылку логов в syslog, kernel buffer, консоль и отправку сообщения пользователям.
ForwardToSyslog=no
ForwardToKMsg=no
ForwardToConsole=no
ForwardToWall=yes
Настройки по умолчанию (указаны выше) оптимальны и без необходимости пересылку включать не следует. Единственная включенная пересылка – это отправка пользователям сообщений уровня emerg (катастрофический сбой).
Еще одна важная опция – это лимиты, позволяющие избегать засорения логов однотипными сообщениями. По умолчанию имеет следующие значения:
RateLimitIntervalSec=30s
RateLimitBurst=10000
Это означает, что в течении 30 секунд можно отправить в лог не более 10 000 сообщений. Обратите внимание, что данный лимит действует для каждого источника событий, а не для всей системы.
В высоконагруженных системах лимит можно повысить, например, для гипервизоров, где виртуалки при старте могут быть достаточно «разговорчивы». В виртуальных средах, наоборот, имеет смысл понизить этот лимит, чтобы избежать массового спама логов сбойным сервисом.
👍31❤6👌1🤣1
Настройка перезапуска пула приложений IIS
IIS, как и любое иное приложение, имеет свои особенности и настройки, некоторые из которых, не будучи известными способны доставить администратору ряд затруднений.
У веб-сервера IIS есть штатная опция перезапуска пула приложений IIS, которая призвана мягко перезапустить пул приложений в целях борьбы с утечками памяти, зависшими сеансами, заблокированными файлами, просроченным кешем и т.д. и т.п.
При использовании IIS совместно в веб-публикацией 1С:Предприятие такое поведение полезно, так как утечки памяти и незавершенные сеансы для этой связки «нормальное» явление.
Но, хотели как лучше – получилось, как всегда. Выяснилось, что 1С:Предприятие не умеет «мягко» перезапускаться на IIS и перезапуск приводит к аварийному завершению сеанса пользователя с потерей несохраненных данных.
Но это еще половина беды, сама 1С выдает сообщение, что «Сеанс завершен администратором». Такая формулировка уже не раз приводила к конфликтным ситуациями, поскольку пользователи думают, что причина сбоя – некоторые действия или технические работы администраторов.
А теперь вишенка на торте – по умолчанию перезапуск пула приложений настроен с интервалом 1740 минут или 29 часов. Это делает процесс для внешнего наблюдателя рандомным и несистематическим.
Пользователя дня два выбрасывает из 1С в рабочее время, время разное, потом снова все хорошо. В системном журнале данные события отображаются со статусом Сведения и ничем не выделяются на общем фоне.
С учетом того, что пользователи редко фиксируют точное время проблемы диагностика «плавающей» неисправности становится весьма затруднительной. Отсюда начинаются слухи о глючности IIS, судорожные попытки миграции на Apache и прочие телодвижения.
Но на самом деле надо просто настроить перезапуск. Обращаем ваше внимание, что его нужно настроить для каждого пула приложений, если их несколько.
Переходим Пулы приложений – Выбранный пул – Дополнительные параметры
Пролистываем до секции Перезапуск, находим там параметр Моменты точного времени для перезапуска и добавляем туда желаемое время перезапуска пула. Мы выбрали для себя 6 часов утра.
Данный параметр представляет из себя массив, и вы можете добавить несколько моментов времени для перезапуска. Также не забывайте про часовой пояс сервера и часовой пояс клиента.
После чего еще ниже находим опцию Постоянный временной интервал (в минутах), которая и была причиной всех наших безобразий и устанавливаем ей значение в ноль.
Изменив значения не забываем перезапустить пул или веб-сервер полностью (ну или ждем пока он сам в очередной раз перезапустится).
IIS, как и любое иное приложение, имеет свои особенности и настройки, некоторые из которых, не будучи известными способны доставить администратору ряд затруднений.
У веб-сервера IIS есть штатная опция перезапуска пула приложений IIS, которая призвана мягко перезапустить пул приложений в целях борьбы с утечками памяти, зависшими сеансами, заблокированными файлами, просроченным кешем и т.д. и т.п.
При использовании IIS совместно в веб-публикацией 1С:Предприятие такое поведение полезно, так как утечки памяти и незавершенные сеансы для этой связки «нормальное» явление.
Но, хотели как лучше – получилось, как всегда. Выяснилось, что 1С:Предприятие не умеет «мягко» перезапускаться на IIS и перезапуск приводит к аварийному завершению сеанса пользователя с потерей несохраненных данных.
Но это еще половина беды, сама 1С выдает сообщение, что «Сеанс завершен администратором». Такая формулировка уже не раз приводила к конфликтным ситуациями, поскольку пользователи думают, что причина сбоя – некоторые действия или технические работы администраторов.
А теперь вишенка на торте – по умолчанию перезапуск пула приложений настроен с интервалом 1740 минут или 29 часов. Это делает процесс для внешнего наблюдателя рандомным и несистематическим.
Пользователя дня два выбрасывает из 1С в рабочее время, время разное, потом снова все хорошо. В системном журнале данные события отображаются со статусом Сведения и ничем не выделяются на общем фоне.
С учетом того, что пользователи редко фиксируют точное время проблемы диагностика «плавающей» неисправности становится весьма затруднительной. Отсюда начинаются слухи о глючности IIS, судорожные попытки миграции на Apache и прочие телодвижения.
Но на самом деле надо просто настроить перезапуск. Обращаем ваше внимание, что его нужно настроить для каждого пула приложений, если их несколько.
Переходим Пулы приложений – Выбранный пул – Дополнительные параметры
Пролистываем до секции Перезапуск, находим там параметр Моменты точного времени для перезапуска и добавляем туда желаемое время перезапуска пула. Мы выбрали для себя 6 часов утра.
Данный параметр представляет из себя массив, и вы можете добавить несколько моментов времени для перезапуска. Также не забывайте про часовой пояс сервера и часовой пояс клиента.
После чего еще ниже находим опцию Постоянный временной интервал (в минутах), которая и была причиной всех наших безобразий и устанавливаем ей значение в ноль.
Изменив значения не забываем перезапустить пул или веб-сервер полностью (ну или ждем пока он сам в очередной раз перезапустится).
1👍29👀5🔥2❤1🤯1
Что ждет рынок компьютерных комплектующих в 2026 году? Часть 2
В прошлой заметке (https://t.me/interface31/5604) мы рассказали не очень хорошие новости, но ситуация на потребительском рынке продолжает развиваться от плохого к худшему.
Один из крупнейших производителей NAND Samsung подняла в первом квартале 2026 года отпускные цены на твердотельную память более чем на 100%, это, не считая приблизительно 35% повышения цен в 4 квартале 2025 года.
Об аналогичном намерении заявили два других крупнейших игрока этого рынка SK Hynix и SanDisk. Причем речь идет о повышении цен на 100% или близко к тому.
Также происходит перераспределение производственных мощностей в пользу производства RAM, приносящей более высокую прибыль. В 4 квартале прошлого года Samsung сократил выпуск NAND на 5%, а SK Hynix на 10%.
Для понимания экономической подоплеки происходящего можно обратиться к цифрам Samsung, которая показала в последнем квартале прошлого года рост выручки на 22% при практическом удвоении чистой прибыли.
Все это не несет для потребительского рынка ничего хорошего, рост стоимости и уменьшение объемов производства NAND скажется не только на твердотельных накопителях, но и практически на всей электронике, которая сегодня использует NAND как основной тип памяти.
Рост цен неизбежно снизит спрос, что в свою очередь приведет к сокращению производства, увеличению дефицита и новому витку роста цен, теперь уже не только на компьютерном рынке, а на рынке потребительской электроники в целом.
В общем в 2026-27 годах нас ждут трудные времена и многим придется пересмотреть свой подход к приобретению и эксплуатации гаджетов, многие из которых снова начнут кусаться в цене.
Даже если говорить про бум ИИ как некий пузырь, который скоро схлопнется, то это не приведет к массовому падению цен на потребительском рынке. Падать там будет нечему, так как нечего будет продавать.
Снижение цен будет возможно только при повторном насыщении потребительского рынка товарными предложениями, на что может потребоваться продолжительное время, не забываем, что весь объем производства на 2026 уже продан.
Поэтому если вы что-то еще не купили или даже передумали покупать, то самое время еще раз хорошо подумать. Возможно, через некоторое время мы со светлой ностальгией будем вспоминать текущий уровень цен, примерно также, как и «доллар по 30».
В прошлой заметке (https://t.me/interface31/5604) мы рассказали не очень хорошие новости, но ситуация на потребительском рынке продолжает развиваться от плохого к худшему.
Один из крупнейших производителей NAND Samsung подняла в первом квартале 2026 года отпускные цены на твердотельную память более чем на 100%, это, не считая приблизительно 35% повышения цен в 4 квартале 2025 года.
Об аналогичном намерении заявили два других крупнейших игрока этого рынка SK Hynix и SanDisk. Причем речь идет о повышении цен на 100% или близко к тому.
Также происходит перераспределение производственных мощностей в пользу производства RAM, приносящей более высокую прибыль. В 4 квартале прошлого года Samsung сократил выпуск NAND на 5%, а SK Hynix на 10%.
Для понимания экономической подоплеки происходящего можно обратиться к цифрам Samsung, которая показала в последнем квартале прошлого года рост выручки на 22% при практическом удвоении чистой прибыли.
Все это не несет для потребительского рынка ничего хорошего, рост стоимости и уменьшение объемов производства NAND скажется не только на твердотельных накопителях, но и практически на всей электронике, которая сегодня использует NAND как основной тип памяти.
Рост цен неизбежно снизит спрос, что в свою очередь приведет к сокращению производства, увеличению дефицита и новому витку роста цен, теперь уже не только на компьютерном рынке, а на рынке потребительской электроники в целом.
В общем в 2026-27 годах нас ждут трудные времена и многим придется пересмотреть свой подход к приобретению и эксплуатации гаджетов, многие из которых снова начнут кусаться в цене.
Даже если говорить про бум ИИ как некий пузырь, который скоро схлопнется, то это не приведет к массовому падению цен на потребительском рынке. Падать там будет нечему, так как нечего будет продавать.
Снижение цен будет возможно только при повторном насыщении потребительского рынка товарными предложениями, на что может потребоваться продолжительное время, не забываем, что весь объем производства на 2026 уже продан.
Поэтому если вы что-то еще не купили или даже передумали покупать, то самое время еще раз хорошо подумать. Возможно, через некоторое время мы со светлой ностальгией будем вспоминать текущий уровень цен, примерно также, как и «доллар по 30».
😢25🤬7🤡5❤2🥱2
Системы старые, системы устаревшие
В комментариях время от времени поднимается вопрос эксплуатации старых систем и начинают ломаться копья, что мол старое железо вполне еще ого-го и т.д. и т.п.
Поэтому мы решили углубиться в этот вопрос и рассмотреть, какие системы на сегодняшний день хоть и старые, но могут обеспечить комфортную работу, а какие уже безнадежно устарели.
Мы не будем делать упор на обязательную совместимость с Windows 11, но для пользователей данной ОС это тоже немаловажный фактор. Но мы будем исходить из того, что нам нужно обеспечить комфортную работу с современным окружающим миром на базе Windows 10/Linux.
👆 Начнем с аппаратной части. Сегодня для комфортной работы нам нужно, минимум: SATA 600, PCIe 3.0 и USB 3.0, больше – лучше.
👉 По программной части все сложнее, современные системы требуют, как минимум наличия AVX2 и AES-NI. И если последний нужен в основном для криптографии, то AVX2 критически необходим каждому первому.
Данный набор инструкций затрагивает практически все: кодеки, шифрование, сжатие и т.д. и т.п.
Приведем примеры:
▫️SHA-256 - На 40–50% медленнее без AVX2
▫️ Argon2 (хэширование паролей ) - Катастрофически медленно - в 3-5 раз
▫️ Ed25519 (эллиптические кривые ) - Подпись/проверка в 2 раза медленнее
▫️ VP9 – кое как работает до 1080p c крайне высокой нагрузкой на процессор
▫️ AV1 - без AVX2 практически непригоден
▫️ Zstandard - работает через SSE2, но: Скорость сжатия падает на 35-45%,распаковка - на 20-30%
▫️ Brotli- менее зависим от AVX2, но всё равно на 15-25% медленнее
При этом не забываем, что современные сайты во всю используют форматы WebP и AVIF, которые являются производными от VP9/AV1 и будут сильно грузить процессор в современных браузерах.
Тем более что Chrome ≥110 и Firefox ≥115 без поддержки AVX2 просто не запустятся. А если у вас на старой системе стоит более-менее новый браузер, который понимает все эти современные форматы, то расплачиваться будете вы чрезмерной нагрузкой на CPU.
В общем, исходя из сказанного выше минимально комфортной конфигурацией на сегодняшний день является Intel 4-го поколения и AMD Zen Ryzen 1xxx.
Именно там есть поддержка всего нужного в минимальном количестве. Но тут тоже нужно смотреть и думать.
Современные младшие процессоры N100/150 идут вровень с Core i5-45xx, но являются более экономичными, современными и производительными в повседневных задачах.
На наш взгляд, оставаться на платформе 4-7 поколения Intel следует только если она у вас уже есть, и вы можете малой кровью установить туда недорого топ i7 или аналогичный Xeon.
В других случаях надо смотреть или на современные платформы, либо на поколения не ниже восьмого, которое обеспечит совместимость с Windows 11.
Что касается платформы AMD, то там выбрасываем на мусорку все что ниже Zen. Несмотря на то, что последние поколения Excavator поддерживали все нужные функции, удручающая производительность на ядро и ужасающе тепловыделение ставит на них сразу крест.
Из AMD нужно рассматривать Ryzen 1xxx и выше, но первое поколение страдало многими «детскими болезнями» и поэтому фактически следует рассматривать процессоры начиная от Zen+.
Ryzen 1xxx следует рассматривать к покупке только если он существенно более ниже в цене (на 34-40% и более), аналогично следует подходить к Intel поколений от 4-го до 7-го включительно.
В любом случае следует понимать, что технологии не стоят на месте и сегодняшний минимум завтра отправится на свалку истории и к этому надо быть готовым.
В комментариях время от времени поднимается вопрос эксплуатации старых систем и начинают ломаться копья, что мол старое железо вполне еще ого-го и т.д. и т.п.
Поэтому мы решили углубиться в этот вопрос и рассмотреть, какие системы на сегодняшний день хоть и старые, но могут обеспечить комфортную работу, а какие уже безнадежно устарели.
Мы не будем делать упор на обязательную совместимость с Windows 11, но для пользователей данной ОС это тоже немаловажный фактор. Но мы будем исходить из того, что нам нужно обеспечить комфортную работу с современным окружающим миром на базе Windows 10/Linux.
👆 Начнем с аппаратной части. Сегодня для комфортной работы нам нужно, минимум: SATA 600, PCIe 3.0 и USB 3.0, больше – лучше.
👉 По программной части все сложнее, современные системы требуют, как минимум наличия AVX2 и AES-NI. И если последний нужен в основном для криптографии, то AVX2 критически необходим каждому первому.
Данный набор инструкций затрагивает практически все: кодеки, шифрование, сжатие и т.д. и т.п.
Приведем примеры:
▫️SHA-256 - На 40–50% медленнее без AVX2
▫️ Argon2 (хэширование паролей ) - Катастрофически медленно - в 3-5 раз
▫️ Ed25519 (эллиптические кривые ) - Подпись/проверка в 2 раза медленнее
▫️ VP9 – кое как работает до 1080p c крайне высокой нагрузкой на процессор
▫️ AV1 - без AVX2 практически непригоден
▫️ Zstandard - работает через SSE2, но: Скорость сжатия падает на 35-45%,распаковка - на 20-30%
▫️ Brotli- менее зависим от AVX2, но всё равно на 15-25% медленнее
При этом не забываем, что современные сайты во всю используют форматы WebP и AVIF, которые являются производными от VP9/AV1 и будут сильно грузить процессор в современных браузерах.
Тем более что Chrome ≥110 и Firefox ≥115 без поддержки AVX2 просто не запустятся. А если у вас на старой системе стоит более-менее новый браузер, который понимает все эти современные форматы, то расплачиваться будете вы чрезмерной нагрузкой на CPU.
В общем, исходя из сказанного выше минимально комфортной конфигурацией на сегодняшний день является Intel 4-го поколения и AMD Zen Ryzen 1xxx.
Именно там есть поддержка всего нужного в минимальном количестве. Но тут тоже нужно смотреть и думать.
Современные младшие процессоры N100/150 идут вровень с Core i5-45xx, но являются более экономичными, современными и производительными в повседневных задачах.
На наш взгляд, оставаться на платформе 4-7 поколения Intel следует только если она у вас уже есть, и вы можете малой кровью установить туда недорого топ i7 или аналогичный Xeon.
В других случаях надо смотреть или на современные платформы, либо на поколения не ниже восьмого, которое обеспечит совместимость с Windows 11.
Что касается платформы AMD, то там выбрасываем на мусорку все что ниже Zen. Несмотря на то, что последние поколения Excavator поддерживали все нужные функции, удручающая производительность на ядро и ужасающе тепловыделение ставит на них сразу крест.
Из AMD нужно рассматривать Ryzen 1xxx и выше, но первое поколение страдало многими «детскими болезнями» и поэтому фактически следует рассматривать процессоры начиная от Zen+.
Ryzen 1xxx следует рассматривать к покупке только если он существенно более ниже в цене (на 34-40% и более), аналогично следует подходить к Intel поколений от 4-го до 7-го включительно.
В любом случае следует понимать, что технологии не стоят на месте и сегодняшний минимум завтра отправится на свалку истории и к этому надо быть готовым.
1👍29🔥15🤔9❤7🤝2
Насколько нужен AVX2, практика
Небольшое исследование на предмет нужности и полезности инструкций AVX2. Чтобы оценить их влияние мы взяли одну из наших виртуалок, выключили в ней инструкции AVX и реализовали наиболее распространенный сценарий – просмотр видео на YouTube в качестве 1080HD.
Инструкции AVX отключены, загрузка выделенных виртуалке 4 ядер Ryzen 9 5900X составляет 30-40%.
Инструкции AVX включены, тот же самый ролик в том же самом качестве, нагрузка на процессор в районе 10%.
Результат очевиден, на декодировании видео AVX2 дает выигрыш в 3,5 раза! И это сам по себе мощный современный процессор, а что будет с тем же Intel 3-го поколения даже думать не хочется.
При этом напомним, что AVX2 – это не только видео, но и криптография, с которой вы сталкиваетесь на каждом шагу в интернет, сжатие – т.е. полный набор повседневных задач.
Нет, без AVX2 жить конечно можно, но только такую жизнь сложно назвать комфортной, потому что даже элементарные действия будут вызывать серьезную нагрузку на процессор.
Небольшое исследование на предмет нужности и полезности инструкций AVX2. Чтобы оценить их влияние мы взяли одну из наших виртуалок, выключили в ней инструкции AVX и реализовали наиболее распространенный сценарий – просмотр видео на YouTube в качестве 1080HD.
Инструкции AVX отключены, загрузка выделенных виртуалке 4 ядер Ryzen 9 5900X составляет 30-40%.
Инструкции AVX включены, тот же самый ролик в том же самом качестве, нагрузка на процессор в районе 10%.
Результат очевиден, на декодировании видео AVX2 дает выигрыш в 3,5 раза! И это сам по себе мощный современный процессор, а что будет с тем же Intel 3-го поколения даже думать не хочется.
При этом напомним, что AVX2 – это не только видео, но и криптография, с которой вы сталкиваетесь на каждом шагу в интернет, сжатие – т.е. полный набор повседневных задач.
Нет, без AVX2 жить конечно можно, но только такую жизнь сложно назвать комфортной, потому что даже элементарные действия будут вызывать серьезную нагрузку на процессор.
👍36🥱4🤣2🤝1