Новость: Linux: Производительность кэша inode
(Категория: Linux)
Добавил Roman I Khimov
Вторник, 28 Декабрь 2004, 03:30
В lkml прошла интересная дискуссия об эффективности кэша inode в ядрах Linux версий 2.4, включая обсуждение нескольких настроек, которые могут быть полезны для систем, работающих в качестве больших NFS и Samba серверов.
В частности, было отмечено снижение производительности на таких системах, которое можно легко увидеть производя поиск find / во время вывода cat'ом больших файлов в /dev/null. В дискуссии между поддерживающим ветку 2.4 Марселло Тосатти (Marcelo Tosatti), Эндрю Мортоном (Andrew Morton), занимающимся веткой 2.6 и ответственным за VM Андреа Арканджели (Andrea Arcangeli) выяснилось, что происходит это скорее всего из-за слишком маленькой таблицы кэшей хэшей inode'ов, что приводит к большому числу промахов. Однако выяснилось и то, что некоторые настройки могут помочь в этом, однако, это половинчатые решения, вполне возможно, что в ветке 2.6 позже будет сделано изменение в коде работы с inode для улучшения производительности.
Кэш inode - это хранящаяся в памяти хэш-таблица, описанная в fs/inode.c, и которую использует виртуальная файловая система (VFS). Каждый файл в файловой системе Unix имеет уникальный inode, структуру данных (определенную в include/linux/fs.h), содержащую такую информацию, как владелец файла, дата последнего изменения и устройство, которое хранит этот файл. Эти данные необходимы для навигации по примонтированной файловой системы и для ускорения этого процесса при чтении inode он записывается в кэш inode для дальнейшего использования. По мере заполнения таблицы хэшей вероятность их совпадения у нескольких inode совпадает, что приводит к коллизиям. Увеличивающееся число коллизий скорее всего и ведет к уменьшению скорости поисков, во всяком случае так это объясняет Андреа.
Если у вас возникают подобные проблемы, то, возможно, стоит попробовать поиграться с параметром /proc/sys/vm/vm_mapped_ratio.
Источник этой новости Центр информации по операционным системам
( http://www.osrc.info/news.php?extend.1657 )
(Категория: Linux)
Добавил Roman I Khimov
Вторник, 28 Декабрь 2004, 03:30
В lkml прошла интересная дискуссия об эффективности кэша inode в ядрах Linux версий 2.4, включая обсуждение нескольких настроек, которые могут быть полезны для систем, работающих в качестве больших NFS и Samba серверов.
В частности, было отмечено снижение производительности на таких системах, которое можно легко увидеть производя поиск find / во время вывода cat'ом больших файлов в /dev/null. В дискуссии между поддерживающим ветку 2.4 Марселло Тосатти (Marcelo Tosatti), Эндрю Мортоном (Andrew Morton), занимающимся веткой 2.6 и ответственным за VM Андреа Арканджели (Andrea Arcangeli) выяснилось, что происходит это скорее всего из-за слишком маленькой таблицы кэшей хэшей inode'ов, что приводит к большому числу промахов. Однако выяснилось и то, что некоторые настройки могут помочь в этом, однако, это половинчатые решения, вполне возможно, что в ветке 2.6 позже будет сделано изменение в коде работы с inode для улучшения производительности.
Кэш inode - это хранящаяся в памяти хэш-таблица, описанная в fs/inode.c, и которую использует виртуальная файловая система (VFS). Каждый файл в файловой системе Unix имеет уникальный inode, структуру данных (определенную в include/linux/fs.h), содержащую такую информацию, как владелец файла, дата последнего изменения и устройство, которое хранит этот файл. Эти данные необходимы для навигации по примонтированной файловой системы и для ускорения этого процесса при чтении inode он записывается в кэш inode для дальнейшего использования. По мере заполнения таблицы хэшей вероятность их совпадения у нескольких inode совпадает, что приводит к коллизиям. Увеличивающееся число коллизий скорее всего и ведет к уменьшению скорости поисков, во всяком случае так это объясняет Андреа.
Если у вас возникают подобные проблемы, то, возможно, стоит попробовать поиграться с параметром /proc/sys/vm/vm_mapped_ratio.
Источник этой новости Центр информации по операционным системам
( http://www.osrc.info/news.php?extend.1657 )