Как оптимизировать линукс под использование харда?

А свап отключен?

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

А питание то диска в порядке? У мну такое было, я неделю в системе логи смотрел, отлавливал проблемы в оперативке, а как питание диску поменял, да провод sata поменял, все сразу стало супер, хотя никакие программы типа victoria или mhdd не могли сказать в чем трабл, думал уже диск на помойку нести. Все так же было, все медленно и тд.

Данный баг наблюдается на разных компах, одному месяц от роду.

Только при доступе к ntfs или и на чисто линуксовых ФС?

ionice -c 3 cp ....

пробовал?

На моём только ext4, на тех - и ext4 и ntfs. Это драйвера sata, или что-то. ФС, ДЕ, шлейфы и прочее тут не при чём.

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

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

Ну и ещё раз порекомендую tmp в tmpfs и zram, а дисковый своп вырубить (не командой swapoff -a, а конкретный раздел на hdd). Вообще своп вырубать вроде как плохая практика, но на проблемных машинах либо так, либо лагодром.

Кстати можно ещё написать скриптец который будет денайсить ксорги и прочие квины, тоже должно помочь немного.

Не помогло. Точно так же тупит

Когда Dirty заполняется - случается тупняк. Там где-то или блокировка в ядре, или ещё что-то. Собственно говоря, нужно или уменьшать размеры dirty или увеличивать и иметь кучу свободной оперативы. Или быстрые устройства. Т.е. если бы с кэша на носитель успевало скидываться - тупняка бы небыло. А оно не успевает. Поэтому уменьшение dirty до небольших величин исправляет ситуацию: лок на долго не возникает. Выстави байтами размеры в десятки мегабайт. Или вообще в 8М поставь размер и посмотри, что будет.

Так. Exmor_RS прав. Это делает свап. и получается, что выпихиваются иксы, чтоли? Отключил свап и копировал туда-сюда. Никаких даже намёков на зависон. Посмотрел, swapiness стоит 60. Офигеть. Открыл /etc/sysctl.d, а там ещё и fs.inotify.max_user_watches = 16384

Закоментировал fs.inotify.max_user_watches, поставил swapiness = 10. Перезагрузил комп, со всеми прогами, блендер, фокс, годот, опера, посмотрел топом - в свапе занято 0. Значит уже лучше. Стал копировать, опять 2.4 гига файл. Откопировало 2/3 и затупило и ровно в этот момент стал заполнятся свап. Вот такие пироги.

Я раньше такого не замечал.

Ну правильно - системе не хватает памяти под кэш, а кэш разрешён. Значит неиспользуемые страницы выгружаются в своп. Своп - значит тормоза. vfs.cache_pressure увеличь.

Это баг в новых ядрах, который никто не чинит

https://bugzilla.kernel.org/show_bug.cgi?id=196729

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

+100500, а в свете вот этих проблем со свопом это очень сильно назрело.

Вот блин! Пишу этот пост, запустив в фоне обновление. И на полуслове все повисает. Надо своп отрубать пока.

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

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

Откопировало 2/3 и затупило и ровно в этот момент стал заполнятся свап

Почему не используешь zram? Это сильно уменьшает тормоза при свопинге.

Пока пытаюсь понять логику происходящего. Даже при swapiness = 1 происходит ровно то же самое. Если памяти ещё достаточно, зачем в свап лезть? И если свапит, то что?

Обмазаться ещё одним костылём успею. Если традиционный линукс уже не может без этого. К zram у меня осторожное отношение. Когда он появился - добавлял много проблем.

Вот смотрю, у меня установлен пакет mkinitcpio-openswap. его конфиг лежит в /etc/openswap.conf Мне оно не нравится.

## cryptsetup open $swap_device $crypt_swap_name
## get uuid using e.g. lsblk -f
swap_device=/dev/disk/by-uuid/2788eb78-074d-4424-9f1d-ebffc9c37262
crypt_swap_name=cryptswap

## one can optionally provide a keyfile device and path on this device
## to the keyfile
keyfile_device=/dev/mapper/cryptroot
keyfile_filename=etc/keyfile-cryptswap

## additional arguments are given to mount for keyfile_device
## has to start with --options (if so desired)
#keyfile_device_mount_options="--options=subvol=__active/__"

## additional arguments are given to cryptsetup
## --allow-discards options is desired in case swap is on SSD partition
cryptsetup_options="--type luks"

Значит, если бы я удалил монтирование свапа из fstab, он бы его примонтировал? И шифрование ему повесил? Этот криптсвап действительно нужен? Можно я всё это удалю и оставлю «нормальное» монтирование через свап?

