Что означает сообщение «killed» in Linux

Кто-то ее убил.

Перерасход оперативы, например. В логах посмотри, там подробнее написано.

Её кто-то убил, лейтенант. Кто-то или что-то.

Вопрос почти снят. Понятно, что программу убивают при нехватке памяти, но почему программа не получает отказа в памяти, чтобы нормально завершить работу?

но почему программа не получает отказа в памяти

Кто мы такие, чтобы отказывать программе? Тем более, если памяти у нас хоть попой жуй, виртуальной. Не попой виртуальной, а памяти виртуальной у нас немерено.

Программа запрашивает лишнюю память - ядро не дает - программа не умеет обрабатывать событие «мне не дают памяти» - смерть.

Потому что программа начинает кушать память настолько активно, что отзывчивость и стабильность системы может оказаться под угрозой, поэтому ядро увидев такую ситуацию высылает к такой программе OOM Killer, который убивает её выполнение.

Не совсем верно. Как раз такую ситуацию разрулить несложно.

Процесс память как раз получил, но когда начинает её использовать, то получает уже отлуп, а такую ситуацию в принципе разрулить не очень получится.

Про OOM Killer уже написали, про логику его работы и способ настройки можно почитать в доках ядра: https://docs.kernel.org/filesystems/proc.html#chapter-3-per-process-parameters

почему программа не получает отказа в памяти, чтобы нормально завершить работу

В общем и целом нет такого механизма оповестить процесс о том, что уже выделенную ему память ядро выдать не может.

Имя, ~сестра~, имя программы в студию!

Я все еще не могу к этому привыкнуть. В «пр…ом» Windows этой проблемы не было. Там просто получал NULL и дальше продолжал работать без всяких неконтролируемых падений

Кто-то ее убил.

у попа была собака …

Спасибо - ОЧЕНЬ ценное замечание

В «пр…ом» Windows этой проблемы не было. Там просто получал NULL и дальше продолжал работать без всяких неконтролируемых падений

В Linux тоже так можно, если задавать приложениям (или группам) лимиты по памяти.

если задавать приложениям (или группам) лимиты по памяти

А разве в этом случае будет так как хочет ТС? Программу просто будут убивать по превышению лимита.

Где об этом можно посмотреть?

Понятно, что программу убивают при нехватке памяти, но почему программа не получает отказа в памяти, чтобы нормально завершить работу?

По тому же, почему вам продолжают выдавать билеты МММ когда реальных денег уже нет. В Линуске программам выдают не настоящую память и даже не место в файле подкачки, а фикцию (называемую overcommit). И подло убивают когда программа начинает качать права.

Угадал коммент X512 до перехода в топик.

С позиции системного подхода, убивать программы намного безопаснее, чем выдавать им NULL.

Потому что большинство программ не имеют отлаженных code paths для этих ситуаций и могут вести себя чёрт знает как.

Программу просто будут убивать по превышению лимита.

Нет, при превышении лимита malloc будет возвращать ноль

В Линуске программам выдают не настоящую память и даже не место в файле подкачки, а фикцию (называемую overcommit). И подло убивают когда программа начинает качать права.

В системе, завязанной на CoW, делать по-другому не имеет смысла, так как предсказать реальное использование физической памяти наперед невозможно. К тому же, оверкоммит позволяет использовать оперативку эффективнее и выделять больше памяти для кэша файловой системы (который здесь, в отличие от винды, реально работает)

Где об этом можно посмотреть?

help ulimit, man cgroups (и соотвествующие доки ядра)

Все это прекрасно, но для точного расчета данному алгоритму требуется уева прорва памяти, которой изначально нет у сервера. Поэтому задаются ограничения на количество учитываемых элементов. И если на заданное ограничение не хватает памяти, то пользователь усиливает это ограничение. В процессе этих приближений осуществляется поиск «оптимального» баланса между точностью вычисление и возможностями машины по памяти и времени. Т.е. то, что памяти нет - это не страшно, просто программа должна продолжать работать

Спасибо

В системе, завязанной на CoW

Уже давно нет. Времена когда Apache делал fork при обработке каждого нового соединения давно прошли.

А тот факт, что вся остальныя система работает на форках, как бы не смущает

