[cache][вещества] возможно ли настроить кэш?

хочешь, можно попробывать совместными усилиями сделать либу.

да не кодер я (

Он сделал огромный вклад в развитие highload, разбирается в архитектуре современных ОС очень очень хорошо(и не только в фряхе, хотя в ней лучше всех и на то есть причины).

В чём его унолость и что сделал ты для opensource?

Ну а тестером будешь?

а теперь смотри сюда!
торрент работает всегда! сколько он памяти ест мне глубоко пох!
а вот то что он засирает кэш вытесняя полезное из него - не есть гуд!
просветление снизошло? догнал о чём говоришь ты и о чём я?

хм...можно :)

сделай торрентам низкий приоритет I/O

man ionice

Это решит твои проблемы.

>просветление снизошло?

Нет...

у него при запуске задаётся минимальный приоритет
не надо костылями кидаться - я о них всех знаю...

понимаешь разницу между памятью занятой софтиной(RSS) и кэшем?

> возможно ли запретить кэшировать мусор некого конкретного приложения?

В смысле чтобы приложение, которое активно работает с диском не мешало другим приложениям вымывая из оперативной памяти их данные?

Самое первое, что может придти в голову - использовать для таких приложений отдельный компьютер.

Другой вариант посложнее - нужно научится делать прямое чтение с диска/запись на диск, минуя общий кэш операционной системы + создать для приложения свой собственный кэш в оперативной памяти со своими политиками вытеснения данных и т.д. Также нужно будет создать непрерывный файл на диске собственного размера и придумать способ хранения своей информации в этом файле. Опционально можно научится писать напрямую в сырые разделы. Процессом чтения/записи должны заниматься отдельные процессы, причем они должны синхронизировать свою работу с работой приложения и с работой операционной системы.

Собственно это путь по которому идут все базы данных. Для них не подходит стандартный алгоритм кэширования данных, поэтому они создают свой кэш и применяют свои собственные алгоритмы управления этим кэшем. Честно говоря никогда не задумывался над тем, как им удается (и удается ли?) читать/писать данные минуя обычный кэш операционной системы.

ТО, что ты хочешь — глупо. В любом случае, страницы дискового кэша синхронизируются через весьма короткое время (десятки секунд), за это время даже в потоке диск считает жалкие сотни мегабайт. Единственный железхный способ удержать данные, например, браузера в памяти — это запускать его с профилем, лежащем на tmpfs

да! об этом я и говорю :)
вот и интересуюсь - есть ли готовые варианты?

Для того, что тебе нужно - есть рамдиск. Т.е. копируй /usr/{bin,lib,share} в раму и запускай оттуда. Profit.

это не глупо!
если не понял чего я хочу - перечитай тред!
З.Ы. как же достали «Ъ» которые даже не пытаются думать...да куда там - даже читать!

Думаю, 1G на основное хватит.

это неугодный мне костыль!
ибо это мягко говоря не гуд при отрубании напруги например

не хватит!
если тока пожать чем...

Можно еще посмотреть в сторону виртуальных машин.

Честно говоря просто не знаю, будет ли кэшироваться образ диска гостевой операционки в кэше операционки хозяина. Если не будет - то решение готово. Будет просто достаточно запустить прохорливую до диска программу в гостевой операционке в виртуальной машине.

Самый вменяемый вар-т, уже советовали. В livecd так сделано.

не - это сильно жёстко...даже жестоко %)

Прибавит тормозов только.

НЕвменяемый!
лайф одно, а комп 24/7 совсем другое
и кстати - при чём здесь кэш?

> Прибавит тормозов только.

Ну правильно. Цель ведь в этом и состоит - прибавить тормозов одной программе, чтобы она не мешала другим.

>Ну правильно. Цель ведь в этом и состоит - прибавить тормозов одной программе, чтобы она не мешала другим.
не правильно!
перечитывай тред!

Какая разница то? Копировать в раму, а не перемещать же. Пусть свет хоть раз в пять минут вырубают, пох.

ок - а как быть с софтом?
держать их в вечном свопе?
увольте!

>держать их в вечном свопе

Т.е.? Ну докупи рамы. У меня меньше гига ни на одном компе нет.

