Встает колом

ИМХО, это проблемы не дебиан, а ядра. И вам теперь можно долго подбирать значения типа vm.watermark_scale_factor, vm.swappiness=80, vm.page-cluster=0 и т.д., чтобы в вашем конкретном случае стало получше.

Вы знаете, как раз обсуждали — попробуйте другой планировщик ввода-вывода. Из простого, у вас есть место на диске?

Встает колом

Binkledum.

Кто знает, как решить?

AntiX, EXE GNU/Linux.

devuan ascii + lxde

Все ядра с 4 версии дёргают диск, но Линусу на это глубоко, так как в Шляпе крутят на шляпе твои бытовые HDD и SSD. Могу лишь посоветовать выставить commit побольше.

Владимир

попробуйте другой планировщик ввода-вывода

Спасибо, буду изучать вопрос. Нужны ли в данной ситуации какие-нибудь конкретные руководства по установке/настройке?

у вас есть место на диске

Почти 5 Гб свободно на root. Под swap выделен раздел в 2,93 Гб при ОЗУ в 2 Гб.

AntiX, EXE GNU/Linux

Как это поможет? Они оба основаны на Debian.

Это и есть изначально devuan ascii. Я просто указал дебиановские репы, чтобы не ждать выхода devuan - systemd все равно не будет устанавливаться. Вместо lxde использую еще более легкое сочетание openbox + tint2.

Могу лишь посоветовать выставить commit

Спасибо.

И вам теперь можно долго подбирать значения типа vm.watermark_scale_factor, vm.swappiness=80, vm.page-cluster=0 и т.д., чтобы в вашем конкретном случае стало получше.

Спасибо.

vm.swappiness=80

Ерунда какая, так он из подкачки не будет вылазить вообще

vm.swappiness=1 vm.vfs_cache_pressure=50 vm.dirty_writeback_centisecs=15000

В fstab попробуйте добавить:

noatime,nodiratime,nobarrier,commit=900

Владимир

Поставьте ядро rt-kernel и примените к нему патч UKSM, а также включите preamp и 1000hz тикрейт таймера. После чего отключите huge pages.

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

The attached kernel patch (applied on top of 4.18.5) that I’ve tried, almost completely eliminates the disk thrashing(the constant reading of executable(and .so) files on every context switch) associated with freezing the OS and so, with this patch, the OOM-killer is triggered within a maxium of 1 second when it is needed, rather than, without this patch, freeze the OS for minutes(or just a long time, it may even auto reboot depending on your kernel .config options set to panic(reboot) on hang after xx seconds) with constant disk reading well before OOM-killer gets triggered.

https://github.com/hakavlad/le9-patch

Индикатор работы жесткого бесконечно горит (память в кэш уходит?)

Кэш разделяемых библиотек выбрасывается из памяти. Для каждой операции необходимо повторное считывание либ с диска -> тормоза.

См Просто оставлю это здесь: Игра в supertux2 с множественными `tail /dev/zero` в фоне без зависаний

Без без патчинга ядра можно попробовать prelockd и memavaild.

Индикатор работы жесткого бесконечно горит (память в кэш уходит?), все тормозит

см https://www.opennet.ru/opennews/art.shtml?num=51231

Решение описано выше - закрепление кода в памяти с помощью демона, либо патчинг ядпа для резервирования Active(file)

Своп конечно лучше на zram.

Не слушай советующих низкий swappiness.

Попробуй удалить Debian, они там намудрили. Кроме консоли ещё зачем-то графику подвезли. Так на любом компе тормозить будет. Все графоделы без исключения думают, что у всех компы как у них.

Ерунда какая, так он из подкачки не будет вылазить вообще

С чего вдруг? vm.swappiness — это предпочтение анонимной памяти к дисковому кешу. В дисковом кеше сидят библиотеки, если ядро будет всё время его освобождать, то программы работать вобще не смогут.

Ерунда какая, так он из подкачки не будет вылазить вообще

Ничего подобного

