Страница 1 из 1
FreeBSD: ZFS + rtorrent - сильная фрагментация файлов
Добавлено: 2011-03-25 12:30:47
Oddentity
Исходные данные:
FreeBSD 8.2 amd84
ZFS raidz пул из 4-х SATA-дисков
rtorrent 0.8.6 + libTorrent 0.12.6
Сидбоксы на скачку работают идеально. А вот с отдачей совсем беда - из-за сильной фрагментации файлов (особенно больших) максимум что я могу выдать - смешные 80-100 мбит/c на отдачу при дисковой загрузке выше 80%. Пробовал различный тюнинг ZFS, менять конфиг rtorrent - практически никакого результата.
Также добавлял опцию system.file_allocate.set = yes в конфиг rtorrent чтобы файл сразу "забивал" себе место на диске целиком, но т.к. в FreeBSD не поддерживается функция fallocate(), то эта опция также не дает никакого эффекта, файлы все равно сильно фрагментируются.
У кого есть какие идеи, как избежать сильной фрагментации?
Re: FreeBSD: ZFS + rtorrent - сильная фрагментация файлов
Добавлено: 2011-03-25 14:02:11
BirdGovorun
Oddentity писал(а):
У кого есть какие идеи, как избежать сильной фрагментации?
На ZFS фрагментация? С чего вы это взяли? Чем меряли?
http://www.mail-archive.com/zfs-discuss ... 28153.html
Re: FreeBSD: ZFS + rtorrent - сильная фрагментация файлов
Добавлено: 2011-03-25 14:35:46
Oddentity
Именно. Я уже долгое время пытаюсь разобраться в причинах такой высокой дисковой загрузки, и пришел к выводу, что это из-за фрагментации.
Проследим наглядно что происходит при закачке торрентов:
Скачиваются например 10 файлов по 10 Гб каждый. Если бы файловая система поддерживала функцию fallocate() (например NTFS), то каждый файл забивает себе сразу на диске по 10 Гб без фрагментации. FreeBSD не поддерживает fallocate(), поэтому данные пишутся на диск по мере скачивания, сильно фрагментируясь.
В том, что файлы фрагментированы, можно убедится, если сравнить результаты бенчмарка на random-reads. На моем пуле предел random-reads составляет около 13-14 Мбайт/c, что вполне объясняет низкую скорость чтения фрагментированных данных (порядка 10-11 Мбайт/c).
Re: FreeBSD: ZFS + rtorrent - сильная фрагментация файлов
Добавлено: 2011-03-25 14:58:29
BirdGovorun
Когда переходил на ZFS очень интерисовался фрагментацией файлов, ничего не нашёл.
http://yvoinov.blogspot.com/2010/11/zfs.html
В ссылке сказано "Читайте исходники"
Re: FreeBSD: ZFS + rtorrent - сильная фрагментация файлов
Добавлено: 2011-03-25 15:31:04
Oddentity
Спасибо, но все эти статьи относятся к Solaris.
Как оно реализовано во фряхе - известно одним лишь разработчикам. Учитывая, что функционал iscsi-шаринг, nfs-шаринг до сих пор реализован, это наталкивает на мысль, что в фряхе не все точно так же. Заявляли, что ZFS готова к production еще в 8.0, в реальности же более-менее оно готово только в 8.2 да и то с натяжкой...
Ну да ладно, предположим, что проблема не в фрагментации... Подойдем к вопросу с другой стороны - каким образом можно повысить скорость отдачи торрентов хотя бы до 50 Мбайт/c?
Re: FreeBSD: ZFS + rtorrent - сильная фрагментация файлов
Добавлено: 2011-03-25 16:19:24
BirdGovorun
Даже не знаю, сам недавно подсел на ZFS, только разбираться начал.
Тюнить вы пробовали, у меня вот чего в /boot/loader.conf
Код: Выделить всё
vm.kmem_size_max="1024M"
vm.kmem_size="1024M"
vfs.zfs.arc_max="768M"
8.2-RELEASE amd64, RAM-2G
Сколько файлов сразу на раздачу? Попробовать только один раздать, но это всё гадание на кофейной гуще.
Можно перейти на 9.0 там v28, возможно и 8.2-STABLE уже есть (не следил за этим)
http://www.opennet.ru/opennews/art.shtml?num=27828
Re: FreeBSD: ZFS + rtorrent - сильная фрагментация файлов
Добавлено: 2011-03-25 16:27:31
Oddentity
При одном файле на раздачу проблем нет. Но ведь это не домашний комп, а сидбокс с гигабитным подключением.
ОЗУ у меня 12 Гб, 2 проца 4-ядерных.
Тюнинг системы уже пробовал делать самый разный.
Просто не очень понимаю, почему такая разница в дисковой производительности. Сравнивал с ноутбуком, к которому подключен внешний 2,5" веник через USB 2.0 - тот же набор торрентов (15 раздач, около 100 Гб) легко раздается на скорости 10 Мбайт/c. С внешнего самого обычного веника. Почему не удается получить бОльшую скорость на мощном сервере с 4-мя SATA-шными дисками? Разница только в том, что на ноуте винда, NTFS и uTorrent, а на сервере FreeBSD, ZFS и rtorrent
Re: FreeBSD: ZFS + rtorrent - сильная фрагментация файлов
Добавлено: 2011-03-25 16:34:43
BirdGovorun
Может проблема в rtorrent? Глобу спросить, так не ответит
Как вариант попробовать другог клиента, например Transmission.
У меня больше мыслей нет, может кто подтянется, что-нибудь подскажут.
Re: FreeBSD: ZFS + rtorrent - сильная фрагментация файлов
Добавлено: 2011-03-25 16:52:00
BirdGovorun
Вот мысль пробила, мне так кажется, если сделаете зеркало, то будет всё в норме,
но это из области телепатии
Re: FreeBSD: ZFS + rtorrent - сильная фрагментация файлов
Добавлено: 2011-03-30 18:49:49
Ikinoki
А что говорит systat -vm?
top -m io?
куда нагрузка собственно? rtorrent под 100 процентов и висит в zfs->i?
Re: FreeBSD: ZFS + rtorrent - сильная фрагментация файлов
Добавлено: 2011-03-31 14:39:02
Oddentity
Вот к примеру - 12 торрентов на отдачу, каждый в среднем 4-7 Гб, скорость отдачи выше 6 Мбайт/c не поднимается при загрузке дисков 80%
вывод top -m io:
Код: Выделить всё
last pid: 58670; load averages: 0.33, 0.49, 0.48 up 2+23:15:49 14:29:31
38 processes: 1 running, 37 sleeping
CPU: 1.9% user, 0.0% nice, 5.6% system, 2.7% interrupt, 89.8% idle
Mem: 367M Active, 1731M Inact, 7230M Wired, 295M Cache, 2275M Free
Swap: 4096M Total, 4096M Free
PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND
1044 dima 63 957 0 0 3631 3631 89.02% rtorrent
1045 alex 159 46 0 0 448 448 10.98% rtorrent
1558 root 6 19 0 0 0 0 0.00% ipcad
1048 root 0 0 0 0 0 0 0.00% snmpd
33657 mrtg 0 0 0 0 0 0 0.00% perl
50287 www 2 0 0 0 0 0 0.00% lighttpd
1015 alex 2 0 0 0 0 0 0.00% screen
1074 root 0 0 0 0 0 0 0.00% nmbd
1097 root 0 0 0 0 0 0 0.00% proftpd
60359 www 0 0 0 0 0 0 0.00% php-cgi
1085 root 0 0 0 0 0 0 0.00% smbd
60361 www 0 0 0 0 0 0 0.00% php-cgi
875 root 1 0 0 0 0 0 0.00% syslogd
60360 www 0 0 0 0 0 0 0.00% php-cgi
Вывод top
Код: Выделить всё
last pid: 59190; load averages: 0.80, 0.69, 0.56 up 2+23:19:48 14:33:30
38 processes: 2 running, 36 sleeping
CPU: 1.5% user, 0.0% nice, 5.3% system, 2.0% interrupt, 91.2% idle
Mem: 383M Active, 1869M Inact, 7227M Wired, 314M Cache, 2105M Free
Swap: 4096M Total, 4096M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
1044 dima 1 52 0 2884M 370M zio->i 4 56:06 14.06% rtorrent
1045 alex 1 44 0 156M 15388K select 2 49:19 0.10% rtorrent
1558 root 3 44 -15 133M 127M select 0 5:18 0.00% ipcad
1048 root 1 44 0 26196K 5196K select 4 5:06 0.00% snmpd
33657 mrtg 1 76 0 72672K 21600K nanslp 0 1:45 0.00% perl
50287 www 1 44 0 23772K 4040K select 4 0:12 0.00% lighttpd
1015 alex 1 44 0 9372K 1576K select 2 0:07 0.00% screen
1074 root 1 44 0 24168K 3392K select 0 0:04 0.00% nmbd
1097 root 1 44 0 13144K 3132K select 1 0:03 0.00% proftpd
60359 www 1 44 0 58980K 10532K accept 0 0:01 0.00% php-cgi
1085 root 1 44 0 32864K 4944K select 1 0:01 0.00% smbd
60361 www 1 45 0 58980K 10528K accept 2 0:01 0.00% php-cgi
875 root 1 44 0 7048K 1192K select 4 0:01 0.00% syslogd
60360 www 1 45 0 58980K 10380K accept 7 0:01 0.00% php-cgi
вывод systat -vm
Код: Выделить всё
2 users Load 0,76 0,73 0,59 31 мар 14:35
Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER
Tot Share Tot Share Free in out in out
Act 1916516 11716 44893440 22236 2420576 count 2403 1
All 8106040 14416 1118759k 39072 pages 2403 11
Proc: Interrupts
r p d s w Csw Trp Sys Int Sof Flt cow 31433 total
1 2 36 48k 3865 52k 15k 1027 3851 zfod atkbd0 1
ozfod 740 mfi0 uhci0
4,7%Sys 2,2%Intr 2,5%User 0,0%Nice 90,5%Idle %ozfod 2001 cpu0: time
| | | | | | | | | | | daefr 5781 igb0:que 0
==+>> prcfr 2333 igb0:que 1
dtbuf 30606 totfr 2660 igb0:que 2
Namei Name-cache Dir-cache 400000 desvn 706 react 3911 igb0:que 3
Calls hits % hits % 75515 numvn pdwak igb0:link
382 382 100 67394 frevn pdpgs igb1:que 0
intrn igb1:que 1
Disks mfid0 mfid1 mfid2 mfid3 7401492 wire igb1:que 2
KB/t 58,65 58,81 59,42 58,62 398252 act igb1:que 3
tps 201 198 193 201 1964328 inact igb1:link
MB/s 11,52 11,36 11,22 11,51 350756 cache 2001 cpu4: time
%busy 85 84 85 83 2069776 free 2001 cpu3: time
buf 2001 cpu1: time
2001 cpu2: time
2001 cpu5: time
2001 cpu6: time
2001 cpu7: time
При скачке проблем нет - скорость легко доходит до 40 Мбайт/c при небольшой дисковой нагрузке.
Re: FreeBSD: ZFS + rtorrent - сильная фрагментация файлов
Добавлено: 2011-03-31 14:54:30
Ikinoki
А что там с кешем? Какие в sysctl параметры для zfs?
Re: FreeBSD: ZFS + rtorrent - сильная фрагментация файлов
Добавлено: 2011-03-31 15:21:45
Oddentity
Тюнинг убрал, все по умолчанию, кроме ограничения размера ARC:
vfs.zfs.arc_max="6G"
Раньше игрался с тюнингом разных параметров, значительного улучшения ничего не дало - вернулся на дефолт.
Сейчас в sysctl такое:
Код: Выделить всё
vfs.zfs.l2c_only_size: 0
vfs.zfs.mfu_ghost_data_lsize: 4976326656
vfs.zfs.mfu_ghost_metadata_lsize: 142520320
vfs.zfs.mfu_ghost_size: 5118846976
vfs.zfs.mfu_data_lsize: 973967872
vfs.zfs.mfu_metadata_lsize: 6446080
vfs.zfs.mfu_size: 1042247168
vfs.zfs.mru_ghost_data_lsize: 1279918080
vfs.zfs.mru_ghost_metadata_lsize: 40544256
vfs.zfs.mru_ghost_size: 1320462336
vfs.zfs.mru_data_lsize: 5070274560
vfs.zfs.mru_metadata_lsize: 263680
vfs.zfs.mru_size: 5119880704
vfs.zfs.anon_data_lsize: 0
vfs.zfs.anon_metadata_lsize: 0
vfs.zfs.anon_size: 0
vfs.zfs.l2arc_norw: 1
vfs.zfs.l2arc_feed_again: 1
vfs.zfs.l2arc_noprefetch: 0
vfs.zfs.l2arc_feed_min_ms: 200
vfs.zfs.l2arc_feed_secs: 1
vfs.zfs.l2arc_headroom: 2
vfs.zfs.l2arc_write_boost: 8388608
vfs.zfs.l2arc_write_max: 8388608
vfs.zfs.arc_meta_limit: 1610612736
vfs.zfs.arc_meta_used: 398116768
vfs.zfs.mdcomp_disable: 0
vfs.zfs.arc_min: 805306368
vfs.zfs.arc_max: 6442450944
vfs.zfs.zfetch.array_rd_sz: 1048576
vfs.zfs.zfetch.block_cap: 256
vfs.zfs.zfetch.min_sec_reap: 2
vfs.zfs.zfetch.max_streams: 8
vfs.zfs.prefetch_disable: 0
vfs.zfs.check_hostid: 1
vfs.zfs.recover: 0
vfs.zfs.txg.write_limit_override: 0
vfs.zfs.txg.synctime: 5
vfs.zfs.txg.timeout: 30
vfs.zfs.scrub_limit: 10
vfs.zfs.vdev.cache.bshift: 16
vfs.zfs.vdev.cache.size: 10485760
vfs.zfs.vdev.cache.max: 16384
vfs.zfs.vdev.aggregation_limit: 131072
vfs.zfs.vdev.ramp_rate: 2
vfs.zfs.vdev.time_shift: 6
vfs.zfs.vdev.min_pending: 4
vfs.zfs.vdev.max_pending: 10
vfs.zfs.cache_flush_disable: 0
vfs.zfs.zil_disable: 0
vfs.zfs.zio.use_uma: 0
vfs.zfs.version.zpl: 4
vfs.zfs.version.spa: 15
vfs.zfs.version.dmu_backup_stream: 1
vfs.zfs.version.dmu_backup_header: 2
vfs.zfs.version.acl: 1
vfs.zfs.debug: 0
vfs.zfs.super_owner: 0
kstat.zfs.misc.zfetchstats.hits: 760734084
kstat.zfs.misc.zfetchstats.misses: 90038936
kstat.zfs.misc.zfetchstats.colinear_hits: 25241
kstat.zfs.misc.zfetchstats.colinear_misses: 90013695
kstat.zfs.misc.zfetchstats.stride_hits: 757377306
kstat.zfs.misc.zfetchstats.stride_misses: 62369
kstat.zfs.misc.zfetchstats.reclaim_successes: 885528
kstat.zfs.misc.zfetchstats.reclaim_failures: 89128167
kstat.zfs.misc.zfetchstats.streams_resets: 4439
kstat.zfs.misc.zfetchstats.streams_noresets: 3356536
kstat.zfs.misc.zfetchstats.bogus_streams: 0
kstat.zfs.misc.arcstats.hits: 98024243
kstat.zfs.misc.arcstats.misses: 5118870
kstat.zfs.misc.arcstats.demand_data_hits: 75588846
kstat.zfs.misc.arcstats.demand_data_misses: 616211
kstat.zfs.misc.arcstats.demand_metadata_hits: 5404549
kstat.zfs.misc.arcstats.demand_metadata_misses: 194276
kstat.zfs.misc.arcstats.prefetch_data_hits: 16489862
kstat.zfs.misc.arcstats.prefetch_data_misses: 4279101
kstat.zfs.misc.arcstats.prefetch_metadata_hits: 540986
kstat.zfs.misc.arcstats.prefetch_metadata_misses: 29282
kstat.zfs.misc.arcstats.mru_hits: 5062792
kstat.zfs.misc.arcstats.mru_ghost_hits: 1360498
kstat.zfs.misc.arcstats.mfu_hits: 83006825
kstat.zfs.misc.arcstats.mfu_ghost_hits: 1717470
kstat.zfs.misc.arcstats.allocated: 29505277
kstat.zfs.misc.arcstats.deleted: 2536894
kstat.zfs.misc.arcstats.stolen: 5304867
kstat.zfs.misc.arcstats.recycle_miss: 80648
kstat.zfs.misc.arcstats.mutex_miss: 64
kstat.zfs.misc.arcstats.evict_skip: 2170036
kstat.zfs.misc.arcstats.evict_l2_cached: 0
kstat.zfs.misc.arcstats.evict_l2_eligible: 516582567424
kstat.zfs.misc.arcstats.evict_l2_ineligible: 194168604672
kstat.zfs.misc.arcstats.hash_elements: 150243
kstat.zfs.misc.arcstats.hash_elements_max: 151055
kstat.zfs.misc.arcstats.hash_collisions: 1388333
kstat.zfs.misc.arcstats.hash_chains: 30365
kstat.zfs.misc.arcstats.hash_chain_max: 7
kstat.zfs.misc.arcstats.p: 5123640320
kstat.zfs.misc.arcstats.c: 6442450944
kstat.zfs.misc.arcstats.c_min: 805306368
kstat.zfs.misc.arcstats.c_max: 6442450944
kstat.zfs.misc.arcstats.size: 6442359200
kstat.zfs.misc.arcstats.hdr_size: 35095056
kstat.zfs.misc.arcstats.data_size: 6162127872
kstat.zfs.misc.arcstats.other_size: 245136272
kstat.zfs.misc.arcstats.l2_hits: 0
kstat.zfs.misc.arcstats.l2_misses: 0
kstat.zfs.misc.arcstats.l2_feeds: 0
kstat.zfs.misc.arcstats.l2_rw_clash: 0
kstat.zfs.misc.arcstats.l2_read_bytes: 0
kstat.zfs.misc.arcstats.l2_write_bytes: 0
kstat.zfs.misc.arcstats.l2_writes_sent: 0
kstat.zfs.misc.arcstats.l2_writes_done: 0
kstat.zfs.misc.arcstats.l2_writes_error: 0
kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0
kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0
kstat.zfs.misc.arcstats.l2_evict_reading: 0
kstat.zfs.misc.arcstats.l2_free_on_write: 0
kstat.zfs.misc.arcstats.l2_abort_lowmem: 0
kstat.zfs.misc.arcstats.l2_cksum_bad: 0
kstat.zfs.misc.arcstats.l2_io_error: 0
kstat.zfs.misc.arcstats.l2_size: 0
kstat.zfs.misc.arcstats.l2_hdr_size: 0
kstat.zfs.misc.arcstats.memory_throttle_count: 0
kstat.zfs.misc.arcstats.l2_write_trylock_fail: 0
kstat.zfs.misc.arcstats.l2_write_passed_headroom: 0
kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 0
kstat.zfs.misc.arcstats.l2_write_in_l2: 0
kstat.zfs.misc.arcstats.l2_write_io_in_progress: 0
kstat.zfs.misc.arcstats.l2_write_not_cacheable: 1487070
kstat.zfs.misc.arcstats.l2_write_full: 0
kstat.zfs.misc.arcstats.l2_write_buffer_iter: 0
kstat.zfs.misc.arcstats.l2_write_pios: 0
kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 0
kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 0
kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 0
kstat.zfs.misc.vdev_cache_stats.delegations: 34226
kstat.zfs.misc.vdev_cache_stats.hits: 283577
kstat.zfs.misc.vdev_cache_stats.misses: 71689
Re: FreeBSD: ZFS + rtorrent - сильная фрагментация файлов
Добавлено: 2011-05-24 6:23:06
JSN
А какие винты стоят на сервере? Случаем не Western Digital? Они очень плохо себя ведут при многопоточной работе, особенно (если не ошибаюсь) на чтение.
Re: FreeBSD: ZFS + rtorrent - сильная фрагментация файлов
Добавлено: 2011-05-24 7:42:54
Aligarh
Клиент Transmission-daemon умеет избегать фрагментации - если в конфиге поставить preallocate равным 2, то вначале будет выделено и забито нулями всё место, а потом начнется закачка.
А вообще, надо бы попробовать просто dd в /dev/null любого большого файла из торрентовских закачек, посмотреть, сколько система выдает на чистом чтении.