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

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

Не я считаю надо в zram сделать zswap а в нём опять разместить zram чтобы получить ещё больше zswap в котором опять…

сервер-oldcache + сервер-newcache + сервер-роутер/ротатор ?

а если написать сервер, который просто выделит в RAM 64-битной системы Достаточно Большой Кусок памяти, и будет аллоцировать/отдавать там по своему разумению, и вот это «по своему разумению» уже написать под конкретные нужды?

Сделай вдоль, не мучайся.

Но вот когда файлы меняются мало и они мелкие — может быть эффективно

Это само собой, ТС же спрашивал про 1кк грязных данных в секунду.

There are only two hard things in Computer Science: cache invalidation and naming things.

Кстати, другая песочнича, но может будет интересно почитать: http://www.tedunangst.com/flak/post/2Q-buffer-cache-algorithm

Можно сделать копию в tmpfs, а потом через bind прибиндить к нужным каталогам. Или блочное устройство в память при запуске загружать как рутовую ФС.

> не работает так ядро Linux ?

По-моему, нет.

если так, то печально..

конкретней некуда, все пилилось ради переноса в оперативу. ни само по ни сама работающая база с диском никак не соприкасалась. Стратанул велосипед с диска и дальше только синк. Но если ты всегда хочешь оставить последнее слово за собой, то да, поищи в ОЗУ еще какой смысл.

RapidDisk 2.8 Stable release

Как видишь, результат получился хуже

а почему? дисковый кэш быстрее чем tmpfs? почему?

Есть указатель на массив байт, в котором находится полная структура ELF

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

Можно сделать vmtouch на бинарник и нужные ему файлы. Если памяти достаточно то после этого обращения к этим файлам не выховут обращений к HDD/SSD или что там. Ибо дисковый кэш.
С тем-же успехом можно использовать cat file > /dev/null, но vmtouch позволяет до хучи посмотреть всякую интересную инфу про жизнь этого файла в дисковом кеше.

Полезность этого всего сомнительна, при наличии излишком ОЗУ после первого чтения файл и так осядет в кеше.

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

интереса ради сравнил

1048576000 bytes (1.0 GB) copied, 0.1475 s, 7.1 GB/s

у меня же древняя медленная оперативка, как это работает? в файле был urandom, так что дело явно не в сжатии нулей.

посаны бенчим контроллер памяти у меня 30см в холодной воде

Варниш?

fadvise?

Если к данным обращаются часто, то разве они будут успевать выгружаться? Ну то есть пока старыми данными будет забиваться кеш не случится ни одного обращения к новым данным, которое продлит их жизнь в кеше? При некотором объёме оперативке (меньше, чем объём данных) должно так происходить и всё будет хорошо. Либо новые данные не такие уж и популярные.

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

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

— 1Гб «свежих» данных, в виде 100 тыс. файлов по 10 кб, к которым идёт 50% обращений и которые хочется отдавать мгновенно, поскольку 99% реальных посетителей пользуются ими. Скажем, если такие файлы запрашиваются 10 раз в секунду, то в среднем к одному файлу идёт обращение раз в 3 часа.

— 100Гб «старых» данных (при тех же пропорциях это 10 млн. файлов), которые не только можно не кешировать, а прямо не нужно, ибо к одному файлу обращение будет происходить при той же частоте лишь раз в пару недель.

Так вот, прикол в том, что вторые пресловутые 100Гб «старых» данныз за эти 3 часа, которые пройдут между обращениями к одному файлу из 1Г «новых» данных напрочь выбивают последние из кеша.

Цифры очень примерные, но суть отражают.

Из той же оперы — вот, например, много ли весит вся обвязка ssh+bash? Да копейки. Однако, она быстро выбивается из кеша и при повторном обращении к нагруженному серверу проходят утомительные несколько секунд (а когда нагрузка очень высокая — невыносимые десяток-другой секунд), пока файлы прочитаются с диска. А как было бы здорово, если бы можно было закешировать принудительно соответствующие файлы.

munin запускается раз в 5 минут. Весит вся его подсистема копейки. Но файлов там много, раскиданы как попало. За 5 минут успевают выбиться из кеша (в первую очередь пресловутыми «100Гб старых») и раз в 5 минут создают приличную нагрузку на дисковую систему, пока всё это барахло прочитается с дисков (активно загруженных!) с нуля.

И так много ещё где... На машинах по 16 или 32Гб оперативки, выделить 2-4Гб под «персистентные» кеши — не вопрос. Но, увы, простых решений нет :-/

fadvise?

Но это системный вызов, как я нагуглил. Какое отношение он имеет к прикладным проблемам имеющегося софта?

Так вот, прикол в том, что вторые пресловутые 100Гб «старых» данныз за эти 3 часа, которые пройдут между обращениями к одному файлу из 1Г «новых» данных напрочь выбивают последние из кеша.

<br/><br/> Ну хорошо, и как лечишь эту проблему?

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

удаление, вещь весьма посредственная. Бинарник не загружается в раму сразу весь и целиком, а мапится, и в последствии доступа к страницам подгружается с файла. Ты то файл удалишь, но в реале он не удалится, просто станет не видимым для файловой системы. А когда программа завершится, память анмапится и закроется дескриптор - вот только тогда участок на диске пометится как dirty.

Ну хорошо, и как лечишь эту проблему?

Пока в лоб — никак. Только косвенно, например, перетащил часть «старых» данных на другой сервер, перевёл раздел с активными данными под reiserfs (у неё с кешированием в таких условиях, похоже, лучше, чем у ext4), сегодня посмотрел в сторону RapidCache, но как-то не то... Скорее всего подумаю о размещении части «новых» данных в tmpfs с синхронизацией с hdd через lsync.

