https://opennet.me/openforum/vsluhforumID3/118068.html Известна (https://lkml.org/lkml/2019/8/4/15) проблема, которая донимает множество людей на протяжении многих лет и которую можно воспроизвести меньше, чем за несколько минут на последней версии ядра Linux 5.2.6. Все параметры ядра установлены в значения по умолчанию.<br><br><br>Шаги:<br><br><br>- Загружаемся с параметром mem=4G<br>- Выключаем поддержку swap (sudo swapoff -a)<br>- Запускаем любой веб браузер, например, Chrome/Chromium или/и Firefox<br>- Начинаем открывать вкладки с сайтами и смотрим как уменьшается объём свободной памяти<br><br><br><br><br>Как только возникает ситуация, что новая вкладка требует больше оперативной памяти, чем доступно, система практически полностью зависает. Вы даже с трудом сможете двигать курсором мыши. Индикатор жёсткого диска будет моргать без остановки (мне не ясно почему). Вы не сможете запустить новые приложения или закрыть текущие запущенные.<br><br><br>Этот маленький кризис может продолжаться минуты или дольше. Я предполагаю, что система не так должна себя вести в этой ситуации. Я думаю, что что-то нуж https://opennet.me/openforum/vsluhforumID3/118068.html#620 Wed, 02 Jul 2025 12:37:37 GMT Решается prelockd/mglru.<br>Управление памятью в десктопном линуксе устарело на 30 лет.<br> https://opennet.me/openforum/vsluhforumID3/118068.html#618 Sat, 08 Feb 2020 14:35:41 GMT Бро, в МО плотность низкая, если ты про Мск, то Мск не входит в МО<br> https://opennet.me/openforum/vsluhforumID3/118068.html#617 Wed, 04 Dec 2019 09:14:04 GMT Проблема с очень большим захватом памяти при открытии новой вкладки FF и полным торможением при свопировании при заполнении RAM существует. Но там я думаю, много виновников - и плохое управление свопированием и использованием памяти многими ядрами, работой с памятью FireFox и выделением её для addons.<br>Включение zSWAP поможет, отсрочив и немного сократив это зависание, тюнинг его настроек может слегка улучшить работу в конкретном случае.<br>Но думаю, что у Вас много ядер CPU и включено одновременно много аддонов, в первую очередь блокирующих, конкурирующих между собой при открытии сильно захламленных рекламой сайтов: SmartAdBlock, Adblock Plus, uBlock Origin и тп (лечил уже такое). Рекомендую попробовать оставить из блокираторов только скажем &#171;uBlock Origin&#187;, может и &#171;NoScript&#187; оставить.<br> https://opennet.me/openforum/vsluhforumID3/118068.html#616 Sat, 02 Nov 2019 12:45:55 GMT Нет, этот параметр такого не делает.<br> https://opennet.me/openforum/vsluhforumID3/118068.html#615 Sun, 01 Sep 2019 06:38:44 GMT Купить за эти $50 б\у системник на целероне, и прекратить насиловать проц для медиаплеера, в попытках сделать из него сервер.<br> https://opennet.me/openforum/vsluhforumID3/118068.html#614 Wed, 21 Aug 2019 12:49:29 GMT Легендарный суперкодеры заняты на работе, думаю.<br> https://opennet.me/openforum/vsluhforumID3/118068.html#613 Mon, 19 Aug 2019 08:58:14 GMT &gt;&gt;сразу отвалит с ошибкой, а не будет "мусолить" систему <br>&gt; Нет, MemoryError - это вам не SIGKILL.<br><br>&lt;sarcazm&gt;Без этого уточнения - никак не понять.&lt;/sarcazm&gt;<br><br>&gt; Приложение может обрабатвавать MemoryError вовсе не падать, и своим присутствием заставлять <br>&gt; падать другие, невиновные приложения, которые пытаются выделить себе память. См скриншоты <br>&gt; выше.<br><br>Так и должно быть, приложения должны уметь обрабатывать такие ошибки. А если какое-то приложение устроит гонку, то сработает oomkiller и это правильно. А если хочется что-то "прибить гвоздями" в памяти, то oom_score_adj в помощь.<br><br> https://opennet.me/openforum/vsluhforumID3/118068.html#612 Mon, 19 Aug 2019 01:42:55 GMT &gt;сразу отвалит с ошибкой, а не будет "мусолить" систему<br><br>Нет, MemoryError - это вам не SIGKILL.<br><br>Приложение может обрабатвавать MemoryError вовсе не падать, и своим присутствием заставлять падать другие, невиновные приложения, которые пытаются выделить себе память. См скриншоты выше.<br> https://opennet.me/openforum/vsluhforumID3/118068.html#611 Sun, 18 Aug 2019 12:03:57 GMT &gt; Документация пдтверждает мою правоту: <br>&gt; "in most situations <br>&gt; this means a process will not be killed while accessing <br>&gt; pages but will receive errors on memory allocation as <br>&gt; appropriate." <br>&gt; https://www.kernel.org/doc/Documentation/vm/overcommit-accounting <br>&gt; И закономерный итог - https://imgur.com/a/p9j67KA - процессы валятся на ошибках.<br><br>"in most situations" - значит не во всех ситуациях. Срабатывают оба варианта, проверено. <br>И второе поведение и является правильным. Значение vm.overcommit_ratio = 200 - устанавливает в двое больший размер для аллоцирования, чем есть в системе, потому, любое ПО которое будет пытаться занять размер больше чем свободно в системе, просто сразу отвалит с ошибкой, а не будет "мусолить" систему.<br>