Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
Сообщение от opennews (ok), 02-Мрт-20, 20:25
После восьми месяцев разработки опубликован выпуск фонового процесса earlyoom 1.4, который периодически проверяет объем доступной памяти (MemAvailable, SwapFree) и пытается на ранней стадии отреагировать на возникновения нехватки памяти. Код проекта написан на языке Си и распространяется под лицензий MIT... Подробнее: https://www.opennet.me/opennews/art.shtml?num=52465
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+3 +/–
Сообщение от cat666 (ok), 02-Мрт-20, 20:25
Выпуск фонового процесса... Вон оно нынче как... Выпускайте Кракена.
Ответить | Правка | Наверх | Cообщить модератору

	99. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+5 +/–
	Сообщение от Аноним (-), 03-Мрт-20, 10:29
	> Выпуск фонового процесса... Вон оно нынче как... Выпускайте Кракена. А он вебмакаками питается? Если да - цып, цып, цып, цып, у нас тут много еды! Иди сюда!
	Ответить | Правка | Наверх | Cообщить модератору

2. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+12 +/–
Сообщение от Аноним (2), 02-Мрт-20, 20:31
Почему нельзя в ядре допилить этот диспечер памяти? Нет вместо этого будем городить всякие user-space костыли.
Ответить | Правка | Наверх | Cообщить модератору

	4. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (4), 02-Мрт-20, 20:34
	Допили. У меня даже есть идея: берешь этот обработчик и высылаешь его Торвальдсу, мол: "Смари, чувак, мне не нравится нынешнее состояние в ядре. Давай ты сделаешь вот так!"
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+2 +/–
	Сообщение от zzz (??), 03-Мрт-20, 02:21
	Анониму за это не платят, в отличие от 95% разработчиков линукса. Которые в перерывах между допиванием кофейной гущи и ковырянием в носу вот уже 20 лет как не могут запилить нормальный OOM в ядре. Нигде такой фигни нет - под виндой процессы нормально киляются, под фрюхой, да даже под симбианом, и только под линуксом разрабы заняты чем угодно, но только не решением покрытого мхом бага, что ажно приходится костылить пяток юзерспейсных демонов.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+5 +/–
	Сообщение от rshadow (ok), 03-Мрт-20, 09:56
	Не надо нам тут сказок про винду. Знаем - плавали. Там вообще вероятность работы 50/50. Может и диспетчер задач тупо не открыться. Даже без нагрузки. "Семь бед - один ресет".
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от Аноним (103), 03-Мрт-20, 10:48
	А я сужу по практике. Может мне конечно повезло см железом. Но у меня несколько месяцев работала Win 10, я ее только отходя куда-то отправлял в hibernation. Ни одного падения, зависания, все как часы работало.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+4 +/–
	Сообщение от Аноним (119), 03-Мрт-20, 11:44
	И как это связано с нехваткой памяти? пробовали в windows память всю занимать?
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от Аноним (176), 04-Мрт-20, 02:50
	> И как это связано с нехваткой памяти? пробовали в windows память всю занимать? Это он так спалился что винды оказывается умеют виснуть намертво при выходе из STR и тому подобных режимов, очень приятно получается, как серпом по... :)
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 10:37
	> Нигде такой фигни нет - под виндой процессы нормально киляются, Ыгы, если гуйня вообще прорисуется. Если не прорисуется за разумное время, из-за системного душняка - сушите весла! Никакого эквивалента например alt-sysrq-n чтобы построить приоритетный такс там нету! И alt-sysrq-f чтобы вынести жирный таск вызывающий свопление без всяких гуев - тоже. > под фрюхой, да даже под симбианом, Не знаю как во фрюхе (она меня задолбала задолго до таких мелочей и я ее вынес до настолько интимных знакомств), а в симбиане это примерно так: вот вы чатитесь в паре чатиков, браузя между делом файлики и что-то еще. Фигак! Ни чатиков, ни файлов, ни прочих глупостей. Вот те абсолютная лысая система, дорогой юзерь. Но вам же не впадлу переконектиться в чатики и забрести в диру файлменеджером заново, правда? :) > и только под линуксом разрабы заняты чем угодно, но только не решением покрытого мхом бага, > что ажно приходится костылить пяток юзерспейсных демонов. Внезапно, линух используется в дофига применений, в отличие от симбианов и фрибсд, так что 1 размер всем таки не катит.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	133. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от zzz (??), 03-Мрт-20, 13:44
	>Никакого эквивалента например alt-sysrq-n Ты путаешь причину и следствие. Это не линукс такой хороший, что в нем есть даже такая комбинация, а комбинация появилась, потому что линукс такой плохой. И да, полно случаев, когда система встает колом так, что даже alt-sysrq-n не отрабатывает. >так что 1 размер всем таки не катит В линухе куча рабочих планировщиков как процессов, так и IO под разные применения. Ни одного рабочего OOM нет до сих пор. Линукс - это серьезно (с).
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (150), 03-Мрт-20, 17:41
	> Ты путаешь причину и следствие. Это не линукс такой хороший, что в > нем есть даже такая комбинация, а комбинация появилась, потому что линукс такой плохой. Офигенное понимание дел системных, тудыть-растудыть! А я то думал что проблема - в том что realtime (да и просто высокоприоритетный) процесс BY DESIGN может крепко узурпировать систему. Изначально - для реалтаймного отклика, но ежели что-то пойдет не так, в остальной системе, видите ли, душняк с временем процессора может наступить. Потому что так условились что процесс важен, а он решил взять и офигеть. И это как бы BY DESIGN, на уровне семантики. При том на системе где реалтайм реально роялит - это даже может быть желаемым и нужным состоянием дел. Хоть програмер и должен по уму вынести heavy lifting на низкоприоритетные worker'ы. Нормально это, кстати, только в линуксе и можно: там разным тредам можно разный приоритет вкатить, хоть это и не соответствует кретинизму который в POSIX. В этом месте линухоиды таки положили на стандарт во имя здравого смысла. И таки в линухе у 1 задачи могут быть треды с разными приоритетами. А у остальных... ацаца :). В винде не помню, там вроде тоже так можно. И таки в винде высокоприоритетный процесс хрен срубишь, если он офигеет. Можно заманаться таскменеджера ждать. > И да, полно случаев, когда система встает колом так, что даже alt-sysrq-n не отрабатывает. EPIC BULLSHIT. Это кернелем рюхается, так что не срабатывать может только если отключено, разве что. Как максимум до него alt-sysrq-r может потребоваться, если из иксов, чтобы raw mode клавы форсировать, мало ли чего там софт настроил. Но вот конкретно эти комбо работают железобетонно, даже цук по сериальному шнурку (с break'ом). > В линухе куча рабочих планировщиков как процессов, так и IO под разные > применения. Ни одного рабочего OOM нет до сих пор. Линукс - это серьезно (с). Там вообще-то вполне рабочий OOM killer. И весьма конфигуряемый. Просто система его сама пнет только когда память уже вообще совсем закончилась. В системе с большим свопом этого момента можно ждать довольно долго.
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от mikhailnov (ok), 03-Мрт-20, 15:05
	Выкладывайте свои предложения по алгоритму работы правильного ООМ
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	204. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от kek (??), 05-Мрт-20, 08:37
	Всё давно выложено и реализовано в nohang и oomd.
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+2 +/–
	Сообщение от Аноним (11), 02-Мрт-20, 20:41
	Этот же earlyoom можно без проблем засунуть в ядро в виде earlyoom.ko, но просто пилить его будет сложней, опции менять сложней (например, sysctl, что не очень визуально, как, например, конфиг в /etc), получать оповещения сложней (только если вываливать в dmesg, но как-то это надо ловить и показывать пользователю). Плюс, всякие ограничения ядра по поводу coding style - тут пишешь себе на github и не паришься. Например, в Windows этой проблемы нет, потому что ntoskrnl связано с GUI и может посылать сообщения explorer.exe и в Windows Notifications (Win 8 и выше). в Лине kernel само по себе, Xorg сам по себе, user X session само по себе. Для ядра ваш KDE/Gnome/Unity/XFCE просто процесс. Короче, будем и дальше жить с user-space обработчиком. В лине всё идеально - вы забыли? Только идиоты-пользователи и кривое железо - надо покупать православное, как мне сказали в соседнем обсуждении: https://www.opennet.me/openforum/vsluhforumID3/119938.html#205 Абсолютно типичный ноут на 99% из Intel без NVIDIA/AMD discrete'ной графики - уже "специфичное железо". // b.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	82. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Q2W (?), 03-Мрт-20, 08:12
	А в чём минусы earlyoom в userspace? Пусть живёт там себе дальше.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 10:45
	> А в чём минусы earlyoom в userspace? Потенциально менее надежно. Ядро себя при управлении ресурсами точно не обидит. И поэтому чтобы скопытился именно важный компонент ядра - ну разве что после всего остального уже, если душняк почему-то не пропал (e.g. conntrack неадекватный размеру RAM на мелкой мыльнице). А вот для юзермода удостовериться что никогда не поплохеет софтине рулящей такими аспектами - очень нетривиально. Отдельные приветы всякой пихтонрасии, где это вообще mission impossible. > Пусть живёт там себе дальше. Однако почему б что-то такое не было в кернеле - все ж вопрос. А юзермод мог бы конфигурять. Ну вон OOM killer так примерно и работает, но он врубается либо если памяти совсем нет, либо если его мануально по alt-sysrq-f позвать.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от Q2W (?), 03-Мрт-20, 08:13
	Комментатор выше жаловался на на это, а на то, что ядро могло бы и отказать очередному процессу, который попросил памяти, которой уже нет и, если всё-таки выдать, система встанет колом.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	95. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (95), 03-Мрт-20, 10:22
	проблемы с коммуникацией - надуманные. chardev для связи с клиентом, который уже будет оповещения ловить в обрабатывать (модуль ядра + клиент отличается от нынешней схемы тем, что без клиента модуль будет работать, но без оповещений) конфиг нагляднее? - конфиг может поменяться, а reload не выполнен, куда нагляднее настройки в /sys/ для тюнинга и/или в /proc для суммарного отображения.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	140. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (140), 03-Мрт-20, 15:20
	Всё классно звучит. Возьмётесь? // b.
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+2 +/–
	Сообщение от VINRARUS (ok), 02-Мрт-20, 20:42
	По тому же почему нельзя заставить Linux не вешать систему при копировании сотен мелких файлов на 8ми ядрах — этому ядру уже ничего не поможет.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	28. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–3 +/–
	Сообщение от Аноним (-), 02-Мрт-20, 21:24
	Под Linux, система вешается при копировании большого объёма, десятки гигов, и не важно мелкие файлы или нет.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+2 +/–
	Сообщение от заминированный тапок (ok), 02-Мрт-20, 22:49
	переносил исходники UE4 с одного диска на другой, около 86Гб и тысячи мелких файлов никто никуда не повесился ЧЯДНТ?
	Ответить | Правка | Наверх | Cообщить модератору

	43. Скрыто модератором	–4 +/–
	Сообщение от VINRARUS (ok), 02-Мрт-20, 23:12
	Windows?
	Ответить | Правка | Наверх | Cообщить модератору

	48. Скрыто модератором	–1 +/–
	Сообщение от Анончик999 (?), 03-Мрт-20, 00:22
	Да не страдай больше, просто пользуйстя Windows 10. Кстати, лицензию купить не забудь!
	Ответить | Правка | Наверх | Cообщить модератору

	77. Скрыто модератором	+/–
	Сообщение от пох. (?), 03-Мрт-20, 07:24
	> Да не страдай больше, просто пользуйстя Windows 10. Кстати, лицензию купить не > забудь! о, да, "буду жрать гимно с лопаты, патамушта тут 6ешплатна!"
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (52), 03-Мрт-20, 01:34
	>исходники UE4 >около 86Гб Что там в UE такого, чтобы набрать эти 86 гигов написанного людьми кода, если дале 1 мег текста - это очень много? Я сомневаюсь, что вообще существуют такие большие проекты.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	116. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от заминированный тапок (ok), 03-Мрт-20, 11:37
	* PhysX * модули и системы сборки MaCOS,iOS,Android,Windows,Linux,.... ну и всех остальных поддреживаемых платформ * куча плагинов и дополнений из маркетплейса * и тд и тп * + промежуточные файлы после компиляции (я просто не почистил всё ненужное) конечно, еслив всё это почистить, то размер можно порезать в x2-x3 раза установленный под виндой винарниками около 15 Гб весит  +/-
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от llirik (ok), 03-Мрт-20, 07:01
	не так давно (около 3 месяцев назад наверное), разворачивал на машине почти 100 гиговый бэкап в основном с фоточками плюс какое-то количество документов. Что-то делаю не так?
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	78. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 03-Мрт-20, 07:33
	> не так давно (около 3 месяцев назад наверное), разворачивал на машине почти > 100 гиговый бэкап в основном с фоточками плюс какое-то количество документов. > Что-то делаю не так? бэкап. А у товарища - с fs на нее же или другую такую же, и обе, небось, ext4 с _журналом_ (это важно). То есть очень похоже на 12309 во всей его красе. И важно не число гигов (главное чтоб на порядок больше чем кэш позволяет вместить) а количество, фоточки плохой тест, вот как у анона - исходники UE - хороший. Там, правда, насмерть не висло, но прервать этот процесс при околонулевой реакции системы было непросто. А учитывая что его с тех пор десять раз починили и даже два раза закрыли - теперь при каких-нибудь интересных сочетаниях условий может и виснуть ;-)
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 10:19
	>А у товарища - с fs на нее же или другую такую же, и обе, небось, ext4 с _журналом_ (это важно) Нет, у меня на обоих винтах btrfs
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 03-Мрт-20, 11:29
	и тоже виснет? Ну, в целом и неудивительно, у нее количество лишних записей еще больше чем у ext4, хотя и была у меня смутная надежда что локап где-нибудь непосредственно около журнала и его обработчиков.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 11:41
	разумеется виснет, это же я написал несколько сообщений, что при копировании виснет
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (152), 03-Мрт-20, 18:06
	> смутная надежда что локап где-нибудь непосредственно около журнала и его обработчиков. Скорее этот умник пихнул активно кантуемые файлопомойки на системный диск. А напрасно! Вот конкретно ты думаю в курсе одной интимной особенности: страницы executable'ов можно вытряхнуть если потом можно подчитать из файла. При душняке, даже если свопа нет (или он в каком там zram), кернель таки рассмотрит executable'ы в этом качестве. И если уж плеваться в линь кислотой - то вот за этот рудимент, чтоли. Но большинство местных тупарей в системной механике полные дрова, поэтому даже кислотой обхаркивают самих себя, тупари :) И таки да, на системном SSD баг становится даже, пожалуй, фичой: быстрый readonly swap, не протирающий стораж (readonly же) и вполне эффективный. Вот видимо никто и не парится :)
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

	212. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 05-Мрт-20, 20:09
	>> смутная надежда что локап где-нибудь непосредственно около журнала и его обработчиков. > Скорее этот умник пихнул активно кантуемые файлопомойки на системный диск. А напрасно! а локап-то откуда? > Вот конкретно ты думаю в курсе одной интимной особенности: страницы executable'ов можно > вытряхнуть если потом можно подчитать из файла. При душняке, даже если ну да, мы вот этот цирк вполне наблюдали на том примере, который тут в конце комментов был дан. Чего бы, собственно, и не выбросить то, что даже и свопить не надо, оно и так уже на диске лежит. Понятен, что в случае когда мы не планировали свопинга вообще - было бы некисло эту фичу как-нибудь уметь выключить нафиг, да и low limit на буферный кэш не помешал бы (у zfs arc такой, кстати, есть - как бы ни было плохо, целиком arc никогда не очищается, потому что если его совсем очистить, то ничего работать вообще не будет), но вот чего нет, того нет. А полезешь там ковыряться - обязательно что-то еще поломаешь. Но совсем виснуть-то нахера же ж ?
	Ответить | Правка | Наверх | Cообщить модератору

	218. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (218), 07-Мрт-20, 07:03
	> а локап-то откуда? Ну смотри, душняк памяти. Кернель выкидывает паги его любимой апликухи из рамы, с мыслью подчитать потом из файла, коли так можно было. А когда юзер пытается поюзать апликуху - ну, собссно, она ловит page fault, как обычно -> кернель идет за страницей в бинарь апликухи. И пока оно там ее вынет, особенно ежели сие на механическом диске, да для десятка апликух... ну апликуха и висит тряпочкой. А куда она денется без потребной для продолжения работы страницы? :) > ну да, мы вот этот цирк вполне наблюдали на том примере, который > тут в конце комментов был дан. В случае с SSD баг можно рассмотреть за фичу :P. И ты же понимаешь что разработчики себе не враги и давно накупили SSD. Вот оно их и не парит. > оно и так уже на диске лежит. Проблема с этим вот в чем: ежели мы хотели low latency систему, которая либо отрабатывает, либо обламывается за обозримое время, даже вырубить своп таки не пролечит вот это на 100% т.к. останется этот механизм. Это может быть немного назойливо. Кому принципиально, я знаю минимум 2 хака на тему: 1) Вообще вырубить свопы в конфиге кернеля, это вроде и данный механизм выносит, если не путаю. 2) LD_PRELOAD всем процессам и оттуда mlockall, чтоли, какой. Сие сделает что запрошено, но есть некие побочные эффекты... > Понятен, что в случае когда мы не планировали свопинга вообще - ...мы таки все равно можем получить "computer is thrashing" в объеме превышающем желаемый. > буферный кэш не помешал бы (у zfs arc такой, кстати, есть Только гули толку, без плотной интеграции с остальным mem management оно только все испортит лишний раз. А кто ж его в zfs то с mem management линя то настолько плотно будет дружить? > Но совсем виснуть-то нахера же ж ? Если страниц памяти для апликухи нет - она не может работать :). Это не полный взвис, просто деградация перфоманса. Но это в назойливом виде реально получить на механическом диске vs мощный комп с дофига всего запущенного, чтоли.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (79), 03-Мрт-20, 07:34
	Windows.
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

	104. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (104), 03-Мрт-20, 10:49
	> Windows. Так бы сразу и сказал, он при 50К файлов в дире встает колом на несколько минут, хоть там что. Но это ntfs так работает, там индексация если и есть - то на проволоке и скотче. Поэтому когда на холодную пытаетесь подчитать список на 50К позиций - ых, ых, ых, там нет индекса для быстрой выгрузки всех 50К :)
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 03-Мрт-20, 11:35
	> Поэтому когда на холодную пытаетесь подчитать список на 50К позиций дайте угадаю - вы не "список" пытаетесь, а в интуитивно-приятном эксплорере, которому на эти 50ке надо разобраться с типом файла и симпатичную иконочку к каждому пририсовать, если, конечно, дело ограничивается автоназначаемой, а не приходится еще и лезть внутрь, чтобы узнать, что же такое нарисовать этому юзеру. А индекс при линейном чтении помогает только в детских сексуальных фантазиях. У взрослых уже обычно есть понимание, что помочь он может только если точное имя файла уже откуда-то известно, и никакого перебора "50k" нет в помине. С этим у ntfs все хорошо, а вот у ext4 лучше не знать как оно коллизии разрешает. И да, ls без -F в линуксном каталожке на 50ке ненужно - тоже, мягко говоря, небыстр (и прожорлив, ему сортировать это все надо) - поэтому и  нехрен такие помойки устраивать, а потом лазить к ним  доступом с полным перебором содержимого, причем не только имен, а еще и дополнительной сложно извлекаемой информации.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 22:17
	> дайте угадаю - вы не "список" пытаетесь, а в интуитивно-приятном эксплорере, В FAR без иконок те же яйца. > еще и лезть внутрь, чтобы узнать, что же такое нарисовать этому юзеру. Красивая теория, но FAR плевал на иконки. > А индекс при линейном чтении помогает только в детских сексуальных фантазиях. Это зависит от устройства оного, однако. Есть 2 вида ФС: те которым пофиг на unordered bulk выгрузку списка и те которым не пофиг. Последние держат под такое какие-нибудь структуры из которых это можно эффективно отпедалить, первые шарахаются по всему диску, с понятным факапом перфоманса. > У взрослых уже обычно есть понимание, что помочь он может только если > точное имя файла уже откуда-то известно, и никакого перебора "50k" нет в помине. Это просто выгрузка списка диры. И таки те кто поумнее и кому не пофиг на перфоманс этот кейс вменяемо обыгрывают. В том числе и делая отдельные структуры на такой случай. > С этим у ntfs все хорошо, а вот у ext4 лучше не знать как оно коллизии разрешает. По времени чтения диры на 50К файлов я заметил, насколько там все офигенно. > И да, ls без -F в линуксном каталожке на 50ке ненужно - > тоже, мягко говоря, небыстр (и прожорлив, ему сортировать это все надо) Блин, в винде 50К файлов хоть там чем залистить занимает *минуты* если это "на холодную". Из кэша то быстро, но это уже не заслуга ФС, от слова вообще. А в линухе - там по разному, от ФС зависит. XFS с разлапистыми иерархиями вроде не очень, остальные - получше. В btrfs меня подобные вопросы не парили особо, во всяком случае - ну вот не помню туповэйтинга МИНУТАМИ. Единственное где я такие времена в линухе видел вообще - стирание сильно фрагментированых торентов на цать гигов на XFS :) > - поэтому и  нехрен такие помойки устраивать, а потом лазить > к ним  доступом с полным перебором содержимого, причем не только > имен, а еще и дополнительной сложно извлекаемой информации. Как бы если нужная информация "сложно извлекается" - это факап дизайна, гарантирующий хреновый перфоманс.
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 06-Мрт-20, 15:40
	> В FAR без иконок те же яйца. ну так это - проблема вашей фары , не? > Это зависит от устройства оного, однако. расскажите же, каким волшебным образом dirindex (особенно в ext4 реализации) участвует в получении _полного_ списка содержимого каталога. > Как бы если нужная информация "сложно извлекается" - это факап дизайна нет, это факап пользователя. Не понимающего, как правильно работать с помойками в 50k файлов (и вообще ухитряющегося их создать) - что при этом не надо генерить графические превьюшки всех пятидесяти и добывать из них exif с точной секундой съемки. Программы пишут для нормальных людей, у тех таких помоек нет, поэтому странно ожидать что они о тебе позаботятся.
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 07-Мрт-20, 07:15
	> ну так это - проблема вашей фары , не? Лично я вообще не смог найти проги где такой проблемы нет. > расскажите же, каким волшебным образом dirindex (особенно в ext4 реализации) участвует > в получении _полного_ списка содержимого каталога. Если есть индексированный и линейный варианты - последний в упомянутом случае логично и выдать, если он конденсированно лежит его можно быстро и крупным оптом выдать на гора. У NTFS походу какие-то сложности с таким развитием событий. Во всяком случае, я только что на холодную сунулся в ext4 на механическом диске с ~60К файлов в дире (если не больше) - и потер это. Ну, собссно, обычным миднайтом. Чего-то после этого сказ о крутизне винды и ее технологий как-то не убеждает, скорее верится тому прогеру который на реддите(?) ms рассказал почему винды тормозят относительно пингвина :) > нет, это факап пользователя. Угу, щас. > Не понимающего, как правильно работать с помойками в 50k файлов Балин, мистер умник, выгрузку делала прога и я не имел никакого контроля над тем как она это будет фигачить. > (и вообще ухитряющегося их создать) - Его прога автоматически слепила, это выгрузка была. А когда я заметил что места нет, надо бы стереть .. ух ты, простое действо оказывается все раком ставит и надолго. В лине я подобными иерархиями ворочаю (в т.ч. на механических дисках) в крейсерском режиме и не задумываюсь. > что при этом не надо генерить графические превьюшки всех пятидесяти Про превьюшки круто, но фар их не генерит, да и вообще, это были кастомные файлы, винды не умеют превью из них делать, для начала. > и добывать из них exif с точной секундой съемки. Чего, кого, откуда в кастомных файлах exif? И тормозящая фара тоже как-то этим всем не интересуется.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 10:46
	> По тому же почему нельзя заставить Linux не вешать систему при копировании > сотен мелких файлов на 8ми ядрах Чокаво? Я копирую целые деревья линукскернеля, сколько там мелких файлов посчитай сам. Явно не сотни, скорее десятки тысяч. И таки почему-то ничего не вешается.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

3. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–12 +/–
Сообщение от Аноним (4), 02-Мрт-20, 20:33
Обработчик нехватки памяти... Сейчас фиг найдешь кого-то, у кого ее меньше 8 гиг. В основном по 16 и выше. И шо, все равно не фатает? :(
Ответить | Правка | Наверх | Cообщить модератору

	6. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (6), 02-Мрт-20, 20:36
	Хром, вбокс и Де на гтк3, и всё, нету 8
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от Аноним (4), 02-Мрт-20, 20:38
	Ты не поверишь, но у меня 4, и я это все запускаю, раз в пару дней так точно. А, еще и ФФ открыт с тундрабердом.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от Аноним (4), 02-Мрт-20, 21:00
	>Хром, вбокс и Де на гтк3, и всё, нету 8 Ну ок, вот тебе slimjet (хром), vbox (с фотошопом даже) и DE на GTK3. Память - 4 гига. Внимание на память в коньках справа: http://0x0.st/ic45.png
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	30. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним84701 (ok), 02-Мрт-20, 21:29
	>>Хром, вбокс и Де на гтк3, и всё, нету 8 > Ну ок, вот тебе slimjet (хром), vbox (с фотошопом даже) и DE > на GTK3. Память - 4 гига. Внимание на память в коньках  справа: http://0x0.st/ic45.png И? 2 окна браузера по 3 вкладки c  Opennet и LOR. Виртуальный ящик с древней XP и не менее древней версией (пустого) фотошопа 7 (причем, емнип, виртуалка отжирает у системы только действительно задействованную память). И собственно все – 2.32 из 4 ГБ как корова языком. А если в виртуалке нужно будет запустить фотожоп свежее 18 лет (да еще и не просто для запуска вхолостую, а для обработки чего-то) и вместо лора в браузере открыть тройку вкладок "жирной" доки страниц на тыщу?
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от Аноним (4), 02-Мрт-20, 21:41
	Просил - получил, как говорится. Я к тому, что у меня есть еще в запасе для картинки в фотошопе и еще пары вкладок. Зачем их открывать 100500 - никогда не понимал. Дибилизм. Мне всего этого хватает с головой для работы.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним84701 (ok), 02-Мрт-20, 21:54
	> Просил - получил, как говорится. Чисто формально -- возможно. И? Я к тому, что древний фотошоп 2002 года с древней XP - не очень убедително выглядят. Обычно приходится запускать современный софт и то же приложение на электроне быстренько отожрет 600 мб под банальный чатик. А так-то я могу  откопать железку 2006 года с 2.5ГБ ОЗУ - там фотожоп 7 и XP тоже летать будет и пожалуй даже современный браузер на 10 вкладок запустить получится. И что, на основании этого можно будет смелао писать "2.5ГБ хватает всем для всего!"? > Я к тому, что у меня есть еще в запасе для картинки в фотошопе и еще пары вкладок. > Зачем их открывать 100500 - никогда не понимал. Дибилизм. Если это вкладки с ЛОРом или Опеннетом, то возможно и незачем. А вот если что-то другое, то переключаться между вкладками выходит быстрее, чем прыгать по странице прокруткой или поиском или задействуя закладки.  Но современные браузеры из-за современных методов отображения (оптимизированных под "вебприложения") жрут память даже на неинтерактивных страницах.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–2 +/–
	Сообщение от Аноним (4), 02-Мрт-20, 22:12
	>древний фотошоп 2002 года с древней XP Ты повторяешься. Я уже это читал. Мне ничего новее не нужно. Винда себе и винда, какая разница, лишь бы свои задачи выполняла. Фотошоп тоже, я и 50% его функционала не использую. Уверен, и ты тоже, лол. Короче, для работы достаточно. Ничего не виснет и не уходит в ступор, еще и свободная память есть, а ее всего 4 гига. Как-то так.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от zzz (??), 03-Мрт-20, 02:26
	А ты-то тут каким боком? С какого перепугу ты стал тем мерилом, чей набор софта и кол-во вкладок стали эталоном, по которому надо мерить остальные десктопы? Корона не жмет?
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от fske (?), 03-Мрт-20, 08:53
	>я и 50% его функционала не использую Ты математик или светлосиний?
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	134. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от fske (?), 03-Мрт-20, 13:45
	Это меня функционалы минусуют? ))
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (176), 04-Мрт-20, 02:48
	> Это меня функционалы минусуют? )) "тихо, сам с собою, правою рукою" //приключения Ларри МакЛаффера.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 03-Мрт-20, 07:46
	> Чисто формально -- возможно. И? top - 07:34:59 up 18 days, 11:00, 17 users,  load average: 0.22, 0.15, 0.14 Tasks: 125 total,   1 running, 124 sleeping,   0 stopped,   0 zombie Cpu(s):  4.4%us,  1.7%sy,  0.1%ni, 93.6%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st Mem:   3085136k total,  2665132k used,   420004k free,   348400k buffers Swap:  4194300k total,     6548k used,  4187752k free,   893704k cached   PID USER      PR  NI  VIRT  RES  SHR S   %CPU %MEM    TIME+  COMMAND         18322 user      20   0 1591m 752m  71m S     15 25.0 875:53.52 palemoon         1894 root      20   0  216m 202m 190m S      8  6.7   2240:08 X                 2012 user      20   0 15160 7684 5672 S      1  0.2  35:10.94 e16               24528 user      20   0 1124m 462m  63m S      1 15.4   3958:44 palemoon         2060 user      20   0  3608 1336 1060 S      0  0.0  13:02.43 asclock           3212 root      20   0     0    0    0 S      0  0.0   0:44.96 kworker/3:1       23499 root      24   4  2760 1124  840 R      0  0.0   0:00.02 top                   1 root      20   0  2212  620  592 S      0  0.0   0:14.53 init                 2 root      20   0     0    0    0 S      0  0.0   0:00.00 kthreadd         ну вот как-то так выглядит "работа" в тоже, конечно, немодном-несовременном (3.0.101, отсутствие "DE" и прочего трэша) линуксе с современным web (видишь второй palemoon? Нет, это не тред, это именно второй - потому что там aliexpress и online visa application, обе в старых версиях не откроются) Вкладки в pm "консервативные", то есть основной расход памяти будет если всю сотню по разику открыть, я этого не делаю, поэтому почти не мешают (их реально с полсотни, если не больше) Тут еще не видно десятка xterm'ов, часть с ssh, но они и не жрут на этом фоне ничего. Чятик на эшелоне, разумеется, уже бы не поместился, но он тут и не запустится, не поддерживает "мультиплатформенный-переносимый" гугломусор эту платформу. > А так-то я могу  откопать железку 2006 года с 2.5ГБ ОЗУ > - там фотожоп 7 и XP тоже летать будет и пожалуй > даже современный браузер на 10 вкладок запустить получится. И что, на не получится - не собирается современный под хепе. > Если это вкладки с ЛОРом или Опеннетом, то возможно и незачем. > А вот если что-то другое, то переключаться между вкладками выходит быстрее, чем > прыгать по странице прокруткой или поиском или задействуя закладки.  Но > современные браузеры из-за современных методов отображения (оптимизированных под > "вебприложения") жрут память даже на неинтерактивных страницах. это ты думаешь что она неинтерактивная, а worker'ы алиэкспресса думают, как бы что спереть у тебя еще не спертого. А еще в "подвале" сайта, где цопирайты  и неработающий мэйл владельцев, и до которого никто и никогда страницу не прокручивает, может быть "fog.jpg" на двенадцать мегабайт, размером 6000x4000.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	86. Скрыто модератором	+1 +/–
	Сообщение от fske (?), 03-Мрт-20, 08:50
	>никогда не понимал Вот это и называется "дибилизм", а не что ты там нацарапал.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	181. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (181), 04-Мрт-20, 09:41
	На Orange Pi PC2 гиг оперативы.При нехватки памяти ядро прибивает самый ненужный процесс. В моем случае это был ssh сервер. Следующий по ненужности оказался nginx. Это полный пи...
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	186. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 04-Мрт-20, 21:21
	> оказался nginx. Это полный пи... Ну, правильно, кто ж сейчас маны то читает и вес процессам для oom killer настраивает? :)
	Ответить | Правка | Наверх | Cообщить модератору

	205. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от kek (??), 05-Мрт-20, 08:41
	sshd имеет oom_score_adj=-1000 из коробки обычно
	Ответить | Правка | Наверх | Cообщить модератору

	220. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 07-Мрт-20, 07:17
	> sshd имеет oom_score_adj=-1000 из коробки обычно У того анонимуса это походу было не так.
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+2 +/–
	Сообщение от yaya (?), 02-Мрт-20, 20:39
	Да. Пишешь какую-то свою прогу, которая из-за ошибки ушла в бесконечный цикл по захвату памяти. Комп становится полностью нерабочим - все 8 гигов пытаются слиться на диск, чтобы дать достопочтенной проге дальше захватывать память. И ты такой сидишь, ждёшь когда появляются временные окна какой-никакой работоспособности и выходишь сначала в консоль по ctrl-alt-f1 (потому что X'ы уже всё, не отвечают), потом вводишь свои логины с паролями и кое-как вызываешь долгожданный kill - и всё это с большими перерывами по фризам, данные же всё льются и льются на диск.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	10. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (4), 02-Мрт-20, 20:41
	А можно спеки твоей машинки? А также в чем пишешь код и запускаешь? Интересно до жути.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от yaya (?), 03-Мрт-20, 13:49
	> А можно спеки твоей машинки? i3-2100 CPU @ 3.10GHz, 8 ГБ памяти, диск ST500DM002-1BD14 # cat /proc/meminfo | fgrep Swap SwapCached:         9176 kB SwapTotal:       8273916 kB SwapFree:        7804412 kB > А также в чем пишешь код vim >  и запускаешь? Эээ, mate terminal через команду ./a.out > Интересно до жути. Фирму мышки и клавиатуры не сказать?
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 22:52
	> SwapTotal:       8273916 kB Сэру никогда не приходило в бошку что вообще записать 8 гигз на механический диск - это не очень быстро? А ежели еще и 4К кусочками с достаточно рандомным доступом, ибо это эмуляция _RAM_ в которой никаких seek нет... :)
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от yaya (?), 04-Мрт-20, 20:28
	Вы не поняли суть проблемы? Проблема не в том, что я ожидаю, что 8 гигз свопаться будет быстро и всё будет летать. Проблема в том, что система ушла в полную неотзывчивость. Я бы с удовольствием бы прибил бы программу, которая начала своп грузить, но я не могу этого сделать, потому что нет отклика.
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 04-Мрт-20, 21:26
	> удовольствием бы прибил бы программу, которая начала своп грузить, но я > не могу этого сделать, потому что нет отклика. Да ну ладно, alt-sysrq-f это довольно быстро решает. Это ручной пинок oom killer, в свежих ядрах он достаточно метко гасит именно жиртрестов, а не те ужастики про которые пох рассказывает :D. А так без свопа, только zram на пару гигз + ssd под систему это примерно так: при runaway процессе все тупит секунд 5. Бдыщ. Runaway процесс пристрелен oom killer. И усе. Хотя, если вам нравятся тормозные лагучие системы, вы в вашем праве переть другими маршрутами и наслаждаться результатами, но вот ниоткуда не следует что это какое-то неотъемлимое свойство системы :)
	Ответить | Правка | Наверх | Cообщить модератору

	200. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от iPony129412 (?), 05-Мрт-20, 06:41
	> ну есть же ручка - дёргайте за неё! Ну как бэ по нормальному ОС сама должна как-то реагировать. Я уж про клавишу sysrq из прошлого молчу. Не у каждого есть. А можно ещё линуксовому десктопу этак отдельный отладочный интерфейс приделывать и другой компьютер рядом ставить, чтобы он первый зависший вытаскивал по этому интерфейсу. Во как придумал 👍
	Ответить | Правка | Наверх | Cообщить модератору

	221. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 07-Мрт-20, 07:24
	> Ну как бэ по нормальному ОС сама должна как-то реагировать. Так она и реагирует. Просто в зависимости от кофигурации и настроек это может быть не сразу. > Я уж про клавишу sysrq из прошлого молчу. Не у каждого есть. У мну она есть и на десктопе и на лаптопе. На планшете ее конечно хрен нажмешь, но, знаешь, даже у эппла в этом случае ты таки пролетаешь и разве что poweroff долгим зажимом "power" может прокатить. И то молитесь чтобы power manager это хардварно умел, а то с завинченным в девайс акумом и одуревшей системой очень прикольно выглядит, хе-хе. И даже твой любимый эппл умеет отжигать в таком плане - лично видел это под офигевшие писки хомячков. > Во как придумал 👍 Да это не ты придумал, это ты с тормоза снялся. Вон там отладка по uart, вместе с отправкой BREAK в роли SYSRQ и kdb/kgdb на всем чем можно + jtag, которому вообще на живость софта плевать. Как и дебагсерверу в qemu. Так можно даже в останках совсем дохлого кернела покопаться, актуально тем кто пытается понять "а чего это он сдох?" :)
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от YetAnotherOnanym (ok), 02-Мрт-20, 21:14
	> чтобы дать достопочтенной проге дальше захватывать память Вы хотите сказать, что ОС, которой скоро будет тридцать лет, до сих пор не имеет средств для разруливания такой ситуации?
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	29. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+2 +/–
	Сообщение от Аноним (-), 02-Мрт-20, 21:27
	Не имеет, я полностью подтвержаю слова автора. Спека моей машины - Ryzen 7, 32 гига ОЗУ. При копировании десятков гигов система может повиснуть, точнее курсор мыши будет двигаться, а кликнуть нельзя ибо система не отвечает.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (4), 02-Мрт-20, 21:44
	>Ryzen 7, 32 гига ОЗУ >При копировании десятков гигов система может повиснуть Честно, не понимаю. Это Linux настолько *не готов для десктопа* что ли? Тогда это печаль, серьезно. P.S. Опеннет посчитал слово shtole (на русском) неприемлемой лексикой. Ахаха.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–4 +/–
	Сообщение от Аноним (-), 03-Мрт-20, 01:40
	А ты часто копируешь дксятки гигов с одного винта на другой или на тот же самый? От ответа на этот вопорос зависит твоя точка зрения готов ли Linux для десктопа или нет.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+3 +/–
	Сообщение от zzz (??), 03-Мрт-20, 02:28
	А что это за отмазки пошли? Типа, раз нечасто - то какбе и нет проблем?
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от Аноним (68), 03-Мрт-20, 05:35
	У меня периодически бывает такое. Линукс встаёт колом, да.
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	108. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 11:05
	> У меня периодически бывает такое. Линукс встаёт колом, да. Hint: выдели под данные отдельные диски. А систему лучше на быстрый SSD. Своп выключить. Если RAM все же надо больше - zram заюзай. А теперь попробуй такую ракету вообще хоть чем-то заякорить. Ну, в общем, используемую систему и ее особенности стоит знать. Обходя баги и юзая фичи, тогда будет хорошо :)
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 03-Мрт-20, 15:34
	а как он их скопирует-то на отдельные, если оно - виснет. И у меня ощущение что виснут как раз быстрые системы. У них что-то умудряется выполниться слишком быстро и встать в дидлок. Медленные - медленно и печально копируют.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (159), 03-Мрт-20, 22:21
	> а как он их скопирует-то на отдельные, если оно - виснет. В смысле, у него именно, натурально, deadlock в ядре? Из которого оно не выходит? Или таки всего лишь временный тупняк? > И у меня ощущение что виснут как раз быстрые системы. У них > что-то умудряется выполниться слишком быстро и встать в дидлок. Медленные - > медленно и печально копируют. На быстрой машине активно что-то делающей может быть вероятнее выиграть какие-нибудь редкие гоночки, которые так кусались бы раз в 5 лет, а так уже раз в неделю :). Но вот это в общем то редкость и обычно случается только под извращенскими штукамаи типа XFS tools каких, у разработчиков, конечно.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (159), 03-Мрт-20, 22:23
	ЗЫ еще кстати очень помогает собрать себе full preempt кернель. Я это практикую давно, не заметил никаких факапов от этого - и таки вохможность выпереть кернель с проца во время длительных операций это хорошо и правильно. По неизвестным мне причинам даже десктопные дистры юзают как максимум компромиссные настройки. Даже в "realtime" ядрах. Не знаю с чем связано, может им 2% в бенчмарках важнее user experience'а :)
	Ответить | Правка | Наверх | Cообщить модератору

	201. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от iPony129412 (?), 05-Мрт-20, 06:47
	> Hint Не поможет - проходили.
	Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

	222. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 07-Мрт-20, 07:25
	> Не поможет - проходили. В смысле - не поможет? Я вон не обломался тест от чувака запустить. И oom killer вышиб его шляпу за 5 секунд, даже плеер заткнуться не успел.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (4), 02-Мрт-20, 21:45
	Так, стапэ! А если это сервак, гоняющий файло? Там что, тоже нельзя копировать десятки гигов теперь? :(
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	53. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 01:39
	Как давно на серваке есть ГУЙ? Вообще хрен знает, что будет но у меня при копировании 40 гигов даже видео через youtube подвисало на минуту или типа того или если у VLC нажать паузу то потом видео заново не запутсить пока всё не скопируется.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от Аноним (-), 03-Мрт-20, 01:49
	И ещё самый прикольный прикол забыл сказать, если копировать эти несколько десятков гигов с винта на винт или на тот же самый винт то через несколько минут перестаёт работать сеть. Например торрент качалка не может качать и т.п. Похоже, что ядро просто не успевает обрабатывать сетевуху (прерывания или обработчики прерываний и т.п.) и она ничего не принимает и не посылает.
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	161. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 22:32
	> то через несколько минут перестаёт работать сеть. Например торрент качалка не > может качать и т.п. Это надо ping или подобным проверять, а не торенткачалкой! С торенткачалкой может быть так что та встрянет тряпочкой на файловом IO, кернел вкалывает, прога висит в сисколе, если тот тормознутый, а качалка не выносит это в отдельный тред или какое там асинхронное IO - ну тогда до работы с сетью дело дойдет не скоро. На вид больше похоже на качественный затык дискового IO, вероятно, здорово фрагментированный файл, на механическом диске.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от iPony129412 (?), 03-Мрт-20, 07:39
	> Не имеет, я полностью подтвержаю слова автора. Спека моей машины - Ryzen 7, 32 гига ОЗУ. При копировании десятков гигов система может повиснуть Ну это же линукс. https://askubuntu.com/questions/1212212/how-to-copy-12gb-fil... Труе линуксоид в таких ситуациях пойдёт на баше писать скрипт копирования с использованием чанков, сплитов, синков и прочего. Он же не пользователь-ламер Windows который файлы мышевознёй в один клик без проблем копирует.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	89. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от fske (?), 03-Мрт-20, 08:58
	>Windows >файлы мышевознёй в один клик без проблем копирует Я так и знал, что больше она ни для чего и не нужна
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (104), 03-Мрт-20, 10:53
	> Он же не пользователь-ламер Windows который файлы мышевознёй в один клик без > проблем копирует. А если файлов 200 - то и кликов у мышевозилы получается 200 :). А копировать иерархию размером например с линукскернел под виндой - а вы это попробуйте вообще, как раз и расскажете как это все "не тормозит". Про то что вы cp --reflin там не сможете думаю и ежику понятно, так что иерархия займет место второй раз, даже если почти идентична первой :)
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	112. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от iPony129412 (?), 03-Мрт-20, 11:18
	> А копировать иерархию размером например с линукскернел под виндой - а вы это попробуйте вообще, как раз и расскажете как это все "не тормозит" Ну так делал. Ничего особенного не заметил.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 22:32
	> Ну так делал. Ничего особенного не заметил. Угу, кроме времени этой операции. В линухе это как-то резвее.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 03-Мрт-20, 12:19
	> А копировать иерархию размером например с линукскернел под виндой - а вы это попробуйте вообще а в чем проблема, я именно ей lizardfs тестирую? Да, из под винды, меня ее драйвер интересует, а не линуксный.
	Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

	163. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 22:33
	> а в чем проблема, я именно ей lizardfs тестирую? Не то чтобы вот прям проблема, но после линуха время такой операции как-то анноит :)
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от пох. (?), 03-Мрт-20, 12:16
	> Он же не пользователь-ламер Windows который файлы мышевознёй в один клик без проблем копирует. ты точно прочитал, что тот хмырь и _куда_ копировал? Он пытался слить 12гиговую порнушку с компьютера, где памяти половина от того, на ведроидофон, подключенный каким-то череззадничным методом, ни разу не как внешний usb-диск, поскольку гугль решил что это немодно. (не знаю что такое "camera" и знать не хочу) Дай угадаю - оно как "диск" у него видится исключительно с помощью gvfs. Поэтому весь файл сначала пытается положиться в буфер кривой гуглософтины, которая еще, наверняка, и кэшировать его пытается, а потом - софтина может быть, когда-нибудь, начала бы его поблочно выкладывать в телефон - но до этого, кажется,даже и не дошло. Уверен, что под вендой перкрасной у тебя мышеклики не приведут к тому же самому? тру-линуксоид хотя бы и не понимая, что, собственно, происходит (где ему разницу между gvfs и нормальной fs понять) - нашел решение проблемы. А у тебя - винда повиснет. P.S. почти так же работает, к примеру, davfs2-fuse. К счастью у нее кэш - файловый. Поэтому при попытке скопировать на dav-шару файлик больше чем места в /var- кончается место в /var ;-) Потому что луц по частям не продается, и чтобы сохранить файлик на dav - надо иметь файлик, а не поток байтов.
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	127. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от iPony129412 (?), 03-Мрт-20, 12:31
	> ты точно прочитал, что тот хмырь и _куда_ копировал? Дай угадаю - оно как "диск" у него видится исключительно с помощью gvfs. Да, читал. В первую очередь про косяк в GVFS подумал. Это просто демонстрация принципа. > Уверен, что под вендой перкрасной у тебя мышеклики не приведут к тому же самому? Ну почти да. Хотя проверять не на чем... Секрет же элементарен - просто гораздо больше отработанный юзеркейс. Вот и всё.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 03-Мрт-20, 12:41
	> Да, читал. В первую очередь про косяк в GVFS подумал. это не в gvfs косяк, это кого надо косяк, его брать не полагается. gvfs просто делает что может - имитирует файловую систему на том, что не является дисковым устройством даже приблизительно. Оно ж не блочное, а файловое. > Секрет же элементарен - просто гораздо больше отработанный юзеркейс. 12G порнухи НА телефон, а не с телефона - это вряд ли популярный юзкейс, нормальный юзер выложит их в гуглоклауд, а эти, линуксоиды, вечно никаквсе.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от iPony129412 (?), 03-Мрт-20, 12:54
	> это не в gvfs косяк Да не суть в чём косяк, просто в линуксах это сделано через одно место. Ну как было проще, так и это самое. В принципе работает. А так классика - выстроил цепочку из компонент, вроде результат плохой, так и никто не виноват... https://www.youtube.com/watch?v=heUq31_Zyd0
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 23:05
	> Да не суть в чём косяк, просто в линуксах это сделано через одно место. Да оно у всех сделано хрен знает как. Там какой-то чудесатый протокол. И на винде например я натыкался на то что фоточки с телефончика вроде бы даже и копируются. Но на половине почему-то оказываются пейзажи марса. Ну вот как-то девайс и конкретный патч конкретной винды видимо не нашли общего языка, но наружу сделали вид что все зашибись. А узнать об этом можно только опосля, попробовав скопированное посмотреть. И горе тому кто поленился это сделать сразу...  (и наверное такое западло похуже всего лишь тормозов, ибо ведет к профакиванию фот)
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от yaya (?), 03-Мрт-20, 14:33
	> Вы хотите сказать, что ОС, которой скоро будет тридцать лет Вы, наверное, имеете в виду ядро Linux, а не ОС... > до сих пор не имеет средств для разруливания такой ситуации? Вы меня спрашиваете? Я - пользователь ОС. Я получил плохо-отзывчивую систему в определённой ситуации. Вот пример, который уводит мою систему во фриз: ``` #include <stdint.h> #include <stdlib.h> int main() {     while (1) {         uint64_t *buf = malloc(1024 * 1024 * 1024);         if (buf != NULL) {             for (int i = 0; i < 1024 * 1024 * 1024 / 8; i += 4096 / 8) {                 buf[i] = 0;             }         }     }     return 0; } ```
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	164. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 22:34
	Пардон за глупый вопрос, а memset ща не модно? Или с ним уже не то?
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от yaya (?), 04-Мрт-20, 20:30
	Вы невнимательно прочитали код. Там не делается memset. Там просто тупо трогается страница, чтобы ядро её выделило физически. Если бы не было записи (или чтения) никакой страницы физически выделено не было бы и malloc бы спокойно себе отработал бы до какого-то момента и всё на этом, никакого бы свопа не началось бы. А так, если физически начать трогать страницы, то начинает включаться своп и я получаю систему без какого-либо отклика - только диск шуршит себе и никого не хочет слушать.
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 05-Мрт-20, 01:47
	> Вы невнимательно прочитали код. Там не делается memset. Там просто тупо трогается страница, А, пардон, не обратил внимание что это 1 раз на 4096, так явно резвее. > чтобы ядро её выделило физически. Я в курсе этой механики и прочих overcommit'ов и проч, все же свою систему следует знать :)
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 05-Мрт-20, 01:58
	> Вы невнимательно прочитали код. В качестве компенсации за тупняк: 1) Компил именно этого кода с -O2 довольно фиговая идея, настолько оптимизируется что потом вообще не жрет память :) 2) $ time ./memhog Killed real    0m4.627s user    0m1.432s sys    0m3.139s Итого? Умер за 4.6 секунды, расстрелян из реактивного г@вномета oom_killer'ом. В процессе даже плеер с музоном не икнул. Приветы поху и прочим великим системщикам :). Я все же посчитаю что умею готовить пингвинов получше этих :)
	Ответить | Правка | К родителю #185 | Наверх | Cообщить модератору

	91. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от rshadow (ok), 03-Мрт-20, 10:05
	В консерватории, пробовали править? Нахрена вообще на современной тачке нужен своп на диск? Уменьшать жизнь ssd? Хочешь своп, ну zram настрой что-ли. Закинь туда метров 500 и забудь. Раз уж 2т.р. на еще планочку жалко. Браузер сожрал всю память? Напиши 10 строк конфига для cgroups и жестко прибей ему 4 гига. Больше он никого не повесит.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	96. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+2 +/–
	Сообщение от пох. (?), 03-Мрт-20, 10:25
	угу, модно, молодежно, современно - браузеру четыре гига, почтовику два, чятику шесть, а этому - не дала, потому что больше нету, надо еще планочку памяти. И все прибивать гвоздиком. RSX11, последние версии - 1982го года. Там примерно так и было принято. Только вот это была - RT OS, и память там выделяли чтоб получить предсказуемое время реакции, а не потому что по другому не умела. Но потом это всех затрахало, и кто мог - спер unix6, а кто не мог - вынужден был переизобретать его.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от rshadow (ok), 03-Мрт-20, 12:16
	Путаешь гарантии с ограничением. Считай что это ООМ который ты сам настроил для конкретного процесса.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 03-Мрт-20, 12:22
	> Путаешь гарантии с ограничением не, не путаю. Гарантии - это было понятно, для чего и почему так и надо. Но настолько неудобно, что предпочли медленнее и без гарантий, но и без ручного траходрома с резервированием памяти под редактор, как только железо стало чуть попроворнее. А ограничения вручную расставлять, чтобы процесс схлопнулся даже если на самом деле память была, потому что если ее не окажется, он тебе все разнесет - это маразм.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от rshadow (ok), 03-Мрт-20, 12:44
	Маразм это в идеальной вселенной с розовыми пони. А здесь у нас есть пара жрущих не в себя приложений. Работают они хорошо, просто немного подтекают. Рестарт на лимите это стандартная практика, даже для серверного ПО. там правда рестартят форки обработчиков, а не все приложение. Но унас тут гуй, так что без выбора. P.S. Неконструктивная критика - критика без предложений исправить. Бессмысленна, беспощадна и ничего не изменит. Просто нытье...
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 03-Мрт-20, 12:56
	> Неконструктивная критика - критика без предложений исправить. ну щас все брошу и пойду еще линукс за вас чинить. Во фре кое-кто пытался исправить, я поучаствовал, в меру возможностей. Ну как-то не особо хорошо закончилось. Как не отдавала память, так и не отдает. notabug.
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 05-Мрт-20, 02:02
	> ну щас все брошу и пойду еще линукс за вас чинить. На, откушай, мегасистемщик, бэть: https://www.opennet.me/openforum/vsluhforumID3/119943.html#193
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от ДавноСидим (?), 03-Мрт-20, 12:26
	Насколько я помню, RSX-11(как M, так и S) все же не притворялась, что она realtime. Для этого у Digital была RT-11 Хотя это к основной теме никак не относится.
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	130. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 03-Мрт-20, 12:50
	она не притворялась, она ей - была. Даже, кажется, параметры этого рилтайма где-то были детально расписаны, с допустимыми временами обработки. rt11 вообще сложно назвать полноценной операционной системой, она недалеко ушла от "дос с резидентной программой [одной]". Разьве что совсем поздние версии, которых я уже не застал, за ненадобностию на больших машинах и неработоспособностью на мелких.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от yaya (?), 03-Мрт-20, 14:14
	> В консерватории, пробовали править? В консерватории? Не, не пробовал. У меня стационарный компьютер, в консерваторию идти со всем компьютером как-то накладно, да и то не пустят поди. > Нахрена вообще на современной тачке нужен своп на диск? Я не знаю, по дефолту установщик предлагает swap. > Уменьшать жизнь ssd? У меня нет ssd :( > Хочешь своп, ну zram настрой что-ли. Зачем? Может проще earlyoom поставить? > Закинь туда метров 500 и забудь. Раз уж 2т.р. на еще планочку жалко. Как прога, которая просто тупо съедает всю память (из-за логической ошибки), внезапно перестанет съедать всю память и тормозить всё систему? Дополнительная оперативка поможет в этой ситуации? > Браузер сожрал всю память? Напиши 10 строк конфига для cgroups и жестко прибей ему 4 гига. Больше он никого не повесит. Машина взрывается от перегрева? Ну поставь доп. охлаждение. В чём проблемы-то? Или всё-таки поставить earlyoom как-то проще, раз штатно это никак не разруливается?
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	153. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (153), 03-Мрт-20, 18:27
	Да вроде виснут те у которых при нехватки памяти файл подкачки или раздел подкачки на HDD. Но вариант так себе размещать подкачку на SSD, привык, что на Win ssd ненужен для файла подкачки чтобы не завыиснуть опер. системе. Но пришлось купить SSD под раздел подкачки. SSD для этого и был куплен. OC на HDD.
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	154. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (153), 03-Мрт-20, 18:34
	Нет я не о том, что мне жалко износа SSD под подкачку использовать, пока не жалко.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 22:36
	> Нет я не о том, что мне жалко износа SSD под подкачку > использовать, пока не жалко. В линухе можно zram поюзать. Будет такой себе сжатый RAM для малоактивной фигни. Весьма годная штука - скорость работы все же ближе к оперативе чем к диску.
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 04-Мрт-20, 08:42
	Моё мнене на моём опыте. Zram хорош это если много памяти. А если 2 - 4ГБ не сильно поможет. Zram это отсрочивание момента когда файл подкачки в памяти заполнится ( zram ) и начнётся использоватся подкачка на диске.
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 04-Мрт-20, 08:49
	Вариант без подкачки я не расматриваю по тому, что когда нет памяти и нет подкачки зависнет. Сейчас совет от меня из моего опыта такой или не заполнять полностью память или иметь подкачку на SSD. И ядро последнее судя по обзорам на ядро, работу с подкачкой и памятью вроде улучшают. Имея подкачку на диске советуют лучше использоват zswap, а не zram.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 04-Мрт-20, 09:17
	Кстати если фал подкачки на диске заполнится тоже зависнит. Было у меня таке.
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 04-Мрт-20, 09:21
	Только у меня не файл подкачки, а раздел подкачки. Путаю раздел с файлом подкачки на Win привык, что на Win. это файл подкачки. Как работает файл подкачки в Linux я незнаю не когда им не пользовался только раздел подкачки раздел мне удобние.
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 04-Мрт-20, 21:34
	> Моё мнене на моём опыте. Zram хорош это если много памяти. А если памяти мало, это не хорошо, а просто офигенно :). Потому что в сжатый "своп" выжмется все что не используется активно - и расчистит от своего присутствия изрядно Немедленно Доступной оперативы - которой остальные смогут пользоваться для чего нибудь полезного. А когда (и если) это редко используемое все же где-то потребуется - декомпреснуть страницу из zram, особенно lz4 какой - это намного быстрее чем винтом шуршать. И такое по этому поводу практикуют для роутеров-мыльниц хде 32 мега на все, и одноплатников, где обычно что-то типа 256Мб...2Гб. > А если 2 - 4ГБ не сильно поможет. Zram это отсрочивание момента > когда файл подкачки в памяти заполнится ( zram ) и начнётся > использоватся подкачка на диске. Попробуйте посмотреть на это под другим углом: это сжатие редко используемых страниц и околореалтаймная распаковка если вдруг потребовалось. Просадка скорости от распаковки, конечно, будет, но это не идет ни в какое сравнение с механическим винчом...
	Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

	14. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+2 +/–
	Сообщение от Аноним (11), 02-Мрт-20, 20:46
	И 8GB забить сложно, да. И 16, да. Нельзя нечаянно запустить пару виртуалок и поставить систему колом. И прямо сейчас на citilink нет уймы ноутов с 4GB памяти. Или например, есть такой баг: https://bugzilla.kernel.org/show_bug.cgi?id=201673 на который разрабам ядра по фигу. Когда уже гнилые отмазы закончаться у Линукс фанатов? Если ОС такая идеальная, то почему она может раком вставать даже на "поддерживаемом" "православном" оборудовании? // b.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	16. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–2 +/–
	Сообщение от VINRARUS (ok), 02-Мрт-20, 20:47
	> у кого ее меньше 8 гиг. В основном по 16 и выше. И шо, все равно не фатает? :( Не фатает. Ядро упоротое просто и хоть 1 Тб оперативки ему дай всё равно будет не работоспособно полностью без swap.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	20. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от Аноним (11), 02-Мрт-20, 20:56
	> Ядро упоротое просто и хоть 1 Тб оперативки ему дай всё равно будет не работоспособно полностью без swap. К слову сказать, я работаю без SWAP что на Windows, что на Linux уже лет 15 и не имел по этому поводу ни одной проблемы. Так что не стоит выдумывать. // b.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от VINRARUS (ok), 02-Мрт-20, 20:58
	И как твой Linux себя ведёт при свободных 10 Мб?
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (11), 02-Мрт-20, 22:04
	ХЗ, у меня сейчас 64GB - пока меньше 20GB не удалось достичь :D Больше всего забивает память 7z со словарём 1.5GB и виртуалки (я диски виртуалок выношу в ... оперативную память, чтобы быстрее пахало).
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (4), 02-Мрт-20, 23:13
	Можешь поделиться рецептом выноса дисков виртуалок в оперативку? Спасибо.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (49), 03-Мрт-20, 00:23
	Так cp -a ~/VirtualBox/VM\ Name /tmp /tmp ессно примонтирована в tmpfs (по крайней мере во многих свежих дистрах так). Если нет, то tmpfs                                     /tmp          tmpfs defaults,nosuid,nodev,seclabel,size=75% Но это очень много рамы нужно. 75% на 64GB - это 48GB. Поосторожней! Если у вас всего 16, то больше 50%, наверное, под tmpfs не стоит выделять. Из-за бага в ядре можно систему положить напрочь за пару секунд (баг я выше привёл) - ядро tmpfs считает чем-то, что нельзя из памяти убирать. // b.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (65), 03-Мрт-20, 04:04
	И правильно считает.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (67), 03-Мрт-20, 05:31
	> К слову сказать, я работаю без SWAP что на Windows, что на Linux уже лет 15 и не имел по этому поводу ни одной проблемы. Так что не стоит выдумывать. … > Поосторожней! > Из-за бага в ядре можно систему положить напрочь за пару секунд (баг я выше привёл) - ядро tmpfs считает чем-то, что нельзя из памяти убирать. Как-то быстро спалился :))) Куда убрать-то? :)))
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	75. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (75), 03-Мрт-20, 07:14
	Убрать из памяти. tmpfs - это модуль ядра, а не процесс, поэтому память, которую он съедает, ядро считает своей собственной и высвободить не может.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Секция башенного крана (?), 03-Мрт-20, 08:25
	tmpfs - это файловая система, которая может быть очищена.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (85), 03-Мрт-20, 08:25
	Он не ведает о чём говорит.
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	31. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 02-Мрт-20, 21:29
	Наоборот, со свапом система не работоспособна при утечки памяти, просто перестаёт отвечать, а без свапа процесс потребляющий больше всего памяти будет убит OOM Killer, такой опыт.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	41. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (41), 02-Мрт-20, 22:22
	Ну вот к примеру я пишу программы для микроконтроллеров(разных). Открыл FF для справки вкладок 40, открыл vscode для esp, открыл Atollic truestudio для stm, поставил influxdb и grafana для тестирования прошитых датчиков. Все 8 гигов на рабочем ноутбуке с linux как не бывало. Система на гиг в свопе. Но даже если было бы 16 все равно отсрочка на 2-3 дня,прежде чем поделия на eclipse и electron/nodejs сожрут доступную память. А еще иногда ковыряю pic (у них своя среда тоже на базе eclipse) и Arduino. Не говоря уже что большую часть времени пишу на Go, но liteide по сравнению с остальными почти ничего не ест. Кстати не особо этот earlyoom и помогает. Для себя выработал такое решение: 1. При первых признаков тормозов. Грохнуть FF (он у меня дополнительно в firejail). 2. Избавиться от свопа: cat ./clear_mem.sh #!/bin/sh echo 3 > /proc/sys/vm/drop_caches swapoff -a && swapon -a 3. Запустить FF, он восстановит открытые вкладки, но жрать под них память перестанет пока ты к ним не обратишься. Хром не предлагать с ним тоже самое по памяти. Но к FF у меня есть хорошая подборка расширений для удобства работы.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	66. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от iPony129412 (?), 03-Мрт-20, 04:37
	> Сейчас фиг найдешь кого-то, у кого ее меньше 8 гиг. На ноутбуке одну вещь србирал. 8 ШБ ОЗУ, чего-то бомбануло и 16 ГБ заняло. Страшно подумать, если бы линукс был бы 😮
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	76. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Секция башенного крана (?), 03-Мрт-20, 07:16
	Собирать опасно без юзерспейсных обработчиков. Но так как обработчики есть и широко используются желающими, то и проблемы нет. Федора начиная с 32 будет поставляться с юзерспейсными обработчиками, например.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 11:03
	> Страшно подумать, если бы линукс был бы 😮 Да то же что и на винде. Можно подумать, кто-то смог отменить тот факт что эмулировать винчом оперативку дико тормозно. Ну, нажал alt-sysrq-f - гамнюк получит по рогам. Это сильно быстрее чем пытаться в гуйном таскманагере в истошно тормозящей системе понять кто там вообще память сожрал. Так и скажи что ты просто не умеешь линем пользоваться, включая шустрый отстрел runaway программ :)
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	111. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от iPony129412 (?), 03-Мрт-20, 11:13
	> Да то же что и на винде. Не. Там всё будет жёстко тормозить, но хоть как-то реагировать. То есть если не психованный, то можешь вывести компьютер из этого положения без удара ногой по кнопке ресет на корпусе. С линуксами бесполезно. > Так и скажи что ты просто не умеешь линем пользоваться Возможно и можно как-то настроить, и так далее... Но не имею желания - проще ОЗУ закидать.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 04-Мрт-20, 21:41
	> С линуксами бесполезно. Ну вообще-то в моей конфиге я даже alt-sysrq-f не успеваю обычно бабахнуть, oom killer приходит раньше :). И при этом хотя у меня и "нет свопа", неиспользуемые станицы В СЖАТОМ ВИДЕ выталкиваются в zram, расчищая больше оперативки тем кто ей активно пользуется. Что как бы хорошо и правильно. А в винде вообще аналога этой клевой технологии просто нет. > Возможно и можно как-то настроить, и так далее... Но не имею желания Да я вон выше написал как. > - проще ОЗУ закидать. Не гарантирует отсутствие тупняка при runaway. В отличие от того что я написал, где у меня система тупит секунд 5, после чего oom killer выносит жиртреста и вообще делать ничего не надо :)
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от iPony129412 (?), 05-Мрт-20, 06:31
	> А в винде вообще аналога этой клевой технологии просто нет. Этой что ли? https://www.howtogeek.com/319933/what-is-memory-compression-.../
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 03-Мрт-20, 12:25
	Ну, нажал alt-sysrq-f - прибил свой DE. Ну а заодно все что имело несчастье открыть на ем окошко, потому что вся гуйня порестартилась следом. Поправил, не благодари.
	Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

	166. Скрыто модератором	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 22:39
	> Ну, нажал alt-sysrq-f - прибил свой DE. Ну а заодно все что > имело несчастье открыть на ем окошко, потому что вся гуйня порестартилась следом. На 2.6.32.чототам - наверное оно как-то так даже и работало. А ща это обычно выносит самую жирную задачу. В вменяемых дистрах к тому же доперли вес процессам затвикать - желание OOM killer вынести процесс видите ли настраивается. Даже Гарри Поттер допер своим процессам сие поправить, и если ВетеранЮниксМаздайцы тупее даже него - ну я тут не виноват :D > Поправил, не благодари. WORKSFORME :P
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 22:55
	На 2.6.чототам - наверное оно как-то так и работало. А ща это обычно выносит самую жирную задачу. В вменяемых дистрах к тому же доперли вес процессам затвикать - желание OOM killer вынести процесс настраивается. Даже Гарри Поттер допер своим процессам сие поправить, однако.
	Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

	92. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (92), 03-Мрт-20, 10:12
	Достаточно одного тяжёлого запроса в постгре на десктопе, чтобы вспомнить где находится кнопка ребута или sysrq.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

5. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–4 +/–
Сообщение от бублички (?), 02-Мрт-20, 20:36
"sysctl -w vm.swappiness=1" ну и памяти докупить пропорционально задачам, и никакие костыли не понадобятся
Ответить | Правка | Наверх | Cообщить модератору

	9. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–2 +/–
	Сообщение от Аноним (4), 02-Мрт-20, 20:40
	*на ушко*: swappiness уже давно ничего не решает. А вот память - да. Здесь я согласен. Сидят нищ*броды и ноют, что не хватает им памяти, видишь ли.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+2 +/–
	Сообщение от Секция башенного крана (?), 03-Мрт-20, 06:47
	Решает, но не так, как думают ретартды.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (92), 03-Мрт-20, 10:13
	Я пробовал все возможные значения сваппинес и становилось только хуже. Объясни как влияет.
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Антон (??), 04-Мрт-20, 14:33
	Поехавшие рекомендуют уменьшать свопинес. На самом деле это приводит к замедлению своппинга и io операций при исчерпании памяти. Либо ставьте свопинес выше 10, либо вообще отключайте своп нахрен. Худший вар - большой свопспейс и очень гизкий свопинес - если запустится мем бомба, то своппинг будет катастроастрофически медленным и долгим.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от cat666 (ok), 02-Мрт-20, 20:43
	Как вы задолбали с этим swappiness. Никогда того не было и вот опять. Вы для начала разберитесь что этот параметр делает, а потом пишите всякую чушь. Для просвещения https://www.howtogeek.com/449691/what-is-swapiness-on-linux-.../
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	19. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–2 +/–
	Сообщение от Аноним (11), 02-Мрт-20, 20:53
	А зачем фанатам знать мать часть? Они на то и фанаты. Это как верующие, подавляющее число которых никогда библию от начала и до конца не читало. Так же и Линукс/Windows/MacOS/фанаты in general. Они выдумают себе идола и носятся с ним. Вроде никому за это не платят, ан, нет, хочу быть в своём tribe'е - это же так уютненько быть окружённым людьми с таким же отклонением. r/AMD r/linux - лютое тому подтверждение. Такие умилительные сопли по поводу каждого "достижения". Вышла новая софтина взамену этой Windows программы - миллион upvotes, даже если Linux программа имеет 0.1% возможностей. r/AMD: "я сегодня собрал целиком полностью систему на AMD" - триллион лайков. Все стоят на коленях и молятся за Lisa Su. Это просто отвратительно. Я ничего не понимаю в этом мире. Зачем преклоняться кому-то или чему-то? Есть разные системы с разными недостатками. Быть разумным - это всё это видеть, а не писать бредятину вида "вы купили неправильное оборудование для Линукса". Кому вообще сдался Линукс, если ему нужно специальное оборудование? // b.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от Аноним (58), 03-Мрт-20, 02:21
	Так редит уже как двач стал, только неанонмный, естессно там фанбоев полно.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от iPony129412 (?), 03-Мрт-20, 06:25
	> Так же и Линукс/Windows/MacOS/фанаты in general. Они выдумают себе идола Да как-то среди Windows и MacOS не особо. Особенно первые так и вообще только так матом покрою разработчиков, если у них на васян репаке что не заработает 😀
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	106. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 03-Мрт-20, 10:59
	> Это как верующие, подавляющее число которых никогда библию от начала и до конца не читало. "Без разбору позволять неискусным чтение Св. Писания тоже значит, что и младенцам предложить употребление крепкой пищи" это, если что - _православное_ мнение (по факту пересказ решения собора 17в). У католиков все гораздо проще - там периодически не то что читать, держать дома запрещалось (потому что начитаются под одеялом, и давай друг-другу глотки резать - то есть у них основания были не теоретические, а по факту уже случившихся полных п-цов) Истиная вера не нуждается в чтении "от начала и до конца". > Есть разные системы с разными недостатками. да, например, в сферическом вакууме - вообще ни одна не работает > Быть разумным - это всё это видеть, а не писать бредятину вида "вы купили неправильное > оборудование для Линукса". ну вот вы разума не демонстрируете > Кому вообще сдался Линукс, если ему нужно специальное оборудование? кому линукс сдался, тем и сдался. Оборудование выбирается под задачу - не, не слышал? Ну тогда и Библию не трожь, а иди, вон, в специальное учреждение, в положенное время положенный специалист тебе ее прочтет - так и то, что положено. Слушать - можно, и для спасения души полагается весьма пользительным.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	110. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 11:10
	>> Есть разные системы с разными недостатками. > да, например, в сферическом вакууме - вообще ни одна не работает Поэтому свою систему и ее особенности нехило бы знать. Да, это несколько сложнее чем гнуть пальцы на форумах. И вот конкретно ты должен это знать, не? :) > в специальное учреждение, в положенное время положенный специалист тебе ее прочтет > - так и то, что положено. Ну а что, дать денег тем кто все-таки в проблематике разбирается - это вполне себе вариант. Если уж сам с темой не дружен - что ж поделать. Вон японя пытается рассматривать линух как бесплатный маздай. Разумеется это работает плохо - совершенно разные системы с разными "приколами". И если копнуть, большой вопрос чей набор приколов хуже. Большинство линуксных таки можно обыграть. А вот некоторые виндовые чудеса - лично я в принципе не возьмусь, ибо винда крайне враждебна к системным вещам и системщикам.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от iPony129412 (?), 03-Мрт-20, 11:38
	> Вон японя пытается рассматривать линух как бесплатный маздай Чего? А почему я на ту же Ubuntu потратил столько денег, что наверно этак надо брать десяток тут комментаторов типа "линукс - это круто!" с их донатами в опенсорс - наверно не переплюнут. И футболки все есть с маскотами - с единорогом самая фапабельная. Не, мне "вендовых приколов" в линуксе ни за бесплатно, ни за деньги не надо. Просто мне отсутствие религии позволяет сравнивать macOS/Windows/Linux на десктопе. > Поэтому свою систему и ее особенности нехило бы знать Мой любимый пример - это звуковая сисиема. Пользуясь Windows/macOS/Linux на десктопе про устройство её я могу расcказать только под линуксами. Не потому что мне это интересно, это круто, пригодится в работе - а просто работает через одно место... Это место на букву П.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от Аноним (-), 03-Мрт-20, 22:47
	> Чего? А почему я на ту же Ubuntu потратил столько денег, Ну, потребуй их возврата, чтоли, если чем-то недоволен? Хоть я и не понимаю как ты это сделал, но хомячки существа забавные. Если уж они эплодевайсы на лопатки кладут одной левой, я не удивлюсь и деньгам потраченным на убунты > круто!" с их донатами в опенсорс - наверно не переплюнут. А вот лично я еще малость умею борзыми щенками, это всегда в цене :P > Просто мне отсутствие религии позволяет сравнивать macOS/Windows/Linux на десктопе. Мне кажется, таких как ты в линуксе не очень то и ждут. Для тебя вон максимум это андроид какойнить, с залоченым бутлоадером и кучей шпиков в комплекте. Это то что господам типа тебя реально светит "по жизни". Ну, можно на эппл заменить, на результат не влияет - тот же залоченый бутлоадер и сотни шпиков. > работает через одно место... Это место на букву П. На себе я это как-то не ощутил. И если П это ПульсАудио - ну, у меня он просто работает. И я вообще не трогал никаких конфигов руками и проч. Ну, повозякал немного крыжики в pavucontrol, дабы вело себя как мне нравится - примерно как в винде, только в винде еще дрова черти какие и вечно норовят какие-нибудь приколы отмочить. Как вон на одной системе работало только 1 ухо почему-то. Ну вот драйвер так джеки видимо обрабатывает. В линухе, чсх, оба уха пашет нормально, и уткнувшись в такие факты я как бы готов с сэром поспорить насчет линукса и звука.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от Аноним (4), 02-Мрт-20, 21:08
	То слишком сложно для него. Еще и на буржуйском. Надо было что-то типа "ну чо, пацаны, седня перетрем за свапинесс, короче так..." и в двух словах, что это такое.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	59. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (58), 03-Мрт-20, 02:22
	Только так и можно завоевать массовость.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от Секция башенного крана (?), 03-Мрт-20, 06:44
	>"sysctl -w vm.swappiness=1" Вот юзкейс: был у юзера свопинес 1, и все висло. Поставил 60 - и полегчало. > I've reduced my swapfile now to 3 GB and changed swappiness to 60. Running memload doesn't lock up the system as badly anymore https://github.com/hakavlad/nohang/issues/85#issuecomment-58...
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	88. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от бублички (?), 03-Мрт-20, 08:54
	уже с десяток лет не делаю swap больше 1 GB - он просто годами не используется на серверах где объём памяти начиная от 64 GB. а swapiness лишь помогает чтоб даже в этот 1 GB ничего не сместилось, кроме совсем уже критических ситуаций, которые мониторятся и тщательно изучаются. а вот earlyoom и подобным костылям, на мой взгляд место в топке
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от ананчик (?), 04-Мрт-20, 00:21
	Стоит спросить у пользователя захрена он изменил дефолт? Я так тоже могу, грохну к хренам fstab и буду ходить рассказывать что не работает ваш линакс
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	190. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 04-Мрт-20, 22:40
	> грохну к хренам fstab и буду ходить рассказывать что не работает ваш линакс Показать как Linux работает без fstab? :) Systemd смешно чертыхается, конечно, но ничего фатального не происходит.
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Анонимусис (?), 05-Мрт-20, 13:17
	У systemd есть объект, который называется точка монтирования. Если вы умеете его правильно готовить, то на fstab никто ругаться не будет, ибо легаси.
	Ответить | Правка | Наверх | Cообщить модератору

	223. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (223), 07-Мрт-20, 07:30
	> У systemd есть объект, который называется точка монтирования. Если вы умеете его > правильно готовить, то на fstab никто ругаться не будет, ибо легаси. У меня не было ни того ни другого. И собственно я не хотел чтобы systemd своими лапками ремаунтил файлуху - ремаунт, видите ли, загрузку железки замедляет, а кернель ее и так правильг маунтит. Systemd прикольно чертыхается на такое комбо, не понимая откуда это вообще взялось XD но никаких побочных эффектов кроме матюка это не дает. И нет, не надо предлагать маунтить это из системды - это rootfs, на коем systemd и лежит :P
	Ответить | Правка | Наверх | Cообщить модератору

15. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
Сообщение от Нанобот (ok), 02-Мрт-20, 20:46
> сброс привилегий root А как оно после этого прибивать процессы будет?
Ответить | Правка | Наверх | Cообщить модератору

	17. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от VINRARUS (ok), 02-Мрт-20, 20:48
	Через sudo =)
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от Антон (??), 03-Мрт-20, 01:56
	CAP_KILL
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	156. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Нанобот (ok), 03-Мрт-20, 18:45
	получается процесс с правами убивать всех :) такой себе жнец с косой (ну или шинигами, если хотите)
	Ответить | Правка | Наверх | Cообщить модератору

26. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
Сообщение от YetAnotherOnanym (ok), 02-Мрт-20, 21:16
> Добавлена подсветка отладочного лога светло серым цветом Нужно, да.
Ответить | Правка | Наверх | Cообщить модератору

27. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
Сообщение от Аноним (-), 02-Мрт-20, 21:21
А в FreeBSD как, разве лучше?
Ответить | Правка | Наверх | Cообщить модератору

	36. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от Alex_K (??), 02-Мрт-20, 22:02
	Фря процессы, жрущие много памяти, убивает, в dmesg и /var/log/messages будет что-то типа: pid 5490 (mysqld), uid 88, was killed: out of swap space
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от Аноним (11), 02-Мрт-20, 22:05
	Но, вообще, была инфа, что во FreeBSD всё так же плохо.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+4 +/–
	Сообщение от zzz (??), 03-Мрт-20, 02:55
	На лоре тебе и не такой инфы расскажут. За всю свою практику ни разу не сталкивался с тотальными фризами из-за памяти. Тупило, отвечало через минуту, но отвечало. А тут как-то попросили поставить линукс на старый уже комп с двумя гигами. Ну я поставил. Открыл скайп, пяток вкладок в ФФ - и у меня всё встало колом. Подождал, еще подождал - через десять минут стало понятно, что ждать бесполезно и надо жать ресет. Такой фигни у меня ни разу не было ни на винде, ни на фрюхе, которую я одно время пользовал десктопом.
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от ананчик (?), 04-Мрт-20, 00:29
	что то вы лукавите, нормально суся на 2гб работает. Все вам не так то спинлок медленно работает, то OOM криво. Если вы что то до настраивали или школьник который собирал ваш дистрибутив решил поиграть в оптимизатор - только вашы пролемы
	Ответить | Правка | Наверх | Cообщить модератору

39. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
Сообщение от Alexey (??), 02-Мрт-20, 22:04
Во FreeBSD не лучше. Эффект наблюдается при зацикливании сборки из портов, до полного исчерпания. ZX Spectrum хорошо реагировал на подобное - нет памяти и всё.
Ответить | Правка | Наверх | Cообщить модератору

	45. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от анонн (ok), 02-Мрт-20, 23:34
	> Во FreeBSD не лучше. Я тут, на опеннете, даже демку со друзей программой приводил - или пробивается ядерным ОоМ или не получает память > Эффект наблюдается при зацикливании сборки из портов, до > полного исчерпания. Разве что если из под рута в tmpfs или MD собирать.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от анонн (ok), 02-Мрт-20, 23:36
	>со друзей программой приводил жручей
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от Аноним (47), 02-Мрт-20, 23:55
	Дело не в жручести. Многое зависит от паттернов пользования и юзерспейсного аллокатора.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от анонн (ok), 03-Мрт-20, 00:27
	> Дело не в жручести. Многое зависит от паттернов пользования и юзерспейсного аллокатора. Еще больше - от настроек. vm.pageout_oom_seq - выставить поменьше, скажем 4 и возможно стоит посмотреть vm.pfault_oom_wait vm.pfault_oom_attempts А сам фряшный OOM простой как тапок, подсчитывает тупо кол. резидентных страниц  - там комментарий к принципу работы как бы не больше самой реализации. Ну и да - если забить рамдиск от рута, то вполне придет звиздец.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от Аноним (47), 03-Мрт-20, 01:17
	Т.е. 1 в 1 проблемы линукса? Зачем тогда уверять, что там что-то лучше устроено…
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от zzz (??), 03-Мрт-20, 02:57
	Фряха сохраняет минимальную отзывчивость, в линуксе - только ресет. А так-то да, 1 в 1.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (47), 03-Мрт-20, 12:26
	Я не помню, когда мне последний раз пришлось резет в линуксе прожимать. Это наверно если своп маленький ставишь и он забивается.  Вот в венде я помню, что она зависала и не отвечала ни на какие комбинации. В линуксе всегда нажимаешь sysrq+f и едешь дальше, это лучше чем перезагрузка. Т.е. ядро то как раз не зависает, зависает вывод картинки видеодрайвером и несколько секунд может отрвечать терминал, чаще просто потому что io забито. Лучше добавить свопа и не доводить до такого.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от zzz (??), 03-Мрт-20, 16:29
	Выше я уже давал юзкейс: машинка с 2Гб. Под своп отдал 2 Гб. Открыл скайп, открыл пять вкладок - и всё, с приветом Шишкин, даже мышка елозить перестала. Что я там ни жал - не отвечало. Перезагрузился, повторил эксперимент с открытым top-ом: зависание произошло при 30%-ом заполнении свопа. На винде при таком же наборе открытого софта потребление было таким же (так что оверкоммит тут не при делах), при этом система подлагивала, но отзывчивость сохраняла. Если у тебя на машине 16 гигов памяти и своп наполняется от силы на 10% - поверю, что ты не жмешь ресет уже очень давно. У меня же был иной экспириенс. Смотря на всё это, посещают мысли вообще накатывать фрю - пусть там меньше драйверов, но за год использования, как я её только ни мучил - работала как часики под любой нагрузкой.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (47), 03-Мрт-20, 16:45
	Это на линуксе? На ПК 8ГБ памяти, 4ГБ своп. Пока своп не заполнится на 100% я и не увижу, что что-то пошло не так (тут отличие с виндоус, в которой всё начинает тормозить). >своп наполняется от силы на 10% vm.swapiness=99, в норме он заполняется только когда софт "протёк" — в среднем занято не больше 5%. Фоновые вкладки браузера в него падают, визуально видимых задержек при переключении нет. Компиляция "в памяти" не даёт никаких негативных эффектов, игрушки разве что дольше загружаются, когда используется своп. Зависания бывают разные. Если завис видеодрайвер, то тут уже ничего не сделать скорее всего. У виндоус есть хоткей сброса видеодрайвера, а линукс так не умеет. Звук (в плеере например) при этом будет воспроизводится, несмотря на висящие иксы. Если ядро затупило от исчерпания свопа, звук тоже зависает через несколько секунд. Ни разу не видел, чтобы зависание было при наличии свопа - скорее всего был резкий скачок за пределы имеющегося объёма и он просто не отобразился. Проблемы от использования браузеров и жава-софта у меня достаточно часто. И от компиляции браузеров фоном. А ещё бывает что софт течёт. Но всегда выручает sysrq+f (кстати, во многих дистрибутивах magic key комбинации выключены  в ядре).
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (47), 03-Мрт-20, 16:50
	Если sysrq+f не помогает, можно нажать sysrq+e послать сигнал term всем процессам, что лучше перезагрузки. Дальше просто перезапускаешь сервисы в состоянии crashed и иксы. Усб клавиатура может не работать в иксах при зависании, нужно сначала нажать sysrq+r.
	Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

	195. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 05-Мрт-20, 02:11
	> Если sysrq+f не помогает, ...и это пингвин, поставьте себе уже наконец более-менее современное ядро, там oom_killer довольно меткий.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 03-Мрт-20, 17:09
	> это, посещают мысли вообще накатывать фрю - пусть там меньше драйверов, > но за год использования, как я её только ни мучил - > работала как часики под любой нагрузкой. время показывала? ;-) Эт она может. А если тебе работать в мало памяти - и вот чо щастья от того, что твой сцайп вывалился с sigbus?
	Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

	157. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от zzz (??), 03-Мрт-20, 22:11
	Надо будет проверить - когда я её пользовал в качестве десктопа, проблем из-за работы с памятью, тем более чтобы система наглухо висла из-за пяти вкладок, у меня ни разу не было.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от ананчик (?), 04-Мрт-20, 00:42
	Так надо былу свам раздел на стримере размещать. >даже мышка елозить перестала Да это не показатель, у меня мышка лет пять назад елозить перестала, а пинги до сих пор ходят как часы.
	Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

	64. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от анонн (ok), 03-Мрт-20, 03:25
	> Т.е. 1 в 1 проблемы линукса? >> Пишешь какую-то свою прогу, которая из-за ошибки ушла в бесконечный цикл по захвату памяти. Комп становится полностью нерабочим нет. time -l  python -c '{x:str(x)*(x**x**x) for x in range(100000000)}' time: command terminated abnormally         9,80 real         0,80 user         3,91 sys    6145052  maximum resident set size killed     time -l python -c '{x:str(x)*(x**x**x) for x in range(100000000)}' >> При копировании десятков гигов система может повиснуть, точнее курсор мыши будет двигаться, а кликнуть нельзя ибо система не отвечает. нет. https://www.opennet.me/openforum/vsluhforumID3/118068.html > "Linux ядро не может мягко обрабатывать ситуации с нехваткой ..." > Выключаем поддержку swap (sudo swapoff -a) > Запускаем любой веб браузер, например, Chrome/Chromium или/и Firefox >  Начинаем открывать вкладки с сайтами и смотрим как уменьшается объём свободной памяти > Как только возникает ситуация, что новая вкладка требует больше оперативной памяти, чем доступно, система практически полностью зависает тоже ни разу не наблюдалось - только "Оп-па, пропало окно браузера" и "pid 36197 (firefox), jid 0, uid 1001, was killed: out of swap space" в логе. А так да, прям "1 в 1". Правда, даже описаный принципиальный "deadlock" с tmpfs не сходится с описанием https://bugzilla.kernel.org/show_bug.cgi?id=201673 > for some reasons OOM doesn't kick in and the only way to unfreeze your PC is to forcefully reboot it потому что "звиздец" требует лыжи^W и противогаз^W прописывания размера tmfs ручками, отключения "защиты от дуркака" в виде "vfs.tmpfs.memory_reserved: Amount of available memory and swap below which tmpf  growth stops" заполнения части memory disk от рута. И "прилетает" там от излишне усердного ООМ killer, прибивающего в том числе и логиншел (что принципиально обходится предварительным выставлением защитного флага на sshd или login). Но да, в остальном, абсолютно 1 в 1. > Зачем тогда уверять, что там что-то лучше устроено… И где уверения? Хотя да, умиляют некоторые комментаторы, явно не ожидавшие, что лишние навороты сложности и разных эвристик в пингвине, могут иметь не только лишь плюсы и повод для гордости за результаты в бенчах, но и некоторые неприятные (и трудно отлавливаемые) побочные эффекты.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	109. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 03-Мрт-20, 11:06
	> Хотя да, умиляют некоторые комментаторы, явно не ожидавшие, что лишние навороты сложности и > разных эвристик в пингвине, могут иметь не только лишь плюсы и повод для гордости за результаты > в бенчах, но и некоторые неприятные (и трудно отлавливаемые) побочные эффекты. ну вообще-то в том примере товарищ уж очень старался этот эффект получить. А у free, взамен, out of memory, с битой базой mysql по результату, случается и тогда, когда память в системе, вообще-то, была, но по разным причинам, ее постеснялись отобрать.
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 05-Мрт-20, 05:47
	> по разным причинам, ее постеснялись отобрать. А эти причины случайно не ZFS назывались?
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 05-Мрт-20, 07:42
	>> по разным причинам, ее постеснялись отобрать. > А эти причины случайно не ZFS назывались? я же сказал - разным. zfs на этой системе может вообще не быть, а память вожрана в кернельные zones и хрен ты ее оттуда достанешь, хотя в данный момент она не используется. Ну ведь планки памяти такие дешевые, не так ли?
	Ответить | Правка | Наверх | Cообщить модератору

	224. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (223), 07-Мрт-20, 07:31
	> Ну ведь планки памяти такие дешевые, не так ли? Ага, блин, найди мне планки памяти на вон тех одноплатничках :). Но ты в принципе можешь и попытаться перепаять BGA с шагом 0.4 :)
	Ответить | Правка | Наверх | Cообщить модератору

69. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
Сообщение от КО (?), 03-Мрт-20, 06:05
Плохо будет если его хакнут, пробэкдорят или еще чего...
Ответить | Правка | Наверх | Cообщить модератору

	71. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Секция башенного крана (?), 03-Мрт-20, 06:26
	Не беспокойтесь, я отслеживаю каждый коммит. И мои братья тоже.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 03-Мрт-20, 10:27
	Хакнут обработчик OOM? Так он же не делает ничего кроме мониторинга памяти и сноса процессов? Если у вас систему при этом можно хакнуть, у вас уже имеются серьезные проблемы.
	Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

97. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
Сообщение от Аноним (-), 03-Мрт-20, 10:26
> PATH_LEN А что, PATH_MAX ща не модно?
Ответить | Правка | Наверх | Cообщить модератору

138. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
Сообщение от yaya (?), 03-Мрт-20, 14:42
Народ, помогите собрать небольшую статистику. Вот пример, который уводит мою систему (centos 7, hdd 500 GB, 8 GB оперативки, swap включён на 8 ГБ, процессор i3-2100) во фриз: ''' #include <stdint.h> #include <stdlib.h> int main() {   while (1) {     uint64_t *buf = malloc(1024 * 1024 * 1024);     if (buf != NULL) {       for (int i = 0; i < 1024 * 1024 * 1024 / 8; i += 4096 / 8) {         buf[i] = 0;       }     }   }   return 0; } ''' Собрать и запустить: # cc -std=c99 a.c && ./a.out И просьба написать: 0) запустилось/не запустилось/прибилось 1) дистрибутив 2) swap включён или нет 3) полный фриз/притормаживает/вообще не заметил 4) диск: hdd или ssd 5) настройки "из коробки" или что-то сами настраивали
Ответить | Правка | Наверх | Cообщить модератору

	142. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от пох. (?), 03-Мрт-20, 15:56
	запустилось, сожрало весь процессор (логично, как и то что система при этом, мягко говоря, не летает) и нагадило 7 гиг в своп из десяти возможных. На чем надоело и было прибито банальным ctrl-c Поскольку не очень понятно, что мы хотели в итоге узнать - что происходит при запуске троянской программы? Очевидно. Лечение - изоляция и лимиты. Что происходит при запуске легальной программы, которой действительно нужно перемолоть больше памяти чем может дать система - тоже очевидно. Лечения нет, кроме как бежать за планкой. Что происходит при запуске плохо написанной программы, которой столько памяти нафиг не нужно но все равно жрет (наиболее близкий реальный кейс к данному примеру) - тоже очевидно, лечение - выбросить макачий кал и больше не запускать. Система в большинстве этих случаев вполне оставляет время среагировать и возможность вмешаться. Без всякого shit-oom.
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от yaya (?), 03-Мрт-20, 16:17
	Спасибо, что запустили и отписались. > Поскольку не очень понятно, что мы хотели в итоге узнать - что происходит при запуске троянской программы? Да, моя оплошность, что я не написал в комментарии суть эксперимента. Не троянской программы, а ошибочной программы, которая в цикле начинает съедать память. Я приложил сильно атрофированный вариант, который воспроизводит поведение нормальной программы, в которой была допущена ошибка. PS. Это не выдуманный пример. > Система в большинстве этих случаев вполне оставляет время среагировать и возможность вмешаться. Без всякого shit-oom. А что у вас за система? Я свою привёл, у меня система настолько сильно начинает тормозить, что не реагирует ни на что.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 03-Мрт-20, 16:55
	> Не троянской программы, а ошибочной программы ошибки обычно иначе выглядят - вот типичная ошибка (в днк разработчика):   1960 mysql     20   0 5544180 1.873g  11088 S   6.0  9.6   1566:00 mysqld в конце-концов она устанет от такой жизни, задумается о вечном и перестанет откликаться на раздражители (виснет только один из тредов, но об него локаются запросы и рецепт все равно один) - после чего будет просто прибита и перезапущена. Но она никому особо не мешает, лежит себе в гробу...зачеркнуто, в свопе, второй раз эта память не нужна никому и низачем, просто течет себе потихонечку, поэтому и вреда от нее немного. Программа, которая с памятью все же что-то осмысленно делать пытается, а не просто течет, и вгоняет систему в trashing - так что при этом загадит всю и еще захочет - она обычно cpu intensive (столько памяти-то лопатить, мало не покажется), там так просто не отделаешься. И непонятно, хотим ли мы ее такую прибить - нам может в любом случае вся система бесполезна без результатов ее работы. Система - виртуалка с обычной убунтой, xeon e5, диски живут на промышленной СХД, но она об этом счастливо не в курсе, живут на ней репо прода и самой убунты, поэтому нагрузка в штатном режиме ровно ноль, никаких особо специальных настроек нет. Ну да, она тормозила - ну так и должна. У нас работает минимум парочка активных процессов - своппер, который скидывает блоки на диск и пересовывает их в свободный пул - там наверняка через глобальные локи все делается, небыстро, и искалка этих самых свободных блоков - чтобы выдать программе. Ну и наверняка ж еще кто-то там мультитредовый из них. Причем отсутствие памяти не повод остановиться, потому что pressure сохраняется, и цикл поиска все время активен. Помимо самой программы, которая ничем у нас не ограничена кроме как раз своппера - поэтому свое ядро тоже жрет. Вот все четыре доступных и сожрало. При этом буферы уже обнулены, дискардимые сегменты подискаржены, чтение очередной копии шелла с диска превращается в нудный процесс. 15:49:18 up 208 days, 23:28,  2 users,  load average: 3.95, 1.22, 0.42 USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT user      pts/0    192.168.6.4      15:47    1:17   1:04  55.70s ./a.out user      pts/1    192.168.6.4      15:48   11.00s  2.08s  0.50s w linups:~> free               total        used        free      shared  buff/cache   available Mem:        8209956     8071716       46580          44       91660       46520 Swap:      10483708     7880952     2602756 ядер там больше и нету, все что есть - съело. В целом - не вижу на этом вырожденном случае какого-то особо неправильного поведения системы.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от yaya (?), 03-Мрт-20, 18:38
	> В целом - не вижу на этом вырожденном случае какого-то особо неправильного поведения системы. Да, интересно. Но вы это всё запустили в виртуалке - соответственно, можно найти кучу объяснений, почему вы не ощутили полного отсутствия отклика от системы. > Ну да, она тормозила - ну так и должна. То, что творится у меня, я бы не сказал, что "так и должна" :)
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Выпуск обработчика нехватки памяти earlyoom 1.4"	–1 +/–
	Сообщение от Аноним (145), 03-Мрт-20, 16:30
	*та самая картинка с велосипедом и палкой в колесе*
	Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

	151. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+1 +/–
	Сообщение от yaya (?), 03-Мрт-20, 17:44
	Вы так на все тесты реагируете? Багрепорты ни разу не писали? Обычно для поиска бага хорошо иметь тест. Или вы ходите по github'у и на все багрепорты с прикреплёнными тестами прикладываете картинку с велосипедом и палкой? Типа "ха-ха, вот дурак, зачем же ты так делаешь, если же видно, что оно не работает. Сам виноват - велосипедист с палкой, ха-ха" так что ли?
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от ананчик (?), 04-Мрт-20, 00:49
	тест не релевантен, нехватает sleep как только он съедает память то сразу выходит и еще вагон всего вам прежде чем статистику собирать неплохо бы понять что вы хотите проверить, понять как оно должно работать и код правильно написать
	Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

	183. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от yaya (?), 04-Мрт-20, 20:25
	> тест не релевантен, нехватает sleep Зачем sleep-то? > как только он съедает память то сразу выходит Вы не увидели там while (1)? > и еще вагон всего > вам прежде чем статистику собирать неплохо бы понять что вы хотите проверить, понять как оно должно работать и код правильно написать То, что я хочу проверить - я понимаю и написал такой маленький тест. Один человек уже его запустил, у него не возникло недоумений, как у вас. Он увидел, что его система начала притормаживать, но не критично. По ctrl-c он сумел срубить тест. Но он запустил его в виртуалке. Если я запускаю на своей машине этот же тест, то у меня машина перестаёт откликаться - всё уходит в своп и не даёт ничего сделать. Прежде чем давать советы и выглядеть дурачком, вы бы лучше спросили, что вам непонятно.
	Ответить | Правка | Наверх | Cообщить модератору

	191. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от ананчик (?), 04-Мрт-20, 23:44
	> Зачем sleep-то? что бы не выжирал память за считанные секунды. >Вы не увидели там while (1)? Действительно он есть, что еще более странно что будет когда malloc будет возвращать ошибку while(1){} одно ядро убили. я похожие тесты крутил очень очень давно, когда памяти было действительно мало. И они закачивались тем что процесс умирал после жуткого просиживания по io. То что у вас  gui  просто встает колом тоже нормально это регулируется приоритетами процессов по io. а вот посадить такую  membomb в cgroups я не пробовал, думаю сейчас это решило бы практически все проблемы Учтите что соотношение размера оперативной памяти и размер свопа очень сильно влияет на ваши тормоза. Добавьте sleep где-то 1-5 секунд запустите vmstat/iotop или что то подобное и вам сразу станет понятно откуда тормоза. вот вам маленькая шпаргалка https://www.oracle.com/technical-resources/articles/it-infra... в ядре все нормально на самом деле, дополнительное накручивание автоматики только вред приносит.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 05-Мрт-20, 02:22
	> что бы не выжирал память за считанные секунды. А в чем пойнт туповэйтить в разы дольше?
	Ответить | Правка | Наверх | Cообщить модератору

	203. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 05-Мрт-20, 07:47
	> Действительно он есть, что еще более странно что будет когда malloc будет > возвращать ошибку очевидно - будет крутиться в цикле, периодически спрашивая "а еще память есть? А если найду?" и если найдет - сожрет. > io. То что у вас  gui  просто встает колом > тоже нормально это регулируется приоритетами процессов по io. этот процесс не занимается io, думайте дальше. > а вот посадить такую  membomb в cgroups я не пробовал, думаю > сейчас это решило бы практически все проблемы да-да. ручное управление памятью каждому /bin/ls решит все проблемы, безусловно. Добро пожаловать в 1970й. В 72м это немного всем уже осточертело, и появился unix.
	Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

	209. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от yaya (?), 05-Мрт-20, 15:48
	> что бы не выжирал память за считанные секунды. В этом и есть тест. Не, конечно можно было бы открыть chrome, открыть кучу вкладок, открыть libreoffice книги "Война и мир", открыть видеоредактор, 3D-редактор, загрузить в них кучу файлов и надеятся нарваться на проблему "нехватки памяти", но это как-то долго и не факт, что получится проблема "нехватки памяти".
	Ответить | Правка | К родителю #191 | Наверх | Cообщить модератору

	213. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от пох. (?), 05-Мрт-20, 22:32
	>> что бы не выжирал память за считанные секунды. > В этом и есть тест. Не, конечно можно было бы открыть chrome, не, это разные тесты. Тут весь поинт в том что память жрется быстрее, чем своппер успевает ее освобождать. Хромог с либреофисом такого не творят, потому что память им для дела нужна - они требуют здоровый кусок, потом долго и мучительно его заполняют, потому что это надо скачать, распарсить, обсчитать и т д. При этом у своппера остается время и он почти не создает подобных проблем. Плюс они обрабатывают ошибки выделения этой памяти (скорее всего assert("опачки, кончилась?"); но уж точно не навернуть еще десяток циклов в ожидании а вдруг появится). > "нехватки памяти", но это как-то долго и не факт, что получится > проблема "нехватки памяти". получится, но она несколько иначе выглядит. В наиболее примитивном варианте - человек однозадачен, поэтому ковыряется в чем-то одном, с небольшим working set, а остальное только создает для этого фон - своп работает так, как ему и положено - в нем лежит ненужное в данный момент, а активный обмен со свопом происходит только при явном переключении человеческой активности.
	Ответить | Правка | Наверх | Cообщить модератору

	216. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от yaya (?), 06-Мрт-20, 16:52
	> Тут весь поинт в том что память жрется быстрее, чем своппер успевает ее освобождать. > получится, но она несколько иначе выглядит. Даже если не жрать память быстрее, а просто один раз запросить памяти на размер ОЗУ*2 и активно потом этой выделенной памятью пользоваться, то мы получим непрерывную активность на диске (если своп достаточно большой). Более того, процесс консоли может слится на диск и если я вдруг захочу прибить такую программу, то среди всего этого шуршания консоль будет долго идти до памяти и опять получится неотзывчивая система (если, конечно, ядро не остановит всю активность и не отдаст приоритет консоли, но тогда бы я мог прибить свою ту тестовую программу, но система не реагировала, поэтому предполагаю, что никакого приоритета не отдаётся). Если усложнить эксперимент (возвести в абсолют) и сделать своп на дискетах, то считай всё, проще сделать аппаратный ребут, чем перебирать дискеты. Никто не может заранее сказать, что запуская какую-то программу она не съест ОЗУ*2 памяти и не будет ею активно пользоваться, что аж все другие программы уйдут в своп. На это тоже интересно было бы написать тест и посмотреть как поведёт себя система. Впрочем, это не открытие америки. https://www.phoronix.com/scan.php?page=news_item&px=Linux-Do...
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 05-Мрт-20, 02:21
	См. сюда - https://www.opennet.me/openforum/vsluhforumID3/119943.html#193 > 0) запустилось/не запустилось/прибилось Запустилось, сожрало память, прибито oom_killer. С -O2 то только грузило проц, но не жрало RAM. > 1) дистрибутив Deb 10; кернел собственный (full preempt aka "realtime"; no_hz_full aka "tickless"; примерно 5.5). > 2) swap включён или нет ZRAM. > 3) полный фриз/притормаживает/вообще не заметил Даже плеер не икнул. > 4) диск: hdd или ssd SSD. Но HDD в _этом_ случае не должен был бы сильно испортить. > 5) настройки "из коробки" или что-то сами настраивали Осмысленный тюниг с задействованием головы. Цель - быстрая система, которую не клинит. Судя по тесту, получилось отлично. Кернель собран по вкусу, интересного в данном случае full preempt, это полезно от клинов.
	Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

	210. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от yaya (?), 05-Мрт-20, 15:59
	Спасибо за отзыв! Видимо, oom_killer спас в этой ситуации. Почему у меня, интересно, не сработал oom_killer? Запускаю ulimit у себя и вижу unlimited. Может в этом всё дело...
	Ответить | Правка | Наверх | Cообщить модератору

	225. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (-), 07-Мрт-20, 07:38
	> Видимо, oom_killer спас в этой ситуации. А не должен был? В системе кончилась память - он и возбух. > Почему у меня, интересно, не сработал oom_killer? А кернель сильно древний? Если системный диск механический и много всего запущено, бинари могут подрабатывать readonly свопами. Ну и его вручную можно попросить alt-sysrq-f. > Запускаю ulimit у себя и вижу unlimited. Может в этом всё дело... Ulimit и oom_killer несколько ортогональны. Если ulimit или подобный лимит сработает, до oom_killer дело скорее всего не дойдет - прога получит фигу до того как в системе память кончится "глобально". И кстати там вон подсказывают что ошибки выделения памяти нехило бы ловить. Я кстати не полностью понял что оно делает с -O2. VSZ конский, RSS натикал до гига и угомонился, после этого оно только проц грузит. Дизассемблить/профайлить все же несколько впадлу, я и так пару мистических штук разрулил, еще столько же осталось.
	Ответить | Правка | Наверх | Cообщить модератору

	226. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от yaya (?), 10-Мрт-20, 12:50
	> А не должен был? В системе кончилась память - он и возбух. Я не много знаю про OOM killer, но он там как-то определяет, что убить, а что оставить. Теоретически, он мог прибить не тест, а что-то полезное. Да и то, пока не будет swap'а - тест не особо интересен. Именно из-за наличия swap'а, можно словить тормоза. > А кернель сильно древний? Не знаю, но версия такая: 3.10.0-1062.9.1.el7.x86_64 > Ну и его вручную можно попросить alt-sysrq-f. Вот что-что, а хоткеи в линуксе/ОС - это ещё одна больная тема, с которой я сталкиваюсь (хотя тут, наверное, X'ы уже виноваты, а не ядро). Элементарно не работают комбинации ctrl-shift-<some-key> (по ctrl-shift у меня переключение языка) (хотя в той же винде в той же программе (kicad, например) всё работает), а вы говорите про alt-sysrq-f, которые я жму - ничего не происходит. То ли оно работает, но не подаёт виду, то ли что-то опять не так с хотекеями... Но запускать свой тот тест и проверять alt-sysrq-f - не хочу рисковать опять жёстко вырубать комп :) > Я кстати не полностью понял что оно делает с -O2. 0000000000400440 <main>:   400440:       48 83 ec 08             sub    rsp,0x8   400444:       0f 1f 40 00             nop    DWORD PTR [rax+0x0] цикл 1: вызываем malloc(1 GB):   400448:       bf 00 00 00 40          mov    edi,0x40000000   40044d:       e8 de ff ff ff          call   400430 <malloc@plt> делаем "цикл 1", пока он возвращает указатели:   400452:       48 85 c0                test   rax,rax   400455:       74 f1                   je     400448 <main+0x8> цикл 2: заводим счётчик на 1 GB / 8:   400457:       b8 00 00 04 00          mov    eax,0x40000   40045c:       0f 1f 40 00             nop    DWORD PTR [rax+0x0] делаем "цикл 2", пока счётчик не 0:   400460:       83 e8 01                sub    eax,0x1   400463:       75 fb                   jne    400460 <main+0x20> повторяем "цикл 1"   400465:       eb e1                   jmp    400448 <main+0x8> Итого: компилятор выпилил запись в память. Мы впустую типа запросим память и впустую прокрутимся в пустых циклах.
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (206), 05-Мрт-20, 09:45
	i5-3570, 32 ГБ RAM 0) запустилось/не запустилось/прибилось запустилось 1) дистрибутив Debian testing amd64 2) swap включён или нет выключен 3) полный фриз/притормаживает/вообще не заметил "a.out" ~18 минут крутился с 30 ГБ RES и одним съеденным ядром, но без хоть сколь-нибудь заметного влияния на отзывчивость. Потом начало тупить и эксперимент был прекращён по Ctrl+C 4) диск: hdd или ssd HDD, хотя при выключенном свопе это не важно 5) настройки "из коробки" или что-то сами настраивали вроде бы, ничего специально не настраивалось
	Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

	211. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от yaya (?), 05-Мрт-20, 17:03
	Спасибо за отзыв! Ничего себе у вас там памяти :) Интересно, что не сработал oom_killer, а спокойно отдалось 30 ГБ. Возможно после этого из malloc стал возвращаться NULL и просто крутился голый цикл, съедая CPU.
	Ответить | Правка | Наверх | Cообщить модератору

	214. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
	Сообщение от Аноним (214), 05-Мрт-20, 23:36
	Там ещё ~230-250 мегабайт свободные оставались, чего, возможно, было слишком много для срабатывания OOM killer-а, но слишком мало для overcommit-а при вызове malloc() на гигабайт. Собственно, тормоза начались только при попытке открыть новую вкладку с ютубом -- вероятно, аллокации в браузере снизили объём свободной памяти до некоторой критической отметки и ядро начало думать, что с этим делать. :)
	Ответить | Правка | Наверх | Cообщить модератору

208. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
Сообщение от Не_аноним (?), 05-Мрт-20, 14:56
rshadow > В консерватории, пробовали править? > Нахрена вообще на современной тачке нужен своп на диск? Уменьшать жизнь ssd? > Хочешь своп, ну zram настрой что-ли. Закинь туда метров 500 и > забудь. Раз уж 2т.р. на еще планочку жалко. > Браузер сожрал всю память? Напиши 10 строк конфига для cgroups и жестко > прибей ему 4 гига. Больше он никого не повесит. Ох эти болтуны не зная жизненой ситуации у людей пишут с лёгкостью почему не купил ещё себе памяти в ПК. Раз такой совечик и при деньгах переведи rshadow хотябы 300 рублей на покупку памяти для начала. Если переведёш отпишусь здесь, да перевод на 300 был. Если, что всё легально сервис от Яндекса. https://bit.ly/3caE7bG
Ответить | Правка | Наверх | Cообщить модератору

217. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
Сообщение от yaya (?), 06-Мрт-20, 16:52
Linux плохо себя чувствует при нехватке памяти: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Do...
Ответить | Правка | Наверх | Cообщить модератору

227. "Выпуск обработчика нехватки памяти earlyoom 1.4"	+/–
Сообщение от montmorency (?), 02-Фев-21, 16:23
только не РАСкомментировать, а ЗАкомментировать - с точностью до наоборот.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема