LINUX.ORG.RU

Подскажие материалы о работе дискового реширования

 , , ,


1

4

Собственно, интересует как работает дисковый кеш на онтопике в деталях, а именно:

1) До какого предела можно заполнить дисковый кеш? Имеется ввиду сколько максимум свободной памяти он может занять?
2) Как часто или по каким критериям dirty pages синхронизируются с диском?
3) Происходит ли кеширование при операциях, не связанных с непосредственным вводом-выводом? Имеются ввиду не read()/write(), а open(), access(), stat().
4) Остаются ли данные в кеше после того, как выполнен write(), и данные УЖЕ записаны на физический диск?

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

5) Аналогичный вопрос, происходит ли кеширование при O_SYNC? А при O_DIRECT? А при O_SYNC | O_DIRECT ?
6) Как вытеснить имеющийся кеш без применения всяких там «echo 3 > /proc/sys/vm/drop_caches». Слышал истории о том, мол, что кеш в современных ОС сделан умно, и потому чтение раз в пару часов к маленькому файлу не приводит к тому, что этот файл попадает в кеш. Собственно, интересует как вытесняется кеш чтением и записью в теории и на практике.


Через гугл инфы достаточно получить не удалось, мб. я не так искал?

★★★★★

и потому чтение раз в пару часов к маленькому файлу не приводит к тому, что этот файл попадает в кеш.

Что-то я про такое не слышал. Есть posix_fadvise(), но приложение должно само просить не кешировать.

mky ★★★★★ ()

1) теоретически ограничивает vm.pagecache и vm.min_free_kbytes

2) vm.dirty_writeback_centisecs, vm.dirty_expire_centiseconds, vm.dirty_background_ratio, vm.dirty_ratio вполне хорошо описаны в гугле по «linux vm pdflush»

3) чтение каталогов точно кешируется. Кеширование метаданных выглядит логично.

4) если память не попросят процессы, то останется.

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

Есть интересная утиль linux-ftools/fincore

vel ★★★★★ ()
Ответ на: комментарий от mky

Когда-то давно я читал некую статью от яндекса о том, что якобы в веб серверах на freebsd вытеснить кеш гораздо труднее, чем с аналогичными настройками под linux. Как сейчас не знаю.

Вообще да, такие файлы я бы и открывал бы с O_SYNC | O_DIRECT, но суть вопроса в логике работы самого кеша.

reprimand ★★★★★ ()

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

Harald ★★★★★ ()
Ответ на: комментарий от vel

Вау! Спасибо большое :)

чтение каталогов точно кешируется

что имеется ввиду? Когда мы делаем какой-нибудь opendir, в кеш попадает весь список файлов? Или файлы с метаданными? А когда я делаю просто open() на маленьком файле (до 100 байт), данные кешируются? Я бы посмотрел в код ведра, но оно такое сложное и запутанное, что даже хз...

reprimand ★★★★★ ()
Ответ на: комментарий от Harald

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

Этой фразой можно отвечать на любой вопрос в техразделах. Мол, «прочитай исходники xxx, получишь все ответы».

reprimand ★★★★★ ()
Ответ на: комментарий от reprimand

Можно документацию идущую с ядром почитать, и там будет как минимум часть ответов.

anonymous ()
Ответ на: комментарий от reprimand

Если верить документации про drop_caches - то кеширование метаданных (dentry) и данных разделено.

Есть смысл собрать и посмотреть утиль fincore

vel ★★★★★ ()
Ответ на: комментарий от reprimand

Ну уверен, что в кеш попадёт всё содержимое каталоге (весь список файлов), ведь зачем-то у каталога может существовать индекс.

Можете написать тестовую программу, которая запоминает содержимое /proc/meminfo до/после интересующих вас операций и позапускать её в однопользовательском режиме на разных файлах/каталогах.

mky ★★★★★ ()
Ответ на: комментарий от vel

Есть смысл собрать и посмотреть утиль fincore

Я так понимаю, имеется ввиду вот это, да?
http://code.google.com/p/linux-ftools/

Если верить документации про drop_caches - то кеширование метаданных (dentry) и данных разделено.

