LINUX.ORG.RU

А подскажите опции для уменьшения операций записи на диск

 , ,


0

4

Собственно, сабж. Есть файлики на ext4, при старте процесса они вычитываются, потом что-то там записывается обратно и вот этот процесс записи вполне можно было бы сделать и потом, по какому-нибудь sync по cron'у или вроде того. commit поставил побольше; noatime / nodiratime есть. dirty_ratio / dirty_background_ratio, а также таймеры для грязных страниц поднял. Но все равно сейчас при dd нового файла на FS до определенного размера он создается быстро (ок), но если пытаться его перезаписать повторным dd, то весь dirty-кэш уже начинает сбрасываться на диск. Примерно в таком стиле:

rain@miner9:/mnt/rw/rain$ dd if=/dev/zero of=/mnt/dag/file bs=1M count=100
100+0 записей считано
100+0 записей написано
 скопировано 104857600 байт (105 MB), 0,408632 c, 257 MB/c
rain@miner9:/mnt/rw/rain$ dd if=/dev/zero of=/mnt/dag/file bs=1M count=100
100+0 записей считано
100+0 записей написано
 скопировано 104857600 байт (105 MB), 12,0764 c, 8,7 MB/c
rain@miner9:/mnt/rw/rain$ rm /mnt/dag/file 
rain@miner9:/mnt/rw/rain$ sync
rain@miner9:/mnt/rw/rain$ dd if=/dev/zero of=/mnt/dag/file bs=1M count=300
300+0 записей считано
300+0 записей написано
 скопировано 314572800 байт (315 MB), 1,15442 c, 272 MB/c
rain@miner9:/mnt/rw/rain$ dd if=/dev/zero of=/mnt/dag/file bs=1M count=300
300+0 записей считано
300+0 записей написано
 скопировано 314572800 байт (315 MB), 52,9669 c, 5,9 MB/c

Где что еще подкрутить? Хочу, чтобы все операции записи / модификации максимально делались в памяти и процесс начинал работать дальше, а когда там оно скинется на диск - уже не его забота.

★★★★★

Когда-то пробовал для очень медленных флешек указывать ненулевой min_batch_time (например, min_batch_time=5000) при монтировании ext4. Эффект был, но не слишком большой (просто Android на такой флешке вроде бы становился немного более отзывчивым).

Slimer
()
Ответ на: комментарий от soomrack

Ну ты-то хоть в теме, что у меня за файлики и знаешь, что я сейчас так и делаю же :)

Не хватает оперативки под 3 DAG'а и хотелось бы от лишних операций уйти.

YAR ★★★★★
() автор топика
cat /etc/sysctl.conf
    vm.dirty_background_ratio = 5
    vm.dirty_ratio = 60
    vm.dirty_dirty_writeback_centisecs = 6000


с этими надо поиграться

tune2fs -o journal_data_writeback /dev/sda1
fstab options:
    ,noatime,nodiratime,barrier=0,nobh,commit=100
#тут ещё можно data=writeback но с этим были какие-то проблемы при зарузке, надо чего-то прописывать в опции ядра
//ага, это уже упоминалось) Ну других способов наверное и нет (разве что commit можно попробовать крутить)

Bad_ptr ★★★★★
()
Последнее исправление: Bad_ptr (всего исправлений: 3)
Ответ на: комментарий от YAR

Если кеш начинает сбрасываться из-за нехватки ОЗУ, дак он весь сбрасывается, а не только самые старые страницы. Судя по скорости ″8,7 MB/c″ у вас там что-то очень скромное. Сколько там ОЗУ свободного?

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

Все опции пробовал - собственно, результаты по ним были.

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

Это явно не нехватка ОЗУ - почему, собственно, и привел 2 результата - первый раз на кусок на 100 МБ, второй раз - на 300 МБ. Да хоть и 500 - создание нового файла быстрое. Запись в существующий - медленная. Не важно, вычитан он перед этим и находится в кэше или это «холодная» запись.

Судя по скорости ″8,7 MB/c″ у вас там что-то очень скромное.

Флешка.

Сколько там ОЗУ свободного?

rain@miner9:/mnt/rw/rain$ free -m
             total       used       free     shared    buffers     cached
Mem:          7990       4001       3988          0         10       3530
-/+ buffers/cache:        460       7529
Swap:         7990          0       7990