vm.swappiness=1

Это как раз услиливает тормоза при своппинге

Если памяти в обрез, то тормозить будет так и так. Вопрос в кол-ве открытых приложений которые можно с комфортом использовать. До критической точки. Желательно при этом использовать что-то на Java, чтобы тормоза при нехватке памяти ощущались как нельзя лучше.

Единственный нормальный выход при этом – вообще отключить своп и ловить оверкоммиты. Тогда границы дозволенного обозначат себя сами.

Ага, и при 1 гектаре оперативы подкачка будет начинаться как минимум с 200мб, то есть всегда. Предлагаю вариант, поставить Debian 8-32бит с openbox или подобным, links2 в качестве браузера, но конечно сейчас найдуться федорасты с доводами про обновления и «безопасность», канешна.

Владимир

У тебя встает на Binkledum? :3

при 1 гектаре оперативы подкачка будет начинаться как минимум с 200мб, то есть всегда

А со скольки будет начинаться подкачка при swappiness=200?

Вы несете феерическую ахинею. Свопинес не показывает уровень, с которого начинается своппинг.

При свопинес=100 подкачка может начинаться при почти полном исчерпании доступной памяти.

другой - с 2 Гб

См пример настройки Десктоп бати-пенсионера: Linux Mint 18.3 Mate

Ничего подбирать смысла нет. Нужно включать свап и выставлять vm.swappiness=100, если это не помогает - идти покупать кучу озу.

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

Херню пишешь. Во-первых, фризы при исчерпании памяти вообще не имеют никакого отношения к высокой нагрузке на процессор.

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

И rt-ядро не для десктопа вообще.

Почитайте про BFQ.

Тогда нужно играться с параметрами подкачки.

bfq давным-давно в апстримном ядре, ёпт

Ну так CFQ же стоит по умолчанию.

нет, cfq убрали из ядра когда добавляли bfq. остались только bfq, deadline, kyber

О, кажется Вы не подписаны на рассылку linux!

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

vm.overcommit_memory = 2 или юзерспейсный oom-killer. Уменьшай vm.dirty_bytes и dirty_background_bytes. Юзай zram. Пробуй другой планировщик ввода-вывода. Поставь юолее легковесное графическое окружение.

vm.overcommit_memory = 2

Напротив, лучше vm.overcommit_memory = 1 + юзерспейсный киллер.

Думаю, лучшим решением будет увеличить размер оперативной памяти.

Чем дальше, тем сложнее использовать подобное железо в роли десктопа. Странно вообще жаловаться.

что-то намутили с OOM Killer

ничего не понял.
с чем проблемы?
с нехваткой памяти?
или тормозами?

как только подумаю о Лизе Су, так и встаёт колом…

Если у него у уже фризит от нехватки озу

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

ТС не локализовал проблему, вообще.

ты можешь:
а) уменьшить употребление цинка и сахара.
б) передёрнуть

Почему? Честно говоря, не очень понимаю, чем 1 отличается от 0. При 2 все понятно – оверкомит запрещен. При 1 оверкомит разрешен, как и при 0. В чем подвох?

у меня devuan ascii i686 установлен на атлоне с 1 гигом озу… ну как-бы даже если ФФ 78 использовать и на каком-нибудь ютубе начинается тормозня - в консоль пускает…

А вот плюсану данного товарища.

При 2 все понятно – оверкомит запрещен

Разрешен, в зависимости от overcommit ratio.

1 - разрешен всегда, можно выделять терабайты без ограниченй (на самом деле есть лимит терабайт в 30)

1 - дефолт - guess mode, в основном оверкоммит разрешен, зависит от нагрузки.

то ему надо удалять говнософт

Не обязательно. С хорошим ядром (le9 patch, swap on zram) фризов нет: https://www.youtube.com/watch?v=d4Sc80TMEtA

где патчи в апстрим? ;-)

При нехватке памяти (предположительно) возникает очень высокий I/O, что ведет к общему зависанию.