Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня

Модератор: LinuxNEWS
Аватара пользователя

Автор темы
ikrost
Сообщения: 555
Зарегистрирован: 12 май 2017, 17:20
Решено: 1
Откуда: Тбилиси
Благодарил (а): 831 раз
Поблагодарили: 83 раза
Контактная информация:

Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня

#1

10 авг 2019, 10:44

https://3dnews.ru/992024?utm_referrer=h ... yandex.com

Всё так печально? Что-то не замечал.

Аватара пользователя

symon2014
Сообщения: 5924
Зарегистрирован: 16 дек 2017, 21:59
Решено: 36
Откуда: Феодосия
Благодарил (а): 32 раза
Поблагодарили: 747 раз
Контактная информация:

Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня

#2

10 авг 2019, 10:54

Разве что открывать поменьше вкладок. Но это, разумеется, лишь не слишком приятная альтернатива.
А дофига ли тут пасётся вэбдизайнеров , майтейнеров и всяких девелоперов , которые жрут память у ядра лопатами? :-D

no avatar

x230
Сообщения: 2094
Зарегистрирован: 02 сен 2016, 22:07
Решено: 5
Благодарил (а): 406 раз
Поблагодарили: 487 раз
Контактная информация:

Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня

#3

10 авг 2019, 11:10

ikrost, угу, читал вот тут. Взгрустнул и махнул рукой.

Аватара пользователя

slant
Сообщения: 4469
Зарегистрирован: 21 июн 2017, 18:09
Решено: 95
Благодарил (а): 51 раз
Поблагодарили: 1966 раз
Контактная информация:

Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня

#4

10 авг 2019, 11:16

Все сводится к вот этому описанию:
Суть в следующем — при отключённом swap, если пользователь начинает открывать много вкладок в браузере, в какой-то момент веб-обозреватель может потребовать больше ОЗУ, чем есть. После этого система почти полностью зависает, идёт постоянное обращение к диску, текущие приложения нельзя будет закрыть, как и запустить новые.
Из разряда - впихнуть невпихуемое.

На нормально настроенной системе эта ситуация вызывает своп, да. Но система не зависает, т.к. вполне есть куда деть ненужную "вот прямо щас" память. Это, блин, не андроид, который в подобном случае просто прибьет одно из старых запущенных приложений висящих в фоне без спроса. Десктопная система как-бы предполагает, что запущенная программа - она таки нужна, и в ней что-то полезное делали, что нельзя так просто терять.
На практике - у меня на ноутбуке с 2Гб памяти, при активном лазаньи в нете иногда и 6Гб адресуется. Разумеется в своп при этом уходит дофига, разумеется долго, разумеется даже вкладки переключаются задумчиво, но ни о каком полном зависании системы речи нет.

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

Аватара пользователя

kutalgin
Сообщения: 156
Зарегистрирован: 08 июл 2018, 08:42
Откуда: Ишимбай
Благодарил (а): 12 раз
Поблагодарили: 14 раз
Контактная информация:

Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня

#5

10 авг 2019, 11:57

Хм, а у меня при разделе свап, система зависает, когда память кончится. Хотя свап заполняется на 100-200мб. Свап разделом.
Ишимбайский

Аватара пользователя

slant
Сообщения: 4469
Зарегистрирован: 21 июн 2017, 18:09
Решено: 95
Благодарил (а): 51 раз
Поблагодарили: 1966 раз
Контактная информация:

Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня

#6

10 авг 2019, 12:04

Небось, по советам из интернета - "vm.swappiness = 5" стоит?

no avatar

Griga211
Сообщения: 405
Зарегистрирован: 01 окт 2016, 15:20
Решено: 2
Благодарил (а): 9 раз
Поблагодарили: 62 раза
Контактная информация:

Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня

#7

23 авг 2019, 09:02

slant писал(а):
10 авг 2019, 12:04
Небось, по советам из интернета - "vm.swappiness = 5" стоит?
Необязательно советы. У меня на дебиане и арче такая проблема и тянется она очень давно. На минте не могу сказать, потому как минт используется только для серфинга, ему и 4гб хватает без свопа, много вкладок не открываю. А вот на вышеупомянутых системах с 8 гб при работе с исо или в играх даже со свопом случаются эти траблы с оперативой. Сценарий таков: пользуешься ПК, через какое то время кэшем может забиться вплоть до 6 Гб, остальное система и свободная память, приложения все закрыты, своп при этом будет пустой даже несмотря на то что в графе свободно останется всего 1Гб, но в графе доступно будет 7гб. При этом параметр сваппинес по умолчанию 60. Если запустить танчики, то во втором бою начнутся тормоза, лаги и зависания. В свап будет выгружаться только тогда когда графа занято превысит отметку в 40% от общего общего объёма, а это начиная с 3,2 Гб, но танчикам у меня надо где то 3,8. Т е. В свап уйдет всего 600 мб. Но в графе свободно будет балансировать в районе 100-150 мб, потому как минималка установлена в 65мб. При этом система начинает запинаться и чуть ли не падать. Игра 100% зависает, играть невозможно. А если ещё и видеопамяти всего 1гб а игре надо 1,6, то это 100% труп.. Система начинает балансировать на этих 100мб. Это треш.
Можно дропать кэш ручками, можно прописать остаток ОЗУ не 65 мб, а пару гигов, можно поиграться с сваппинесом, но только не через sysctl.conf, потому что, например, на арче он не работает, точнее работает, но ядро при загрузке все равно перезаписывает значения по умолчанию, поэтому надо писать скрипт чтобы параметры применялись уже после запуска. Вот как то так.

Аватара пользователя