минус где-то 2.5 G на tmpfs - текущий вариант хранения этих файликов.

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

Т.е., еще раз:


rain@miner9:/mnt/rw/rain$ sudo mount /dev/sda4 /mnt/dag -o commit=1800,noatime,nodiratime,data=writeback,nobh,async,barrier=0
rain@miner9:/mnt/rw/rain$ dd if=/dev/zero of=/mnt/dag/file bs=1M count=100
100+0 записей считано
100+0 записей написано
 скопировано 104857600 байт (105 MB), 0,386729 c, 271 MB/c
rain@miner9:/mnt/rw/rain$ grep Dirty /proc/meminfo 
Dirty:            102404 kB

Пока все ок... Дальше:

rain@miner9:/mnt/rw/rain$ dd if=/dev/zero of=/mnt/dag/file bs=1M count=100
100+0 записей считано
100+0 записей написано
 скопировано 104857600 байт (105 MB), 13,8077 c, 7,6 MB/c
rain@miner9:/mnt/rw/rain$ grep Dirty /proc/meminfo 
Dirty:                 4 kB

Писало, пока не скинуло на флешку данные, в т.ч. и с кэша.

Пишем снова:

rain@miner9:/mnt/rw/rain$ dd if=/dev/zero of=/mnt/dag/file bs=1M count=100
100+0 записей считано
100+0 записей написано
 скопировано 104857600 байт (105 MB), 13,224 c, 7,9 MB/c
rain@miner9:/mnt/rw/rain$ grep Dirty /proc/meminfo 
Dirty:                 4 kB

Снова то же самое. Любая модификация файла - только с реальным скидыванием данных. Насоздаем новых файликов:

rain@miner9:/mnt/rw/rain$ dd if=/dev/zero of=/mnt/dag/newfile bs=1M count=100
100+0 записей считано
100+0 записей написано
 скопировано 104857600 байт (105 MB), 0,377458 c, 278 MB/c
rain@miner9:/mnt/rw/rain$ dd if=/dev/zero of=/mnt/dag/newfile2 bs=1M count=100
100+0 записей считано
100+0 записей написано
 скопировано 104857600 байт (105 MB), 0,359712 c, 292 MB/c
rain@miner9:/mnt/rw/rain$ grep Dirty /proc/meminfo 
Dirty:            204804 kB
rain@miner9:/mnt/rw/rain$ dd if=/dev/zero of=/mnt/dag/newfile3 bs=1M count=100
100+0 записей считано
100+0 записей написано
 скопировано 104857600 байт (105 MB), 0,373068 c, 281 MB/c
rain@miner9:/mnt/rw/rain$ grep Dirty /proc/meminfo 
Dirty:            307204 kB

Легко. Памяти хватает.

rain@miner9:/mnt/rw/rain$ grep . /proc/sys/vm/dirty_*
/proc/sys/vm/dirty_background_bytes:0
/proc/sys/vm/dirty_background_ratio:50
/proc/sys/vm/dirty_bytes:0
/proc/sys/vm/dirty_expire_centisecs:360000
/proc/sys/vm/dirty_ratio:99
/proc/sys/vm/dirty_writeback_centisecs:360000
rain@miner9:/mnt/rw/rain$ free -m
             total       used       free     shared    buffers     cached
Mem:          7990       3520       4469          0         10       3084
-/+ buffers/cache:        425       7564
Swap:         7990          0       7990
YAR ★★★★★
() автор топика
Ответ на: комментарий от YAR

/* попил чай */

Оно все еще в кэше. А с cat скидывания Dirty нет, но все равно тормоза:

 
rain@miner9:/mnt/rw/rain$ grep Dirty /proc/meminfo 
Dirty:            307204 kB
rain@miner9:/mnt/rw/rain$ time cat /mnt/dag/newfile > /mnt/dag/file 

real    0m12.046s
user    0m0.008s
sys     0m0.532s
rain@miner9:/mnt/rw/rain$ grep Dirty /proc/meminfo 
Dirty:            307204 kB
rain@miner9:/mnt/rw/rain$ time cat /mnt/dag/newfile > /mnt/dag/file 