Нет, дело не в этом. Но ты прав, из-за низкого качества софта запретить overcommit не всегда возможно. А именно, некоторый софт выделяет себе кучу памяти про запас (зная, что ему не откажут), но по факту не использует её. С overcommit-ом эта память так и остаётся неиспользованной, а без него кривой софт упал бы из-за невозможности получить ненужную ему память.

И да, Apache с mod_php все еще делает форк для каждого запроса

Нет, не работает. Давно изобрели posix_spawn (или exec сразу после fork). Почти любое сложное приложение или библиотека упадёт в SIGSEGV после fork потому что на него не рассчитано. Надо реализовывать обработчики atfork что не все делают.

Какой-то анахронизм. PHP давно умеет обрабатывать множество запросов в том же самом процессе.

из-за низкого качества софта запретить overcommit не всегда возможно.

Дело не в низком качестве софта. Современный софт использует кучу динамических библиотек, из которых зачастую используется только небольшая часть кода, и/или они используются для редко используемых функций. Сравни размеры vmsize и rss десктопных приложений, первое может легко превышать второе в несколько раз. Если оверкоммита нет, то под размер всех этих библиотек системе придется резервировать память, вместо того, чтобы использовать ее для чего-то полезного (других программ или кэша ФС).

В добавок, некоторые программы работают с файлами через mmap, для под полный размер этих файлов тоже придется резервировать память.

Давно изобрели posix_spawn (или exec сразу после fork).

posix_spawn мало где используется. Типичный способ порождения процессов - это 1) fork; 2) код для настройки ввода-вывода и IPC с родителем; 3) exec. fork в этом сценарии обязан выполняться быстро, а не копировать всю память процесса, как винда.

Почти любое сложное приложение или библиотека упадёт в SIGSEGV после fork потому что на него не рассчитано.

Ну это лол просто.

Согласен. Возможно наш софт - кривой.

Тогда предложи решение для ситуации, когда требуемый объем памяти заранее неизвестен. Известно только что ее не хватит для полного решения задачи. Нужно динамически выполнить ограничения размеров обрабатываемых данных. Но это возможно только если программа не падает.

Ну это лол просто.

Ну покажите что будет например с браузером после fork()? Думаете будет два окна браузера? Нет, будет SIGSEGV.

Ага, это из-за библиотек фф занимает 2.6гб виртуальной памяти при 700мб физической.

Ну для специфических случаев оверкоммит можно и выключить. А для общего случая он оптимален.

Кроме того, ничто не мешает программе получать у системы информацию о свободном объеме памяти и оценивать, хватит ли её для заданных условий работы.

Думаете будет два окна браузера?

Конечно нет. И две дырки в розетке не для пальцев.

И как получить " у системы информацию о свободном объеме памяти"? Пожалуйста подскажите

Короче fork() без последующего exec() реально применим разве что для простых однопоточных приложений вроде bash.

ничто не мешает программе получать у системы информацию о свободном объеме памяти и оценивать, хватит ли её для заданных условий работы.

Это крайне ненадёжное решение.

Я всё жалею, что среди реакций нет ржущего смайла. Самый востребованный смайл на ЛОР.

В «системе, основанной на CoW» вообще вся виртуальная память основана на CoW. Что ты к форку прикопался?

Вроде же есть системные знания, а мозг включить не можешь, где-то во временах Windows 3.1 пребываешь относительно механизмов управления памятью.

Повторяю, что на CoW основаны разве что консольные программы из прошлого века. В современных высокопроизводительных программах так не делают. Вы видимо застряли в прошлом когда Apache делал fork() в accept() и лучшего решения ещё не знали.

Не надо делать глобальных выводов из своего неумения пользоваться fork-ом. И слово «применим» тут не в тему. Он используется там где он нужен, со всеми нужными обвязками.

Потому, что когда программа запрашивает память, ядро не ожидает, что она её действительно будет использовать.

А если вдруг попытается, а памяти нет, то прибивает.

Так устроено управление памятью в линуксе.

Это можно отключить. Называется overcommit. Но обычно не отключают.

Я всё жалею, что среди реакций нет ржущего смайла. Самый востребованный смайл на ЛОР.

Используй фейспалм.

Панятна. Насчёт системных знаний я ошибся, значит.

Элементарный MAP_PRIVATE основан на CoW. Читай документацию.

Лучше всего вручную задавать предел. Потому как всё-таки не дело программе агрессивно сжирать всю память, которая плохо лежит.

Спасибо