Отключения кэша для какой-либо программы равносильно Direct I/O всех ее запросов. Знаешь, к чему это приводит? К тормозам, потому что любой запрос проги приводит к немедленной постановке его в очередь ввода-вывода, а поскольку кэш у винчестера очень мал, увеличится число дерганий головок в поиске нужной информации на пластине. As a result, даже проги, которые будут редко обращаться к диску (работая исключительно из кэша) будут вынуждены ждать долго-долго, пока очередь ввода вывода не дойдет до них.

Единственный железный способ, повторяю, сделать большую tmpfs, размерами близкую к размеру оперативной памяти и запихать в нее как можно больше прог. Тогда оставшимся дискового кэша в памяти не достанется и они будут работать напрямую с диском (не сами, конечно, но ведро заставит). Ах да, не забудь отключить своп тогда.

> Ну правильно. Цель ведь в этом и состоит - прибавить тормозов одной программе, чтобы она не мешала другим.

Приоритеты I/O и никак по-другому!

>Отключения кэша для какой-либо программы равносильно Direct I/O

НЕТ! Меня уже здесь в это носом ткнули!

>Отключения кэша
вообще то я рассматриваю и вариант настройки кэша - т.е. отдать торрентам всего 200-500 метров - чтоб остальной кэш был забит нужным!

direct I/O для одной проги можно сделать подменой системной библиотеки через LD_PRELOAD на обертку, которая будет ко всем вызовам open() добавлять флаг O_DIRECT. В принципе, не так уж и сложно реализовать, но повторяю, результатом будут адские тормоза, поскольку очередь ввода-вывода на винчестере (если он один) — одна.

>Ну докупи рамы.
ппц!
на каждый чих апгрейд вместо настройки?
вин-стайл же )
и да - итак 2 гига - 3 смысла нет, а >=4 логичнее 64 ставить - лень )

та не нужно мне прямое чтение!!!
мне нужно урезать кэш!
и неважно - для софтины или для директории - последнее даже лучше

>> Ну правильно. Цель ведь в этом и состоит - прибавить тормозов одной программе, чтобы она не мешала другим.

Приоритеты I/O и никак по-другому!

Говоря «прибавить тормозов» я имел в виду не тупое добавление sleep куда-нибудь в цикл - а именно организацию такой работы, когда программе дается меньше ресурсов - например, меньше кэша + ограничивается количество данных, которое она может считать/записать в единицу времени.

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

> очередь ввода-вывода на винчестере (если он один) — одна.

однозначно такой программе потребуется свой отдельный физический диск + свой собственный кэш + пусть она сама читает напрямую без всяких оберток.

и как ты себе представляешь тормоза?
сейчас к диску обращается аж...только торрент! )
ну и несколько байт/килобайт иногда скидывает арбузер в профиль - ФСЁ!
откуда тормоза-то?

ionice, nice это.

Только прямое чтение гарантирует отсутсвие кэширования страниц, ибо, насколько мне известно, на уровне VM нет привязки страниц к процессам.

>ТС, ты не понимаешь
да ну на!?
почитай чуть ниже каммент - к диску и так обращается тока торрент! а когда меня нет за компом - так тем более - откуда ещё геморы с очередью?
З.Ы. всех четвертовать!

>на уровне VM нет привязки страниц к процессам.
ну неужели!? :)
наконец-то начинаешь понимать чего мне надо! :)

>и как ты себе представляешь тормоза?

сейчас к диску обращается аж...только торрент! )

тормоза оттуда, что если сейчас ему доступна для кэша ВСЯ оперативная память, то после его ограничения ему будет доступен меньший объем памяти. В общем случае меньше кэш -> больше тормоза.

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

Почитай тогда

http://www.kneuro.net/linux-mm/index.php?file=pagecache.html

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

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

кстати раз речь про vm - немного офтопа
можно ли и как уменьшить приоритет для kswapd?
патчи-хаки-кряки - не суть важно...

>но я лучше ядра знаю что есть мусор, а что есть нужное!

мальчик, может, ты и ядро сам напишешь?

>можно ли и как уменьшить приоритет для kswapd
for i in `pidof kswapd0`; do ionice -c XXX -p $i; done

спасибо