-bash: fork: Невозможно выделить память
Когда я запускаю любую команду в оболочке bash, она возвращает:
Затем я попытался отладить утечки памяти с помощью команды ps . Возвращает:
Как отлаживать? В чем основная проблема?
4 ответа
Я также столкнулся с этой проблемой с моим рабочим столом Ubuntu 14.04.
Даже эти основные команды показали, что невозможно выделить память. В ходе расследования выяснилось, что система использует всю память для кэширования и не освобождает память. Это называется Cache Ballooning и решается путем очистки кеша.
Сначала вы можете проверить использование системной памяти, чтобы увидеть, достаточно ли свободной памяти.
Если нет, то в моем случае проверьте свой ulimit, набрав ulimit -a , чтобы убедиться, что вы достигли предела максимального количества открытых файлов (в основном вызванного некоторыми определенными процессами, которые занимают много файловых дескрипторов). В этом случае настройка ulimit решит вашу проблему.
У меня такая же проблема. В моем случае, узнав о деталях памяти с помощью « proc / meminfo », я обнаружил идентификаторы, что они использовали много ресурсов ЦП и памяти с « TOP ». После этого я проверил, как долго они работают с » ps -o etime = -p» PID «. Msgstr «Затем я убиваю PID с помощью» kill -9 PID «.
В моем случае ОС работала без PID вместо памяти, сообщение об ошибке было то же самое.
Значение по умолчанию для максимального числа PID равно 32768, чтобы просмотреть значение, запустите
Чтобы изменить максимальный номер pid, запустите
В моем сценарии основной причиной было то, что один процесс Java порождал 18k + потоков (в ядре Linux, поток по сути является процессом), чтобы выяснить количество потоков каждого процесса, запустите
Источник
Выделение оперативной памяти для приложения/процесса
Всем привет. У меня слабый компьютер с Debian. Обычно в силу того что компьютер зависает пользуюсь максимум одной программой, браузером или какой-нибудь cs 1.6 например. Браузер или ОС занимают не всю оперативную память под работу, чтобы я мог запустить другое приложение и компьютер не завис, но мне этого не надо и я хочу максимальной производительности от используемого приложения.
Как мне выделить всю оперативную память (2ГБ) под конкретное приложение/процесс? Какие команды использовать? В интернете нашёл команду nice для повышения приоритета процесса, но пишут что не всегда помогают.
zvezdochiot
Добавил игру в эту группу, выделил всю память, игра вместо 2ГБ есть 1ГБ и тормозит.
fearOfSociety
В силу того что я новичок, ничего нового в этих ссылках я для себя не узнал. По инструкции добавил pid процесса в группу, выделил максимальное кол-во памяти (2GB), но игра все равно использует 1GB и зависает
Как мне выделить всю оперативную память (2ГБ) под конкретное приложение/процесс?
Любое приложение и так имеет возможность использовать всю доступную память. Если не использует, значит не хочет, и командами ты его это делать не заставишь. В любом случае недоиспользованная приложениями память используется для кеширования данных с диска. Так что она всё равно не простаивает.
Что за игра? Через «что» работает?
но только диск со swap будет загружен, если игра на том-же диске опять не поиграешь
Потому что линуксом невозможно пользоваться на компьютерах с небольшим количеством оперативки.
zvezdochiot
экий Вы, сударь, простофиля.
не устал тупизной сиять?
было такое что мишь и ctrlaltfn тормозил и долго думал, что-то компилял, 8GB оперативка и почти столькоже свопа занято было, т.к. hdd молотил жестко, я не задумывался, подумал тормодиск не замена оперативке, через неделю отпустило, и вроде без ошибок получилось.
так что это? регрес-баг, а не тормодиск?
Please refer also to this bug report. It is the same problem and has existed for eleven (11!) years if one can believe that.
я был плохим полным хомяком тогда
Да, Windows работает гораздо лучше на аналогичных конфигурациях. У 
RussianNeuroMancer есть планшет с 1 ГБ оперативки, и на нем линукс почти не работает.
Кое-как работает, но если повыкидывать всякое из автозагрузки и включить максимальный vm.swappiness. Бисект между 4.11 и 4.12 всё ещё в процессе, буквально два-три шага осталось, но отвлёкся на другие дела. Постараюсь вернуться к этому вопросу летом.
У меня слабый компьютер
Линуксом невозможно пользоваться на компьютерах с небольшим количеством оперативки
2 Гб разве это небольшое количество? Я кучу софта открываю.
В Ubuntu 16.04 — 4.4, если ставил с 16.04 или 16.04.1.
Э, ну нет. blkio контроллер применяется и к свопингу (это тоже i/o).
Можно без проблем с помощью cgroups удушить и поставить раком процесс, безудержно жрущий память, вместо того, чтобы ставить раком систему.
Тут недавно новость была про очередной бессмысленный и беспощадный улучшайзер OOM,
так вот старый сниппет
Здорово, конечно, но на моем компьютере с 8 ГБ RAM и SSD запуск виртуалки при запущенном Firefox, при достаточном количестве оперативной памяти, полностью кладёт юзерспейс на десятки минут (даже мышка не двигается), а на этом же компьютере, но с 2 ГБ оперативки, открытие 10 вкладок в браузере приводит примерно к тому же самому, только чуть слабее.
И неважно, со включенным свопом, или без. Дело не в свопе, а в трешинге, похоже. Значительно улучшил ситуацию, установив:
На Windows 10 я могу запустить две виртуалки и браузер, всё будет подтормаживать (как и должно при такой нагрузке), но мышка не зависнет, программы продолжат переключаться, графика не будет тормозить.
Говорят ещё min_free_kbytes поднимать помогает вплоть до сотен мегабайт.
Не помогает, пробовал, даже хуже становится.
Почему это не делается из коробки по-дефолту и зачем есть возможгсть не делать это, а ставить систему раком, причём как раз по-умолчанию?
Потому что это не решение, а обход проблемы: где-то что-то сломали, а эти настройки помогают сгладить поломку, но не устранить её.
И у меня без групп ровно такой же локап UI. Хотя не на 10, а минуты на три, пока не придёт лесник.
Мой месседж в том, что простейшая конфигурация cgroups решает эти проблемы.
В какой-то степени верно, что это заплатка.
Но поскольку средствами ядра, костыльность решения не очень высока.
KISS же. Потом придётся выслушивать в багтрекере вопросы, почему софтина не может сожрать больше
80% памяти и начинает свопиться.
За примером далеко идти не надо, он в оппосте есть.
А вообще я за memory cgroups в дистрибутивах по дефолту.
У нас тут недавно инстанс с AWS Linux словил хардлок.
Не рассосалось ни через 10 минут, ни через 10 часов.
Повесился наглухо, оставив предсмертную записку с отчаянным трешингом i/o.
я за memory cgroups в дистрибутивах по дефолту
Хотелось бы услышать конкретику, что предлагаешь.
Не рассосалось ни через 10 минут, ни через 10 часов.
Повесился наглухо, оставив предсмертную записку с отчаянным трешингом i/o.
А могли бы этого избежать, если б применяли патч https://github.com/hakavlad/le9-patch
Вот мой шаблон, который при загрузке заполняется жёсткими лимитами на память:
Некропостеры, что ж вы творите =)
По патчу — почему он до сих пор не в апстриме?
Недостаточно обобщенный? Или великие люди, занимающиеся серверами, не обращают внимания на нужды смертных?
Или великие люди, занимающиеся серверами, не обращают внимания на нужды смертных?
Это. Корпоративные админы админят серверные парки сидя за маками.
почему он до сих пор не в апстриме
Никто этот патч особо не продвигал. Но мы-то начнем. Вот, в pf-kernel уже принято.
Или великие люди, занимающиеся серверами, не обращают внимания на нужды смертных?
Сервера тоже страдают:
«The traditional Linux OOM killer works fine in some cases, but in others it kicks in too late, resulting in the system entering a livelock for an indeterminate period.»
Какое поведение ожидается, когда:
- Своп есть.
- Своп есть, но в zram.
Со свопом на медленном диске в прцессе активного своппинга эффект не заметен. При исчерпании свопа быстрее придет киллер.
Своп на zram — лагов нет. https://www.youtube.com/watch?v=d4Sc80TMEtA — толстенькая компиляция
Без свопа: зависания нет, киллер приходит (ядерный, а не юзерспейсный) https://youtu.be/iU3ikgNgp3M
Вот это мне больше всего в этом патче нравится.
А мне наоборот. Убивать можно и юзерспейсными — более гибко и безопасно, через SIGTERM и с тонкой приоретизацией выбора жертвый, опционально с гуи уведомлением.
А вот что нового дает патч — это снижение IO при своппинге — при стрессах и активном своппинге гуй еще жив и здравствует.
Есть ли эквивалент для cgroup2? Эпоха v1 уходит в небытие.
Я бы на десктопе вообще не убивал OOM-ом процессы — только в самом крайнем случае. А все некритичные для базовой работы системы приложения можно загонять в своп вплоть до полной остановки их работы, если необходимо. Главное, чтобы сохранялась возможность оператору отдавать команды системе. Он сам разберется, что убить в первую очередь, лучше любого демона.
Но это для опытных пользователей.
Если пользователь опыта администрирования не имеет, то лучше OOM.
Ты уверен, что чем-то поможет SIGTERM, если процесс не имеет возможности на него оперативно отреагировать? Всё равно следом нужен SIGKILL.
опционально с гуи уведомлением
Ну это наверное и к ядру прикрутить можно. Там же должен быть какой-то ивент на приход OOM? Для целей логгирования и оперативного уведомления на серверах.
где-то что-то сломали, а эти настройки помогают сгладить поломку, но не устранить её
Сломали защиту файловых страниц при нехватке памяти. К счастью, решение найдено: https://github.com/hakavlad/le9-patch
Юзеры на десктопе обычно предпочитают низкие задержки. Система должна оставаться управляемой несмотря ни на что. Лучше потерять вкладку, чем повиснуть на неопределенный срок. О чем и заявили создатели патча:
We also see very slow browser tab switching under low memory. Instead of an unresponsive system, we’d really like the kernel to OOM as soon as it starts to thrash. If it can’t keep the working set in memory, then OOM. Losing one of many tabs is a better behaviour for the user than an unresponsive system.
Ты уверен, что чем-то поможет SIGTERM
Большинство таки реагируют быстро. Конечно, нет гарантий быстрой реакции всех процессов, но для части случаев это лучшее решение. При отстутствии ответа на SIGTERM отправляется SIGKILL.
Ну это наверное и к ядру прикрутить можно.
Но никто это делать, конечно, не будет.
Со свопом на медленном диске в прцессе активного своппинга эффект не заметен. При исчерпании свопа быстрее придет киллер.
А вот что нового дает патч — это снижение IO при своппинге — при стрессах и активном своппинге гуй еще жив и здравствует.
Так, пытаюсь сообразить, что к чему.
Список свободных страниц истощается, и на каком-то этапе система прекращает освобождение файловых страниц.
Если есть своп, начинается исключительно выгрузка анонимной памяти. Если нет, приходит OOM.
Так как расход памяти у жирных процессов идёт в основном на анонимную память, такой режим работы не дружественен к ним и дружественен к процессам, имеющий малый объем анонимной памяти.
Из-за этого отзывчивость улучшается.
Вроде так получается.
Это прям хорошо. Осталось прикрутить еще возможность динамически управлять защитой рабочего набора per process, и будет универсальное решение.
Но никто это делать, конечно, не будет.
У ядра нет механизма уведомления на этот счёт? Я просто не в курсе.
Написать юзерспейсный-то демон не дофига делов.
Когда я тестировал эти патчи, они больше вредили.
возможность динамически управлять защитой рабочего набора per process
Юзеры на десктопе обычно предпочитают низкие задержки. Система должна оставаться управляемой несмотря ни на что.
Она и будет управляемой, если у тебя висит только браузер, но не оболочка рабочего стола. Я об этом говорю уже который месяц.
Лучше потерять вкладку, чем повиснуть на неопределенный срок. О чем и заявили создатели патча
Для мобилки решение оптимально. Но я не про мобилки.
Пользователю лучше знать, что ему потерять. Вкладку в браузере или протёкший gimp.
Сейчас все исправлено. Порог держится побочки изучены. Найдены способы устранения побочек. Мягкое и жесткое резервирование на выбор.
Бывают проблемы со встройкуами интел, но костыль для тлечения описан в ридми.
Разные патчи протестированы.
Читай всю ветку — отсюда и до конца Linux 5.10 (комментарий) — разговор с post-factum
Уже применяется в pf-kernel.
Есть copr для федоры, ребята живут с этим ядром https://copr.fedorainfracloud.org/coprs/atim/kernel-futex/ и довольны, отмечают отличный эффект https://youtu.be/d4Sc80TMEtA
Сейчас выбора нет — гуй мерзнет, зачастую юзеры делают хардресет. Патч дает выбор — зависать или иметь низкие задержки.
Источник