Если есть ядро 4.20+, то можешь воспользоваться монитором PSI для диагностики:

https://github.com/hakavlad/nohang/blob/master/tools/psi-monitor

Это позволит оценить конкуренцию за память и IO.

Пример вывода:

$ psi-monitor
Set target to SYSTEM_WIDE to monitor /proc/pressure
Starting psi-monitor, target: SYSTEM_WIDE, period: 2
------------------------------------------------------------------------------------------------------------------
 some cpu pressure   || some memory pressure | full memory pressure ||  some io pressure    |  full io pressure
---------------------||----------------------|----------------------||----------------------|---------------------
 avg10  avg60 avg300 ||  avg10  avg60 avg300 |  avg10  avg60 avg300 ||  avg10  avg60 avg300 |  avg10  avg60 avg300
------ ------ ------ || ------ ------ ------ | ------ ------ ------ || ------ ------ ------ | ------ ------ ------
  0.17   0.83   0.57 ||  11.54  49.25  32.03 |  11.27  45.70  29.59 ||  42.80  78.67  42.78 |  42.09  74.13  39.81
  0.14   0.80   0.57 ||   9.63  47.67  31.81 |   9.41  44.24  29.39 ||  40.12  77.01  42.68 |  39.54  72.62  39.73
  0.11   0.77   0.56 ||   7.88  46.11  31.60 |   7.70  42.79  29.19 ||  32.85  74.49  42.39 |  32.38  70.25  39.46
  0.09   0.75   0.56 ||   6.45  44.60  31.38 |   6.31  41.39  28.99 ||  27.08  72.09  42.11 |  26.69  67.98  39.19
  0.07   0.72   0.55 ||   5.28  43.14  31.16 |   5.16  40.04  28.79 ||  22.90  69.86  41.85 |  22.58  65.89  38.95
  0.06   0.70   0.55 ||   4.33  41.73  30.95 |   4.23  38.73  28.60 ||  18.75  67.57  41.56 |  18.49  63.73  38.69
  0.05   0.67   0.55 ||   7.35  41.05  30.88 |   7.26  38.15  28.54 ||  20.24  66.25  41.46 |  20.03  62.53  38.61
  0.04   0.65   0.54 ||   6.38  39.77  30.68 |   6.31  36.96  28.36 ||  17.48  64.24  41.21 |  17.31  60.65  38.38
  0.03   0.63   0.54 ||   5.22  38.47  30.47 |   5.17  35.75  28.17 ||  14.67  62.21  40.94 |  14.53  58.73  38.13
  0.02   0.61   0.54 ||   4.27  37.21  30.27 |   4.23  34.58  27.97 ||  12.02  60.17  40.66 |  11.90  56.81  37.87
  0.02   0.59   0.53 ||   3.50  36.00  30.06 |   3.46  33.45  27.78 ||  10.20  58.27  40.40 |  10.10  55.01  37.62
  0.01   0.57   0.53 ||   2.86  34.82  29.85 |   2.83  32.36  27.59 ||   8.35  56.36  40.12 |   8.27  53.21  37.36
^CExit
$ psi-monitor /user.slice
Set target to /user.slice
Starting psi-monitor, target: /user.slice, period: 2
------------------------------------------------------------------------------------------------------------------
 some cpu pressure   || some memory pressure | full memory pressure ||  some io pressure    |  full io pressure
---------------------||----------------------|----------------------||----------------------|---------------------
 avg10  avg60 avg300 ||  avg10  avg60 avg300 |  avg10  avg60 avg300 ||  avg10  avg60 avg300 |  avg10  avg60 avg300
------ ------ ------ || ------ ------ ------ | ------ ------ ------ || ------ ------ ------ | ------ ------ ------
  0.00   0.00   0.00 ||   7.20  12.43  18.37 |   6.82  11.85  17.21 ||  31.15  40.69  36.31 |  30.08  39.47  34.62
  0.00   0.00   0.00 ||   5.90  12.03  18.24 |   5.59  11.46  17.09 ||  25.50  39.35  36.06 |  24.63  38.18  34.39
  0.00   0.00   0.00 ||   4.83  11.63  18.12 |   4.57  11.09  16.97 ||  20.88  38.07  35.81 |  20.17  36.93  34.15
  0.00   0.00   0.00 ||   3.95  11.25  17.99 |   3.74  10.72  16.86 ||  17.10  36.82  35.57 |  16.52  35.72  33.92
  0.00   0.00   0.00 ||   3.24  10.88  17.87 |   3.06  10.37  16.74 ||  14.00  35.62  35.33 |  13.52  34.55  33.68
  0.00   0.00   0.00 ||   2.65  10.53  17.75 |   2.51  10.03  16.63 ||  11.46  34.45  35.08 |  11.07  33.42  33.45