А если в рамдрайве размером 1-2Гб «новые» разместить и научить сам движок форумов (я так понимаю о них речь) там кешировать?

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

Ты вообще понял как его юзать?

Как я понял по http://www.rapiddisk.org/?page_id=15#rapidcache создаётся рам-диск (например, rxd0), мапится на физический раздел, появляется кеш-раздел (/dev/mapper/rxc0), с которым уже и работаешь.

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

> sudo modprobe rxdsk
modprobe: ERROR: could not insert 'rxdsk': Exec format error

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

Exec format error

С разрядностью всё ок? 32/64 бита в системе и в модуле соответствуют?

Ну и еще у меня модуль не грузится

Я так даже заморачиваться не стал, увидев, что в родных репах и ppa/layman в ubuntu и gentoo этого пакета нет :) Тем паче, что сейчас в первую очередь именно в Gentoo нужно.

куплю маленький ssd, перекину что надо на него, и симлинками суну в места где оно должно быть

ssd можно попробовать заюзать с чем-то типа bcache. А, вообще, интересная идея. Если с bcache, то надёжность SSD не так актуальна и можно попробовать взять что-то сверхдешёвое китайское. Что-то типа 32Гб за $28 или 64Гб за $40. Как раз для системы маловато будет, а для кеша — в самый раз.

Для bcache надо форматировать винты как я понял. Причем и хомяка и /. А не хочется. С симлинками я могу сделать это без форматирования и получить полный контроль над тем что «кэшируется». Проблему надежности можно решить с помощью megasync или wuala.

для системы маловато будет

У меня на 16-гигабайтный SSD влезает корень (без отделённых /usr и /var) и своп.

$ df /
Файловая система Тип     Размер Использовано  Дост Использовано% Cмонтировано в
/dev/sdb2        reiser4   9,6G         4,3G  5,3G           45% /

ЧЯДНТ?

Ну у меня ситема бы тоже влезла. Но надо еще конфиги выдернуть. Вот взять Komodo Edit - он в работе приображается если его конфиги в tmpfs сидят. А мне как раз его ускорить и надо.

ЧЯДНТ?

«Для системы» — это в смысле с терабайтом файлов и с полусотней гигов БД :) Так-то систему и в 500Мб засунуть можно.

bcache, похоже, пофиг, что за девайс кешем использовать. Главное, чтобы блочные девайсы были. Сейчас закешировал на пробу lvm-раздел через ramdisk.

Только для нормальных тестов не пойму пока как задать размер /dev/ram0, по дефолту 67Мб и всё. Для кеша маловато будет :)

Ааа...

И что, с такими объёмами кэш в 32-64 гигабайта будет полезен?

И что, с такими объёмами кэш в 32-64 гигабайта будет полезен?

Да, когда постоянно из них регулярно читаются 1-3Гб файлов и 10-30Гб БД.

бенчим контроллер памяти

Контроллер памяти бенчится не так, а так:

$ dd if=/dev/zero of=/dev/null bs=1M count=1000
1000+0 записей получено
1000+0 записей отправлено
 скопировано 1048576000 байт (1.0 GB), 0.080558 c, 13.0 GB/c

в файле был urandom, так что дело явно не в сжатии нулей

Точно был? Показывай как запускал.

dd if=/dev/urandom of=~/tmp/test bs=1M count=1000

и трижды чтение файла после сброса кэшей

~ $ dd if=~/tmp/test of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 9.86776 s, 106 MB/s
~ $ dd if=~/tmp/test of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.185372 s, 5.7 GB/s
~ $ dd if=~/tmp/test of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.1475 s, 7.1 GB/s

Прикольно на ФС со сжатием:

# dd if=/dev/zero of=/root/test bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.300273 s, 3.5 GB/s

# dd if=/root/test of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.343222 s, 3.1 GB/s

железо совсем слабое, на нормальном должно быть быстрей

Ну, эта, хрен его знает, товарищ майор, в чём тут дело. Кстати, про совсем слабое железо ты что-то темнишь - первое чтение 106Мб/сек, это как бы далеко не слабый показатель.

Прикольно на ФС со сжатием:

А без сжатия как?

/dev/zero

Со сжатием? Читер.

Это даже для HDD слабенький показатель. Вот мой старый Seagate:

# dd if=/dev/zero of=/media/mix/test bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 1.82472 s, 575 MB/s

# dd if=/media/mix/test of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 8.6169 s, 122 MB/s

575 MB/s

Шта? Это обычная Ext4, откуда 500 метров в секунду?

откуда 500 метров в секунду

/dev/zero

Я же говорю - читер. Нули не записываются же.

Если есть возможность поправить код софта, почему бы и нет.

http://linux.die.net/man/2/posix_fadvise

Вот не нули:

# dd if=/dev/urandom of=/media/mix/test bs=1M count=1000 
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 57.8077 s, 18.1 MB/s

# dd if=/media/mix/test of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 6.7259 s, 156 MB/s

Это Ext4 на Seagate.

А это чтение того же файла с SSD + Btrfs:

# dd if=/root/test of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 3.7226 s, 282 MB/s

И запись туда же с tmpfs (чтобы тормоза HDD не мешали):

# dd if=/dev/shm/test of=/root/test bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 2.87154 s, 365 MB/s

Учитывая, что заявленная производителем скорость чтения моего SSD на уровне 250 Мб/сек, можно сделать вывод, что сжатие даже на SSD даёт прирост в скорости.

P.S. Кстати, а что мы тут меряем вообще? -))