real    0m12.054s
user    0m0.004s
sys     0m0.508s
rain@miner9:/mnt/rw/rain$ grep Dirty /proc/meminfo 
Dirty:            307204 kB
YAR ★★★★★
() автор топика
Ответ на: комментарий от YAR

А с cat скидывания Dirty нет, но все равно тормоза

Точнее, не так. Как я понимаю, то, что осело в Dirty - это те newfile - оно там и висит, пока не сработают таймеры и пороги. А вот модификация существующего файла file почему-то не оседает в кэше, а сливается напрямую.

YAR ★★★★★
() автор топика

Было также опробовано отключение журнала целиком, а также XFS. Поведение не меняется.

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

Интересная проблема.

Я никогда не экспериментировал, всё на флэшки списывал. И опять такая мысль - а может это контроллёр самой флэшки? А на жёствий диск пробовал также писать?

И ещё - если создать пустой файл, примонтировать лупом, отформатировать в любую фс и в ней провести все те же эксперименты? Будет отличаться скорость создания файла и скорость записи в существующий?

Deleted
()

Параметры монтирования тебе не помогут. Никто не расчитывал на такие извращения. Если файлы влезают в оперативку - юзай её. Если нет - найди способ сделать так чтоб влезали. Aufs и куча её параметров монтирования поможет тебе синхронизировать два места. Ну или рейд-зеркало с параметром на гарантию записи только на один диск.

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

С XFS как раз экспериментировал на своем ноуте, где обычный диск. Такое же самое поведение - запись нового файла около гигабайта в секунду, перезапись - чуть выше сотни мегабайт/сек.

И ещё - если создать пустой файл, примонтировать лупом, отформатировать в любую фс и в ней провести все те же эксперименты? Будет отличаться скорость создания файла и скорость записи в существующий?

Могу попробовать, в принципе... Сейчас с обедом закончу только :)

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

Никто не расчитывал на такие извращения.

Кэширование операций с файлом - извращение? Тем более, оно большей частью работает. Просто какой-то системный механизм мешает ему работать и на модификации файла. Какой - непонятно. Хотелось бы как минимум знать, почему так происходит.

Если файлы влезают в оперативку - юзай её.

Сейчас так и есть. Есть tmpfs на 2500 МБ, туда влазит 2 файлика. Файлики копируются при старте системы с флешки, дальше запускается процесс. Процесс реально работает с одним файлом и один генерирует наперед. Т.е., есть короткий момент, когда требуется место на 3 файла - момент, когда текущий становится старым. И нет, файлики не сжимаются. Как минимум, после окончания генерации (т.е., потенциально можно использовать zram и пытаться успеть в момент генерации 3-го удалить 1-й. Костыльненько). Полностью разместить 3 файла у меня памяти нет - тут и с двумя-то проблема, да и растут они потихоньку, скоро в 2500 МБ влазить не будут, поэтому и решил подсуетиться. Сейчас просто раз в несколько дней заканчивается память, все падает, поднимаю вручную, удаляю лишнее, делаю место, запускаю заново и т.п. Фактически же на сейчас кэшировать _на запись_ надо только один файлик на 1,2 ГБ. Т.е., вполне можно попробовать использовать dm-cache между флешкой на 4 ГБ и zram на 1,5 ГБ. Можно было бы bcache, но там ядро старовато.

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

И ещё - если создать пустой файл, примонтировать лупом, отформатировать в любую фс и в ней провести все те же эксперименты?

А так работает :)

rain@miner9:/tmp$ sudo mount /mnt/dag/loopfile /tmp/loopmount/ -o loop,commit=1800,noatime,nodiratime,data=writeback,nobh,async,barrier=0,delalloc,journal_async_commit,max_batch_time=3600000,min_batch_time=3000000
rain@miner9:/tmp$ df -h loopmount/
Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
/dev/loop0         2,0G          67M  1,9G            4% /tmp/loopmount
rain@miner9:/tmp$ sudo chown rain:rain loopmount/
rain@miner9:/tmp$ dd if=/dev/zero of=/tmp/loopmount/file bs=1M count=100
100+0 записей считано
100+0 записей написано
 скопировано 104857600 байт (105 MB), 0,346886 c, 302 MB/c
rain@miner9:/tmp$ dd if=/dev/zero of=/tmp/loopmount/file bs=1M count=100
100+0 записей считано
100+0 записей написано
 скопировано 104857600 байт (105 MB), 0,409628 c, 256 MB/c
