Также см.https://serverfault.com/questions/339390/run-command-in-detached-tmux-sessionдля примеров использования команды отправить -клавиши на отдельной панели.
Ваша идея и значения (, примерно удваивающие их ), кажутся мне приемлемыми, но вы не объяснили, что именно вы подразумеваете под кэшированием RAM . Здесь это скорее просто буферизация , потому что все грязные страницы отправляются на диск без изменений.
Если у вас много операций ввода-вывода на одном блочном устройстве,он просто столкнется немного позже. Количество грязных страниц это не единственный триггер, есть еще(мм/страница -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% соответственно.
С помощью инструмента типов страниц -вы можете более точно идентифицировать эти грязные страницы. Это читает /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 страниц "УДл" ушли, т.е. те, которые «обновлены, грязны, в списке 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
Это моя профессиональная игра -вокруг чаевых.