https://3dnews.ru/992024?utm_referrer=h ... yandex.com
Всё так печально? Что-то не замечал.
Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня
Модератор: LinuxNEWS
-
- Сообщения: 5934
- Зарегистрирован: 16 дек 2017, 21:59
- Решено: 37
- Откуда: Феодосия
- Благодарил (а): 32 раза
- Поблагодарили: 750 раз
- Контактная информация:
Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня
А дофига ли тут пасётся вэбдизайнеров , майтейнеров и всяких девелоперов , которые жрут память у ядра лопатами?Разве что открывать поменьше вкладок. Но это, разумеется, лишь не слишком приятная альтернатива.
-
- Сообщения: 4506
- Зарегистрирован: 21 июн 2017, 18:09
- Решено: 99
- Благодарил (а): 51 раз
- Поблагодарили: 1993 раза
- Контактная информация:
Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня
Все сводится к вот этому описанию:
На нормально настроенной системе эта ситуация вызывает своп, да. Но система не зависает, т.к. вполне есть куда деть ненужную "вот прямо щас" память. Это, блин, не андроид, который в подобном случае просто прибьет одно из старых запущенных приложений висящих в фоне без спроса. Десктопная система как-бы предполагает, что запущенная программа - она таки нужна, и в ней что-то полезное делали, что нельзя так просто терять.
На практике - у меня на ноутбуке с 2Гб памяти, при активном лазаньи в нете иногда и 6Гб адресуется. Разумеется в своп при этом уходит дофига, разумеется долго, разумеется даже вкладки переключаются задумчиво, но ни о каком полном зависании системы речи нет.
А эти ребята хотят, чтобы ядро само занималось сортировкой вкладок броузера и говорило ему - "вот это сейчас выкини, а то у меня память закончилась - потом заново загрузишь". Тогда, как по уму за подобным своими вкладками нормально написанный броузер сам следить должен - его епархия. Сведения о количестве свободной памяти в системе ему доступны.
Из разряда - впихнуть невпихуемое.Суть в следующем — при отключённом swap, если пользователь начинает открывать много вкладок в браузере, в какой-то момент веб-обозреватель может потребовать больше ОЗУ, чем есть. После этого система почти полностью зависает, идёт постоянное обращение к диску, текущие приложения нельзя будет закрыть, как и запустить новые.
На нормально настроенной системе эта ситуация вызывает своп, да. Но система не зависает, т.к. вполне есть куда деть ненужную "вот прямо щас" память. Это, блин, не андроид, который в подобном случае просто прибьет одно из старых запущенных приложений висящих в фоне без спроса. Десктопная система как-бы предполагает, что запущенная программа - она таки нужна, и в ней что-то полезное делали, что нельзя так просто терять.
На практике - у меня на ноутбуке с 2Гб памяти, при активном лазаньи в нете иногда и 6Гб адресуется. Разумеется в своп при этом уходит дофига, разумеется долго, разумеется даже вкладки переключаются задумчиво, но ни о каком полном зависании системы речи нет.
А эти ребята хотят, чтобы ядро само занималось сортировкой вкладок броузера и говорило ему - "вот это сейчас выкини, а то у меня память закончилась - потом заново загрузишь". Тогда, как по уму за подобным своими вкладками нормально написанный броузер сам следить должен - его епархия. Сведения о количестве свободной памяти в системе ему доступны.
-
- Сообщения: 156
- Зарегистрирован: 08 июл 2018, 08:42
- Откуда: Ишимбай
- Благодарил (а): 12 раз
- Поблагодарили: 14 раз
- Контактная информация:
Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня
Хм, а у меня при разделе свап, система зависает, когда память кончится. Хотя свап заполняется на 100-200мб. Свап разделом.
Ишимбайский
-
- Сообщения: 405
- Зарегистрирован: 01 окт 2016, 15:20
- Решено: 2
- Благодарил (а): 9 раз
- Поблагодарили: 62 раза
- Контактная информация:
Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня
Необязательно советы. У меня на дебиане и арче такая проблема и тянется она очень давно. На минте не могу сказать, потому как минт используется только для серфинга, ему и 4гб хватает без свопа, много вкладок не открываю. А вот на вышеупомянутых системах с 8 гб при работе с исо или в играх даже со свопом случаются эти траблы с оперативой. Сценарий таков: пользуешься ПК, через какое то время кэшем может забиться вплоть до 6 Гб, остальное система и свободная память, приложения все закрыты, своп при этом будет пустой даже несмотря на то что в графе свободно останется всего 1Гб, но в графе доступно будет 7гб. При этом параметр сваппинес по умолчанию 60. Если запустить танчики, то во втором бою начнутся тормоза, лаги и зависания. В свап будет выгружаться только тогда когда графа занято превысит отметку в 40% от общего общего объёма, а это начиная с 3,2 Гб, но танчикам у меня надо где то 3,8. Т е. В свап уйдет всего 600 мб. Но в графе свободно будет балансировать в районе 100-150 мб, потому как минималка установлена в 65мб. При этом система начинает запинаться и чуть ли не падать. Игра 100% зависает, играть невозможно. А если ещё и видеопамяти всего 1гб а игре надо 1,6, то это 100% труп.. Система начинает балансировать на этих 100мб. Это треш.
Можно дропать кэш ручками, можно прописать остаток ОЗУ не 65 мб, а пару гигов, можно поиграться с сваппинесом, но только не через sysctl.conf, потому что, например, на арче он не работает, точнее работает, но ядро при загрузке все равно перезаписывает значения по умолчанию, поэтому надо писать скрипт чтобы параметры применялись уже после запуска. Вот как то так.
-
- Сообщения: 1744
- Зарегистрирован: 29 авг 2016, 12:08
- Решено: 20
- Благодарил (а): 108 раз
- Поблагодарили: 521 раз
- Контактная информация:
Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня
Одним из решений проблемы могло бы быть убийство всех смузихлебов пишущих текстовые редакторы выжигающие по пол гигабайта ОЗУ при открытии. А то читаешь потом коменты в стиле "если хочешь работать в VSCode будь добр поставить 16Гб оперативы" При том что это просто сраный редактор кода типа Geany...
А мог бы стать нормальным человеком...
-
- Сообщения: 269
- Зарегистрирован: 01 фев 2018, 15:41
- Откуда: Барнаул
- Благодарил (а): 12 раз
- Поблагодарили: 33 раза
- Контактная информация:
Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня
Если swap на разделе ,то его можно попробовать жать.
zswap.enabled=1
А нехватку ram восполнить используя zram.
zswap.enabled=1
А нехватку ram восполнить используя zram.
-
- Сообщения: 4506
- Зарегистрирован: 21 июн 2017, 18:09
- Решено: 99
- Благодарил (а): 51 раз
- Поблагодарили: 1993 раза
- Контактная информация:
Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня
Скажите, а вы его сами, лично хоть раз открывали? Код в нем писали? Или чужие слова повторяете?
Я писал, более того - перешел на него с Sublime text (если вам это название что-то говорит), из-за множества удобных мелочей и общей шустрости работы. Редактор явно писался программистами для программистов - ощущения: только думаешь - "а вот мне бы сейчас такая фича очень пригодилась" - смотришь, а она в редакторе уже есть, и работает именно как тебе хочется. (Вообще-то это не редактор а IDE общего назначения, если уж на то пошло, а они никогда легковестностью не страдают, даже специализированные на одном языке.)
Да, потребление памяти у него не самое маленькое. Но и не 16 гиг. У меня там сейчас загружен проект с ~полтысячи файлов JS общим объемом под полгига, открыто одновременно ~30 файлов. Потребление памяти - все те же полгига. Причем практически мгновенно работает полнотекстовый поиск с регекспами по всему проекту и обращение в git. Ладно, если вам надо в собственном коде разбираться, где вы почти все помните. А если чужой проект, где только такой поиск с возможностью потому найти связанные места (что откуда вызывалось, или вызывает, где объявляется, и откуда здесь это вообще появилось) и спасает?
Так что, я бы сказал - это как раз пример как НАДО на электроне писать. Если уж взялись.
-
- Сообщения: 1744
- Зарегистрирован: 29 авг 2016, 12:08
- Решено: 20
- Благодарил (а): 108 раз
- Поблагодарили: 521 раз
- Контактная информация:
Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня
slant, Он у меня стоит на минте. Что забавно, распространяется микрософтом, а на минте встал как родной, в отличие от винды, где пока его рожей в .net core не ткнешь не найдет. Да и .net core встал как родной
У меня просто горит пердак что я на ПК с 8Гб ОЗУ все равно поглядываю в монитор ресурсов и вижу как у меня своп юзается, и для этого не надо особо что-то выдумывать, пара вкладок в браузере с музычкой и доками, такой вот редактор какой-нить, почтовый клиент и еще чё Изменил дефолтный swappiness на 20, посмотрим как пойдет. Но вот почему IDE весит при запуске больше чем вся моя ОС с ДЕ я никогда не пойму.
У меня просто горит пердак что я на ПК с 8Гб ОЗУ все равно поглядываю в монитор ресурсов и вижу как у меня своп юзается, и для этого не надо особо что-то выдумывать, пара вкладок в браузере с музычкой и доками, такой вот редактор какой-нить, почтовый клиент и еще чё Изменил дефолтный swappiness на 20, посмотрим как пойдет. Но вот почему IDE весит при запуске больше чем вся моя ОС с ДЕ я никогда не пойму.
А мог бы стать нормальным человеком...
-
- Сообщения: 4506
- Зарегистрирован: 21 июн 2017, 18:09
- Решено: 99
- Благодарил (а): 51 раз
- Поблагодарили: 1993 раза
- Контактная информация:
Ядро Linux не умеет обрабатывать нехватку ОЗУ — проблема снова на повестке дня
Если имеется в виду полгига - дык там библиотеки electron подгружаются, они в отличии от библиотек C не системные, и не загружаются в память сразу. Кроме того выделяется память под индексы, кеширование, и прочее хозяйство похожее на базу данных - что и позволяет обеспечивать быстрый поиск и связки между файлами исходников. Ничего странного - за быстродействие платим объемом выделенной заранее памяти - это общий принцип, не только для IDE а для многих видов софта.
Мой подход - пусть себе юзается. Как я уже где-то тут на форуме объяснял - лучше если своп заранее будет заюзан (фоном не блокируя систему), чем в последний момент когда свободной памяти УЖЕ нету. Пусть лучше система скинет в своп неиспользуемые сейчас данные сильно заранее - тогда в критический момент не будет полного фриза. Сейчас основная проблема в настройках по умолчанию на многих системах именно в том, что они держат данные в памяти до последнего, а так же не возвращают из свопа эти данные заранее при освобождении памяти. Ну и "блоки" на эти операции слишком мелкие для нынешних объемов памяти.
Правда когда память оказывается занята одной задачей/игрой как в сообщении выше - это не поможет. Но там ничего не поможет, по определению. Своп работает, если в памяти много задач, но не все они решаются одновременно, т.е. на диск можно скинуть что-то, что сейчас просто висит в памяти без дела.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 5 гостей