Линуксы зависли, реакции нет

Хотя свободно ещё целых 40% оперативной памяти, сотни мегабайт.

Похоже на сосяк cgrops. Предлагаю отключить cgrops для памяти вообще параметром ядра при загрузке и попробовать без него.

А ещё виртуалки могут свопиться внутри себя обращаясь к диску напрямую.

С этим же параметром, своппинг начинается только тогда, когда занято 90% памяти, а свободно менее 10%.

Параметром vm.swappiness=10? Нет, это не так работает уже давно.

Вся эта тема про oomd

Ноуп как раз НЕ про него.
А про другую фичу ОС которая даёт возможность запретить вытеснять либы из ОЗУ.

Прелоклд посмотри.

Про это я знаю, это другой вариант сниженной отзывчивости.
В некоторых окружениях помогает улучшить ситуацию даже перемещение файла ошибок ксорга в tmpfs или просто отрубить его.
найсы/ренайсы/ионайсы в итоге не спасают от вытеснения.

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

Твоё «повышение отзывчивости на порядок» лишь показывает насколько система и её дефолты отстают от потребностей пользователей и что таким важным компонентом никто не занимается (да и ты сам о данной проблематике стал думать видимо только в этом треде, хоть и в отрицающей пока форме).

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

2 hakavlad

>> У меня - крайне медленный WD Blue из 2009 года

> Тем более свопинес надо повышать, если своп на zram.

У меня - операционная система 2009 года. SLES 11 - SUSE с долговременной поддержкой. На старте там было ядро 2.6.27, которое потом обновляли до 2.6.32 и 3.0. Я потом вручную установил 3.16 из openSUSE 13.2.

Не уверен, что здесь есть zram.

2 kirill_rrr

> Похоже на сосяк cgrops

Я не уверен, что у меня есть cgroups. Вот вывод команды mount:

/dev/sda2 on / type ext3 (rw,data=journal,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,mode=1777)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sda4 on /windows type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
gvfs-fuse-daemon on /home/boss/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=boss)
/dev/sr1 on /media/H3_blade type iso9660 (ro,nosuid,nodev,uid=1000)
/dev/sdb1 on /media/disk type exfat (rw,nosuid,nodev,uid=1000,gid=100,dmask=0022,fmask=0022,namecase=0)

>> С этим же параметром, своппинг начинается только тогда, когда занято 90% памяти, а свободно менее 10%.

> Параметром vm.swappiness=10? Нет, это не так работает уже давно.

Может, в новой системе это уже не так работает, а в моей - результат получен. Раньше я не мог создать виртуалку размером 1 Гб, если у меня 2 Гб ОЗУ минус 128 Мб на видеопамять. И не мог создать виртуалку на 2 Гб, если у меня 4 Гб минус 128 Мб. Зато после применения swappiness, и виртуалка работает, и на оставшихся двух гигабайтах можно запустить браузер, офис, IM, музыку...

Знаешь какой трындец был, когда я поставил вторую планку на 2 Гб, и когда я полностью 2 гига занял, система уходила в лютый своп и не реагировала ни на что? Блин, да у тебя вчера ещё 2 Гб ВСЕГО было, и тебе хватало, а теперь у тебя 2 гига СВОБОДНО, и тебе не хватает!

Притом что DE и жрёт копейки.

> если своп на zram

Своп же используется, когда оперативка кончилась. Зачем хранить своп в оперативке?

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

найсы/ренайсы/ионайсы в итоге не спасают от вытеснения.

Конечно не спасают. Речь о том, чтобы сделать вытеснение в более оптимальном порядке.

сам о данной проблематике стал думать видимо только в этом треде

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

Своп же используется, когда оперативка кончилась.

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

Традиционно на эту тему советуют статью Криса Дауна https://chrisdown.name/2018/01/02/in-defence-of-swap.html, перевод: https://habr.com/ru/company/flant/blog/348324/

Зачем хранить своп в оперативке?

В оперативе можно располагать блочное устройство, которое в среднем в три раза сжимает страницы. Это отлично работавет со свопом. В отличие от HDD устройство zram быстрое и многопоточное. Некоторые дистрибутивы перешли на использование только свопа на zram, например Fedora https://fedoraproject.org/wiki/Changes/SwapOnZRAM.

Документация: https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html

Речь о том, чтобы сделать вытеснение в более оптимальном порядке.

Речь о том чтобы вообще не вытеснять некоторые компоненты, никогда, чтобы в ОЗУ всегда были все компоненты необходимые для обеспечения нормального обслуживания системы в целом (включая банальное взаимодействие с пользователем).

Вот почему у меня 2000-я винда использует немного свопа. даже когда свободной памяти ещё много. Спасибо за ликбез

> В оперативе можно располагать блочное устройство, которое в среднем в три раза сжимает страницы

