Можно ли ограничить размер файлового кэша в ядре 3.0?

Ситуация:
2ТБ памяти в системе.
Процессы потребляют 1.6ТБ
Все хорошо, пока не начинаем копировать большие файлы на другой сервер по сети.
Через некоторое время кэш подъедает оставшиеся 400ГБ и приложение начинает дико тормозить.
Тормозит оно даже после того, как копирование прервано.
Система подъедает свободную память почти до нуля, но отзывать страницы из кэша не торопится.
Причем речь не о грязных блоках.

Пока не сделали
echo 1 > /proc/sys/vm/drop_caches
не полегчало

Спасибо.
По ссылкам вышел вот на это
Похоже swappiness и vfs_cache_pressure - то что нужно крутить как раз.

Мутагенcgroups может, но был ли он в винтажном релизе 3.0 я не помню
на мой взгляд, это извращение
Я то хотел чтобы менеджер памяти в принципе работал иначе.
Зачем мне половина памяти в буферах и своп аут процессов при этом?

netwindИ, кстати, самый простой способ - просто не спешить чтобы процессы успевали память пометить как нужную.
То есть, просто копировать данные с помощью rsync --bwlimit.
Не очень понимаю, как bwlimit помешает ядру прибрать всю неиспользуемую память под кэш чтения.

Я же описал ситуацию: система набрала в кэш, файлы считаны один раз, операция завершена уже около часа, но память не освобождается.
Короче это должно помочь. 18110413

я делаю проще
echo 3 >/proc/sys/vm/drop_caches
То что free не растет - вполне естественно для *NIX систем, однако странно не это, а то, что в условиях дефицита памяти буфера не освобождаются.
Обидно за свое решение?
Скажите мне как оно будет работать если система в принципе не чистит буфера без пинка от души?
Какая разница, ограничиваю я скорость передачи данных, читай наполнения кэша, или нет, если и по прошествии часа приложение испытывает затруднения при запросе памяти.

Как ядро узнает что ему нужно а что нет?
Вот именно про рычаги, заставляющие принимать подобные решения я и спрашивал.
Можно заставить ядро делать выбор либо в пользу своп аут на диск памяти процессов либо в пользу жертвования the most rarely used страниц в буферах файлового кэша.
Можно заставить ядро начинать бить тревогу не при 1ГБ свободной памяти для начала процесса компактинга фрагментированной памяти, а при раз в 10 большем количестве.
Можно обозначить разумный таргет для файловых буферов, до которого в случае дефицита кэш будет схлопнут.


Какое приложение? С трудом верится в объем?
SAP HANA.

какой же ты упорный, блин

я не стану никого убеждать в том, что иногда дефолтное поведение системы необходимо менять, потому что универсальных настроек под любую конфигурацию и любое приложение не существует.
Можешь сказать под какую систему десктоп/файлсервер/сервер БД/сервер приложений и под какую аппаратную конфигурацию заточены дефолт тюнаблс в линуксе?