Если не сложно, можно ссылку на ту документацию и её часть которую вы имеете ввиду?

reprimand ★★★★★ ()
Ответ на: комментарий от mky

Можете написать тестовую программу, которая запоминает содержимое /proc/meminfo до/после интересующих вас операций и позапускать её в однопользовательском режиме на разных файлах/каталогах.

Что имеется ввиду под однопользовательским режимом?

Я написал тестовую программу, но, чувствуется, что для чистоты эксперимента следует убить все сторонние программы, активно использующие ресурсы ОС, а лучше вообще запускать в чистой безгуёвой ОС под виртуалкой... Ибо результаты неоднозначные.

reprimand ★★★★★ ()
Ответ на: комментарий от reprimand

http://code.google.com/p/linux-ftools/

да

Если верить документации про drop_caches - то кеширование метаданных (dentry) и данных разделено.

Если не сложно, можно ссылку на ту документацию и её часть которую вы имеете ввиду?

grep -A11 ^drop_caches linux/Documentation/sysctl/vm.txt

vel ★★★★★ ()
Ответ на: комментарий от reprimand

Ну примерно это и подразумевалось, раньше, когда был initd, был runlevel называемый single user mode, когда в списке процессов, кроме процессов ядра, только init и sh.

mky ★★★★★ ()
Ответ на: комментарий от mky

Если интересно, я тут провёл два теста. Перед каждым я, естественно, дропал кеш.

Первым тестом я создал 100 тысяч файлов по 4111 байт каждый. Т.е. в цикле было open(), write(), close(). Всё попало в кеш, ничего интересного.

Вторым тестом я лишь открывал файлы. Открывать получалось пока не упёрся в лимит файловых дескрипторов (1024 вроде). Результаты такие:

Start results:
MemTotal:        8122968 kB
MemFree:         7911472 kB
MemAvailable:    7850080 kB
Buffers:             916 kB
Cached:            32484 kB
SwapCached:            0 kB
Active:            66404 kB
Inactive:          10156 kB
Active(anon):      43464 kB
Inactive(anon):     2676 kB
Active(file):      22940 kB
Inactive(file):     7480 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                72 kB
Writeback:             0 kB
AnonPages:         43456 kB
Mapped:            29340 kB
Shmem:              2684 kB
Slab:              42868 kB
SReclaimable:      15736 kB
SUnreclaim:        27132 kB
KernelStack:        3424 kB
PageTables:         4768 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     4061484 kB
Committed_AS:     292364 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      128304 kB
VmallocChunk:   34359604988 kB
HardwareCorrupted:     0 kB
AnonHugePages:      4096 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      366252 kB
DirectMap2M:     7968768 kB

======================
After opening huge amount of files:
MemTotal:        8122968 kB
MemFree:         7908852 kB
MemAvailable:    7848852 kB
Buffers:            3752 kB
Cached:            32180 kB
SwapCached:            0 kB
Active:            69244 kB
Inactive:          10156 kB
Active(anon):      43520 kB
Inactive(anon):     2676 kB
Active(file):      25724 kB
Inactive(file):     7480 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                72 kB
Writeback:             0 kB
AnonPages:         43540 kB
Mapped:            29340 kB
Shmem:              2684 kB
Slab:              42868 kB
SReclaimable:      15736 kB
SUnreclaim:        27132 kB
KernelStack:        3440 kB
PageTables:         4824 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     4061484 kB
Committed_AS:     292364 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      128304 kB
VmallocChunk:   34359604988 kB
HardwareCorrupted:     0 kB
AnonHugePages:      4096 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      366252 kB
DirectMap2M:     7968768 kB

======================

P.S. opendir, судя по всему, никак не меняет картину meminfo. По крайней мере не в пространстве ядра. Либо я чего-то не понимаю. Разница была в 280 килобайт в полях MemFree и MemAvailable.

reprimand ★★★★★ ()
Ответ на: комментарий от reprimand

По логике open() должен приводить к кешированию метаданных. Но, вроде есть ограничение на размер кеша метаданных, может по этому больших изменений развмеров кеша не видно. Имена файлов были какой длины?

И, вобще, странно, что у вас после выполнения open() снизился Cached.

mky ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.