Попытка выделения не имеющегося количества памяти и убиение приложения.

1. http://mmonit.com/monit/
2. хз

2. потому что пишется core dump

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

Да, очищает. Но обратно в кеш файлы грузятся, когда к ним есть обращение. Я думаю, тут другое - начинается эффект «отсутствия кеша». Т.к. кеш имеет размер не постоянный, а просто равен объёму никем не выделенной памяти, то когда приложение выделяет всю память, размер кеша становится нулевым.

1. Вот на что конкретно нулевой размер кеша так негативно влияет?

2. Как гарантированно оставить некоторый объём памяти под этот кеш?

> 1. Вот на что конкретно нулевой размер кеша так негативно влияет?

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

Слушай, так динамические либы вытесняемы из памяти значит? Я думал, они неприкасаемы, пока ссылок на них не станет = 0...

они не вытесняемы, если нет файла подкачки. Куда их вытеснять-то?

Вытеснять - не куда-то, а из чего. Они уже хранятся в свопе - это /usr/lib/. Это их своп. Они в памяти не отличаются от этого «свопа». Так что, «своп» у НИХ есть )))

Откудова у них своп? Ядро без виртуальной что ли будет выкидывать из памяти куски работающего кода и потом их читать из файлов обратно? Всё ради какого-то жадного до памяти процесса? И как оно это сделает технически?

Что значит ради какого-то? Ядро и существует, чтобы процессы запускать.

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

Однако Вы какую-то полную херню писать начали. Сам Линус не поймёт.

Он правильно написал, хотя немного сумбурно и слишком образно. Идея такая: в условиях нехватки памяти можно выкинуть из нее код разделяемых библиотек. А когда он понадобится — считать его заново из файла на диске.

2. Почему при достижении лимита свободной памяти, после которого приложение убивается, целых 30 секунд перед моментом убийства приложения, сходит с ума HDD? Свопа нет )

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

Идея такая: в условиях нехватки памяти можно выкинуть из нее код разделяемых библиотек. А когда он понадобится — считать его заново из файла на диске.

Ядру по*ер что у вас там, оно хоть всё может выгрузить, кроме себя.

>Идея такая: в условиях нехватки памяти можно выкинуть из нее код разделяемых библиотек

И как же ядро догадается, что эта память относится к коду библиотек? У ядра Линукса 2 механизма виртуальной памяти? Один в целом для памяти, а второй специальная виртуальная память для кода библиотек при отключенной основной?

> И как же ядро догадается, что эта память относится к коду библиотек?

У mmap есть флажок MAP_SHARED.