zuzabrik
Сообщения: 1744
Зарегистрирован: 29 авг 2016, 12:08
Решено: 20
Благодарил (а): 108 раз
Поблагодарили: 521 раз
Контактная информация:

Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня

#8

10 ноя 2019, 07:51

Одним из решений проблемы могло бы быть убийство всех смузихлебов пишущих текстовые редакторы выжигающие по пол гигабайта ОЗУ при открытии. А то читаешь потом коменты в стиле "если хочешь работать в VSCode будь добр поставить 16Гб оперативы" :-D При том что это просто сраный редактор кода типа Geany...
А мог бы стать нормальным человеком...

Аватара пользователя

Slav164
Сообщения: 264
Зарегистрирован: 01 фев 2018, 15:41
Откуда: Барнаул
Благодарил (а): 12 раз
Поблагодарили: 32 раза
Контактная информация:

Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня

#9

10 ноя 2019, 08:02

Если swap на разделе ,то его можно попробовать жать.
zswap.enabled=1
А нехватку ram восполнить используя zram.

Аватара пользователя

slant
Сообщения: 4469
Зарегистрирован: 21 июн 2017, 18:09
Решено: 95
Благодарил (а): 51 раз
Поблагодарили: 1966 раз
Контактная информация:

Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня

#10

10 ноя 2019, 14:23

zuzabrik писал(а):
10 ноя 2019, 07:51
При том что это просто сраный редактор кода типа Geany...
Скажите, а вы его сами, лично хоть раз открывали? Код в нем писали? Или чужие слова повторяете?
Я писал, более того - перешел на него с Sublime text (если вам это название что-то говорит), из-за множества удобных мелочей и общей шустрости работы. Редактор явно писался программистами для программистов - ощущения: только думаешь - "а вот мне бы сейчас такая фича очень пригодилась" - смотришь, а она в редакторе уже есть, и работает именно как тебе хочется. (Вообще-то это не редактор а IDE общего назначения, если уж на то пошло, а они никогда легковестностью не страдают, даже специализированные на одном языке.)
Да, потребление памяти у него не самое маленькое. Но и не 16 гиг. У меня там сейчас загружен проект с ~полтысячи файлов JS общим объемом под полгига, открыто одновременно ~30 файлов. Потребление памяти - все те же полгига. Причем практически мгновенно работает полнотекстовый поиск с регекспами по всему проекту и обращение в git. Ладно, если вам надо в собственном коде разбираться, где вы почти все помните. А если чужой проект, где только такой поиск с возможностью потому найти связанные места (что откуда вызывалось, или вызывает, где объявляется, и откуда здесь это вообще появилось) и спасает?
Так что, я бы сказал - это как раз пример как НАДО на электроне писать. Если уж взялись.

Аватара пользователя

zuzabrik
Сообщения: 1744
Зарегистрирован: 29 авг 2016, 12:08
Решено: 20
Благодарил (а): 108 раз
Поблагодарили: 521 раз
Контактная информация:

Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня

#11

10 ноя 2019, 14:42

slant, Он у меня стоит на минте. Что забавно, распространяется микрософтом, а на минте встал как родной, в отличие от винды, где пока его рожей в .net core не ткнешь не найдет. Да и .net core встал как родной :-D

У меня просто горит пердак что я на ПК с 8Гб ОЗУ все равно поглядываю в монитор ресурсов и вижу как у меня своп юзается, и для этого не надо особо что-то выдумывать, пара вкладок в браузере с музычкой и доками, такой вот редактор какой-нить, почтовый клиент и еще чё :) Изменил дефолтный swappiness на 20, посмотрим как пойдет. Но вот почему IDE весит при запуске больше чем вся моя ОС с ДЕ я никогда не пойму.
А мог бы стать нормальным человеком...

Аватара пользователя

slant
Сообщения: 4469
Зарегистрирован: 21 июн 2017, 18:09
Решено: 95
Благодарил (а): 51 раз
Поблагодарили: 1966 раз
Контактная информация:

Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня

#12

10 ноя 2019, 14:50

zuzabrik писал(а):
10 ноя 2019, 14:42
Но вот почему IDE весит при запуске больше чем вся моя ОС с ДЕ я никогда не пойму.
Если имеется в виду полгига - дык там библиотеки electron подгружаются, они в отличии от библиотек C не системные, и не загружаются в память сразу. Кроме того выделяется память под индексы, кеширование, и прочее хозяйство похожее на базу данных - что и позволяет обеспечивать быстрый поиск и связки между файлами исходников. Ничего странного - за быстродействие платим объемом выделенной заранее памяти - это общий принцип, не только для IDE а для многих видов софта.
zuzabrik писал(а):
10 ноя 2019, 14:42
У меня просто горит пердак что я на ПК с 8Гб ОЗУ все равно поглядываю в монитор ресурсов и вижу как у меня своп юзается,
Мой подход - пусть себе юзается. Как я уже где-то тут на форуме объяснял - лучше если своп заранее будет заюзан (фоном не блокируя систему), чем в последний момент когда свободной памяти УЖЕ нету. Пусть лучше система скинет в своп неиспользуемые сейчас данные сильно заранее - тогда в критический момент не будет полного фриза. Сейчас основная проблема в настройках по умолчанию на многих системах именно в том, что они держат данные в памяти до последнего, а так же не возвращают из свопа эти данные заранее при освобождении памяти. Ну и "блоки" на эти операции слишком мелкие для нынешних объемов памяти.
Правда когда память оказывается занята одной задачей/игрой как в сообщении выше - это не поможет. Но там ничего не поможет, по определению. Своп работает, если в памяти много задач, но не все они решаются одновременно, т.е. на диск можно скинуть что-то, что сейчас просто висит в памяти без дела.

Ответить

Вернуться в «Другие новости»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 6 гостей