☰

Какие значения dirty_background_ratio и dirty_ratio лучше всего подходят для моего использования?

tag-icon • tag-icon linux hard-disk io sysctl tuning
Какие значения dirty_background_ratio и dirty_ratio лучше всего подходят для моего использования?

Поэтому я экспериментирую dirty_background_ratio and dirty_ratioи надеюсь найти правильные параметры с вашей профессиональной помощью.

На данный момент я использую:

vm.dirty_background_ratio = 20 vm.dirty_ratio = 60

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

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

решение1

Ваша идея и значения (примерно удвоенные) кажутся мне приемлемыми, но вы не объяснили, что именно вы подразумеваете под оперативной памятью.кэширование. Здесь это больше простобуферизацияпоскольку все «грязные» страницы отправляются на диск в неизмененном виде.

Если у вас много IO на одном и том же блочном устройстве, они просто столкнутся немного позже. Количество грязных страниц — это не единственный триггер, есть также (mm/page-writeback.c):

/*
 * The longest time for which data is allowed to remain dirty
 */
unsigned int dirty_expire_interval = 30 * 100; /* centiseconds */

Что дает значение по умолчанию 30 с. Этого может быть достаточно. Но это означает, что грязные страницы старше этого времени не будут удерживаться (временное измерение буферизации/кэширования).

А если у вас есть параллельный ввод-вывод, то эти глобальные настройки также повлияют на него.

Лучшее объяснение длягрязный_коэффициентигрязный_фон_соотношениенаходится в том же файле:

/* The following parameters are exported via /proc/sys/vm */

/*
 * Start background writeback (via writeback threads) at this percentage
 */
int dirty_background_ratio = 10;
...
/*
 * The generator of dirty data starts writeback at this percentage
 */
int vm_dirty_ratio = 20;

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

Вот несколько команд для анализа «грязных» страниц:

]# cp MAINTAINERS MAINTAINERS-2

]# grep dirty /proc/vmstat 
nr_dirty 135
nr_dirty_threshold 311361
nr_dirty_background_threshold 155490

Пороговые значения рассчитываются из значений отношения (указанных в процентах или байтах). У меня 8 ГБ = 2 млн страниц, так что это 10% и 20% соответственно.

С помощью инструмента page-types вы можете точнее определить эти грязные страницы. Он читает /proc/kpageflags и занимает около 200 мс.

]# ./tools/vm/page-types  -b dirty -b lru -b ~active,~reclaim,~mmap |cut -c-80
             flags      page-count       MB  symbolic-flags                     long-symbolic-flags
0x0000000000000030               1        0  ____Dl__________________________________
0x0000000000000038             130        0  ___UDl__________________________________
0x0000000000044038               1        0  ___UDl________b___u_____________________
0x000000000000403c              23        0  __RUDl________b_________________________
             total             155        0

Независимо от того, сижу ли я и жду (30 секунд) или делаю это вручную sync, грязные страницы вскоре исчезают.

]# sync
]# grep dirty /proc/vmstat 
nr_dirty 0
...

И все 130 страниц «UDl» исчезли, т. е. те, которые «актуальны, грязны, находятся в списке LRU».

]# ./tools/vm/page-types  -b dirty -b lru -b ~active,~reclaim,~mmap |cut -c-80
             flags      page-count       MB  symbolic-flags                     long-symbolic-flags
0x0000000000044038               1        0  ___UDl________b___u_____________________
0x000000000000403c              23        0  __RUDl________b_________________________
             total              24        0

Разница в 130 + 1 страниц в двух строках как раз и составляет размер файла:

]# ls --block-size=4096 -s MAINTAINERS 
131 MAINTAINERS

Это мои профессиональные советы по игре.

Связанный контент