^CExit

О PSI: https://facebookmicrosites.github.io/psi/

Если памяти ещё достаточно, зачем в свап лезть?

С чего взял, что памяти достаточно? MemFree или MemAvailable смотришь?

Я думаю этот конфиг нужен просто чтобы шифровать своп когда он есть, а не самовольно его включать.

Когда он появился - добавлял много проблем.

Кому и каких проблем? При каких настройках, при каких условиях? У меня zram приводит лишь к ускорению выполнения задач в разы в сравнении с обычным свопом.

И шифрование ему повесил? Этот криптсвап действительно нужен?

Откуда у тебя это вообще?

Можно я всё это удалю и оставлю «нормальное» монтирование через свап?

Рискни.

При каких настройках, при каких условиях?

Дааавно это было. Машинка, вроде, 512МБ была, но это уже было мало. И назывался zram по другому. Проблема примерно такая, что от маленького куска памяти откусывается часть, свопить начинает чаще и в итоге начинает гонять туда-сюда. И в результате у тебя и память забита и зрам и свап на харде всё равно используется. Игрушка то была. Как tmp и в tmpfs держать. Можно, ежели памяти два вагона.

watermark_scale_factor подкрути. swapiness уже давно является рекомендательным параметром, но не обязательным к исполнению.

и свап на харде всё равно используется

Так настраивать надо правильно. Своп на харде выключаем. Zram disksize можно до 2MemTotal догнать.

https://youtu.be/PLVWgNrVNlc - вот пример. 2 гига памяти и 2 гига свопа на зрам почти забито, вкладки крутятся, зависания нет, жить можно.

https://github.com/hakavlad/yazram - мой скрипт для настройки zram с хорошими дефолтами, можешь попробовать.

watermark_scale_factor = 10 - это достаточно мало, или недостаточно? Вообще, задача не просто отодвинуть сброс в свап, а сделать его работу незаметной. И тут вопрос, как выше мужики писали, что отправлять в свап, когда он нужен?

Спасибо. Я пока не рассматриваю zram. Это не решение проблемы.

Программы стали распускать слишком много процессов. Файрфокс наплодил десять детей, даже Клементина четырёх, и т.д. и т.п. И все их надо сбрасывать? Или кого? Или как?

Там всё плохо сейчас с подсистемой памяти и эти косяки разгребать начали не так давно. Единственное решение - переносить своп на быстрое устройство. Незаметным ты процесс не сделаешь при всём желании - система начинает фризиться не из-за того, что свопится, а из-за того, что вся память подошла к концу. Вообще своп как бы не заметная штука, если сильно не наглеть и резко не занимать память. У меня вообще ядрышко самосборное в генте и проблем я подобных не испытываю уже давным давно. Я и 12309 не видел ни разу за 10 лет у себя.

У тебя проблема на мой взгляд не в том, что из-за свопинга система тормозить начинает. Как бы выяснить, насколько незаметен своп для ОС ты можешь тупо запустив виртуалку и заняв память ей. Зависнет - бага что выше писали, не зависнет - колдуй дальше с dirty.

не рассматриваю zram. Это не решение проблемы.

Напротив, это и есть решение проблемы:

Как оптимизировать линукс под использование харда?

Со zram значительно падает нагрузка на IO при свопинге, свопинг становится более плавным и быстрым.

Файрфокс наплодил десять детей

Можно ограничить в его настройках, число воркеров сократить до одного. Это таки сэкономит память.

Мне кажется, ты где-то путаешь zram и zswap. zram лишь отодвигает необходимость свопа, но когда система лезет в своп - IO от zram меньше не становятся. А вот zswap - другая песня. Правда, я zram пробовал только пару раз и оба раза мне оно не понравилось.

zram лишь отодвигает необходимость свопа

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

Это одна тысячная от оперативки. То-есть, к примеру, для 2ГБ RAM – 2МБ. Я бы ставил больше, потому как раньше оно выставлялось как 1/4 от min_free_kbytes, а min_free_kbytes легко мог быть 64МБ. Значение в 200, которое предлагают в комментах к баге, мне кажется адекватным для систем с небольшим количеством памяти. Может даже и больше можно.

Ну и про выставление dirty_background_bytes и vm.dirty_bytes значений поменьше не забудь. А то система станет колом от того, что оперативка кончилась под буфер записи. Для медленных HDD даже 1 и 2 метра, соответственно, вполне могут быть большИми значениями.

Эээ. Стоп. zram - сжатое устройство в ОЗУ. Т.е. ещё один своп с большим приоритетом. Когда он кончается - система лезет опять же на своп с маленьким приоритетом на диске. Как бы отодвигает использование дискового свопа. IO он может снижать за счёт того, что из него быстренько всё распаковывается и запаковывается обратно, но если его перестанет хватать - один черт система будет так же тупить при обращении в обычный своп с тем же количеством IO. Тут просто zram некий трюк, который снижает количество обращений к свопу за счёт костыля, увеличивающего общий объем RAM, которую может занять система перед тем как полезет на диск.

ZSWAP - другая штука. Она сжимает страницы перед помещением их в SWAP и только. За счёт чего снижает кол-во IO, делая своп на диске более быстрым. Использовать эти две вещи вместе и одновременно не следует, естественно, но назначение у них разное, хотя и приводят они к схожим результатам.

Кстати, в будущих фоксах грозились убрать эту настройку.

Что происходит, когда место в zram заканчивается? Именно. А я за то, чтобы обращение к свапу осталось, но не вешало систему. До корня проблемы надо добраться.

Что происходит, когда место в дисковом свопе заканчивается? Именно.

zram - своп в оперативке. Ему выставляется приоритет повыше, чем у дискового свопа. Когда своп в оперативке закончился - система лезет в своп на диске.

Не полезет, если выключить своп на диске.

А я за то, чтобы обращение к свапу осталось, но не вешало систему.

Со зрам так и будет: своп будет на зрам устойстве, и он будет быстрым. И вешать систему не будет. https://youtu.be/PLVWgNrVNlc - вот пример.

Полезет, ведь кроме свапа есть ещё file-backed pages.

Гхм. Я вот такое вот не люблю. У меня своп на диске всегда равен размеру ОЗУ. Правда, своп на SSD. И не редко возникала ситуация, когда в свопе 15 гигабайт, и в оперативке 15 гигабайт, а система при этом работает. Временами, правда, замирая, но не падая. Но у меня юзкейсы такие, коорые оперативку жрут.

Я вот такое вот не люблю

Почему? Это ж помогает ускорять операции.

Кстати, у зрам хорошая растяжимость: https://imgur.com/a/ZBk0zDp

• засвопилось больше, чем размер мемтотал.

система начинает фризиться не из-за того, что свопится, а из-за того, что вся память подошла к концу

Не начнет при использовании юзерспейсных обработчиков нехватки памяти, https://youtu.be/PLVWgNrVNlc - вот пример.

Так. zram не хочу, не верю. А zswap показался интересным. Для универсальности решил установить systemd-swap, так через конфиг я смогу легко запустить одно, другое и сравнить.

zswap сработал. Никаких фризов. Даже окно взял и тягал из стороны в сторону. При копировании видно как свап наполняется, но фриза не происходит. Костыль, но без посредника в виде отожранного куска памяти под ещё один свап.

Но хотелось бы, конечно, чтобы свап сам умел так мягенько.

то, что он у тебя там убивает процессы - это не решение, это костыль. А должно работать правильно, тогда и убивать не придётся.

без посредника в виде отожранного куска памяти под ещё один свап Zswap это как раз и есть отожранный кусок памяти-посредник.

DragonFlyBSD has virtually no bottlenecks or lock contention in-kernel.

цитата с сайта https://www.dragonflybsd.org/

Лучшая из Windows не перестает совершенствоваться
Разработанная для обеспечения легкого постоянного обновления Windows 10 предоставляет новые возможности и обновленный уровень безопасности без дополнительной оплаты.*

цитата с сайта https://www.microsoft.com/ru-ru/windows/

http://rsdn.org/forum/flame.comp/7580682.all

Всё это, конечно, полумеры. Как только начинает сбрасывать на хард - жёсткие фризы. И это на восьми гигах. как же быть людям с 4 гигами памяти и современным вебом? Охренейшн.

Современный линукс повернулся к ssd лицом, к hdd задом. То что раньше называлось 12309 разраслось кустистыми ветвями. И раньше-то способов побороть небыло, у одних помогало, у других ухудшало. А теперь вообще непонятно, что делать?

Какие-то странные слова. Памяти побольше, чтобы свопилось поменьше, и всё. А 12309 вообще миф я считаю - никогда не видел. Хотя нет, наверное видел при записи разово большого объёма на флешку. Но так, слегка.