Запихиваем туда текстовых файлов с коэффициентом сжатия 96%, и забиваем всю оперативку так, чтобы ничего не осталось. Упихиваем туда в три раза больше текстовых файлов, чем есть оперативки на компе. Допустим, на компе 2 Гб, а в оперативке 6 Гб.

Ага, а теперь начинаем медленно заменять текстовые файлы на сжатое видео с коэффициентом сжатия 0%. Все 6 гигабайт побайтово.

Что будет?

В крайнем случае будет ООМ - даже при SwapFree > 0.

Однако в большинстве случаев сжатие таки 2:1-3:1. Браузеры хорошо жмутся, компиляции неплохо сжимаются. При работе в блендере растягивал память со степенью сжатия 1.4:1. Меньшие значения достигаются синтетикой - наполнением памяти данными из /dev/urandom.

Альтернатива - zswap. Несжимаемые данные при этом будут падать на дисовый своп, а сжимаемые - сжиматься в оперативе.

когда они уже осилят и на диск писать сжатые?

например

https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression

https://fedoramagazine.org/fedora-workstation-34-feature-focus-btrfs-transparent-compression/

не-не девид блейн, так оно будет сначала разжимаься, а потом сжиматься заново

Ты хочешь чтобы кроме фризов от медленного диска оно сверху ежё сжатие разжатие делало? Пожалуй ещё в PAQ8, чтобы наверняка.

С PAQ не утрируй. Но с современными процессорами, если помещать на hdd диск данные, сжатые lz4 или lzo, будет выигрыш.

Ну вот, опять. А кто эти обязательные компоненты помечать будет? И что обязательно? Скрипты в браузере? Или хранить в дисковом кеше вообще весь код, считанный с диска за пару недель аптайма на всякий случай? А что вытеснять вместо них?

Вот поэтому zram не панецея и ставить его больше 30% оперативки особого смысла нет. И ещё есть zswap который может дать примерно те же преимущества, но без головняков. А zram хорош для блочных устройств в оперативке.

Но тем не менее, он реально работает и временами очень конкретно впихивает невпихуемое.

А кто эти обязательные компоненты помечать будет?

Менеджер памяти ядра через механизм LRU

Или хранить в дисковом кеше вообще весь код, считанный с диска за пару недель аптайма

С помощью LRU выбирать наиболее горячий кэш, а наименее используемый можно отбрасывать.

ставить его больше 30% оперативки особого смысла нет

Есть. Ставить zram disksize=2MemTotal это ОК. Позволять сжатым страницам заполнять 80% памяти это ОК.

Тогда очень велик шанс, что ни одной софтине не достанется больше 10-15% памяти.

Но менеджер памяти ядра не знает какие компоненты критические для пользователя.

Это уже работает автоматически (в патче/сервисе).
А кто ведёт wine-database и прочие *-database?
(+ты сам лично можешь прописать, что сохранять в памяти)

Разработчики, мейнтейнеры (благо они любят выполнять тройную работу).
Это вполне выполнимая задача (не так уж много этих компонентов: ssh, dm, de, xorg/wayland).

Вытеснять всё то от чего система не встанет как корова на льду.

ни одной софтине не достанется больше 10-15% памяти

Активная память составляет малую часть общей. Большая часть - неактивная. Рабочий набор обычно не очень большой.

>> Зачем хранить своп в оперативке?

> В оперативе можно располагать блочное устройство, которое в среднем в три раза сжимает страницы. Это отлично работавет со свопом. В отличие от HDD устройство zram быстрое и многопоточное

Разве нельзя сжимать данные в памяти сразу, вместо того, чтобы отправлять их на HDD в своп, но вместо этого обратно в оперативку, но сжимая?

Разве нельзя сжимать данные в памяти сразу

Нельзя. Если можно - отправляй свои патчи в LKML.

Может хоть во Фряхе это сделано?

Обычно, но не тогда, когда возникла нехватка памяти. А всякий своп-треш как раз и начинается при нехватке этого самого рабочего набора. Нехватка дисковых кешей как раз неплохо глотается современными ссд.

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

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

некие дефолтные списки невытеснения в релиз

https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS

А всякий своп-треш как раз и начинается при нехватке этого самого рабочего набора

Так речь как раз и идет о защите рабочего набора с помошью патча: https://lore.kernel.org/patchwork/patch/222042/

Таким образом, уже сейчас существуют механихзмы защиты

• файлового кэша
• анонимной памяти избранных процессов

Лучше используйте патч https://github.com/hakavlad/le9-patch

Тему нужно повторять регулярно, до полного решения проблемы.

Типичные дистрибутивы linux не подходят для десктопа

Всё верно: https://itvision.altervista.org/why.linux.is.not.ready.for.the.desktop.current.html