rain@miner9:/tmp$ grep Dirty /proc/meminfo 
Dirty:            102492 kB
rain@miner9:/tmp$ dd if=/dev/zero of=/tmp/loopmount/file bs=1M count=100
100+0 записей считано
100+0 записей написано
 скопировано 104857600 байт (105 MB), 0,433043 c, 242 MB/c
rain@miner9:/tmp$ dd if=/dev/zero of=/tmp/loopmount/file bs=1M count=100
100+0 записей считано
100+0 записей написано
 скопировано 104857600 байт (105 MB), 0,442062 c, 237 MB/c
rain@miner9:/tmp$ grep Dirty /proc/meminfo 
Dirty:            102492 kB
rain@miner9:/tmp$ dd if=/dev/zero of=/tmp/loopmount/file bs=1M count=200
200+0 записей считано
200+0 записей написано
 скопировано 209715200 байт (210 MB), 0,886772 c, 236 MB/c
rain@miner9:/tmp$ grep Dirty /proc/meminfo 
Dirty:            204892 kB
rain@miner9:/tmp$ dd if=/dev/zero of=/tmp/loopmount/file bs=1M count=100
100+0 записей считано
100+0 записей написано
 скопировано 104857600 байт (105 MB), 0,442103 c, 237 MB/c
rain@miner9:/tmp$ grep Dirty /proc/meminfo 
Dirty:            225372 kB
rain@miner9:/tmp$ dd if=/dev/zero of=/tmp/loopmount/newfile bs=1M count=100
100+0 записей считано
100+0 записей написано
 скопировано 104857600 байт (105 MB), 0,370074 c, 283 MB/c
rain@miner9:/tmp$ grep Dirty /proc/meminfo 
Dirty:            327772 kB
rain@miner9:/tmp$ dd if=/dev/zero of=/tmp/loopmount/newfile bs=1M count=100
100+0 записей считано
100+0 записей написано
 скопировано 104857600 байт (105 MB), 0,503837 c, 208 MB/c
rain@miner9:/tmp$ grep Dirty /proc/meminfo 
Dirty:            327772 kB
YAR ★★★★★
() автор топика
Ответ на: комментарий от YAR

Я подозревал. Дело в том, что луп не учитывает всех этих секторов-шмекторов. И данные просто сливаются.

Но как поправить не знаю.

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

Возможно, тут тема не в секторах, а в том, что получается двойное кэширование. И если в одном слое файл уже перестал использоваться после перезаписи, то на более низком уровне файл образа все еще открыт системой и что-то там как-то кэшируется. Вопрос «почему не кэшируются модификации файла на верхнем слое» пока так и остается открытым.

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

https://ethereum.gitbooks.io/frontier-guide/content/mining.html

Ethash PoW is memory hard, making it basically ASIC resistant. This basically means that calculating the PoW requires choosing subsets of a fixed resource dependent on the nonce and block header. This resource (a few gigabyte size data) is called a DAG. The DAG is totally different every 30000 blocks (a 100 hour window, called an epoch) and takes a while to generate.

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

Приветствую. Есть что сказать по твоей проблеме.

1. У ext4 есть свой таймер записи на диск (30 секунд по дефолту). Он работает отдельно от системного грязностраничного.
2. Где-то в ядрах 2.6.29-3.1 внесли патч «Stable Pages», который гарантирует неизменность dirty pages до их записи на диск. Судя по всему именно он мешает тебе. Читай по этому поводу:
про сами «Stable Pages» http://lwn.net/Articles/442355/
про проблему, вроде как, аналогичную твоей: http://www.serverphorums.com/read.php?12,578187
Upd. Самое главное забыл. Есть вроде как патчик который отключает стабильные страницы. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1d1...

chaos_dremel ★★
()
Последнее исправление: chaos_dremel (всего исправлений: 1)
Ответ на: комментарий от YAR

Странно, что с лупом проблем нет. Тут я вижу два варианта, или на ФС в лупе не распространяются «Stable Pages» или дело в отсутствии Direct IO и/или Asynchronous IO, которые в loop завезли в вышедшем сегодня ядре.

chaos_dremel ★★
()
27 мая 2017 г.

Не скажу

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