FreeBSD: ZFS + rtorrent - сильная фрагментация файлов

[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(), то эта опция также не дает никакого эффекта, файлы все равно сильно фрагментируются.

У кого есть какие идеи, как избежать сильной фрагментации?

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[BirdGovorun]

У кого есть какие идеи, как избежать сильной фрагментации?

На ZFS фрагментация? С чего вы это взяли? Чем меряли?
http://www.mail-archive.com/zfs-discuss ... 28153.html

[Oddentity]

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

Проследим наглядно что происходит при закачке торрентов:
Скачиваются например 10 файлов по 10 Гб каждый. Если бы файловая система поддерживала функцию fallocate() (например NTFS), то каждый файл забивает себе сразу на диске по 10 Гб без фрагментации. FreeBSD не поддерживает fallocate(), поэтому данные пишутся на диск по мере скачивания, сильно фрагментируясь.
В том, что файлы фрагментированы, можно убедится, если сравнить результаты бенчмарка на random-reads. На моем пуле предел random-reads составляет около 13-14 Мбайт/c, что вполне объясняет низкую скорость чтения фрагментированных данных (порядка 10-11 Мбайт/c).

[BirdGovorun]

Когда переходил на ZFS очень интерисовался фрагментацией файлов, ничего не нашёл.
http://yvoinov.blogspot.com/2010/11/zfs.html
В ссылке сказано "Читайте исходники"

[Oddentity]

Спасибо, но все эти статьи относятся к Solaris.
Как оно реализовано во фряхе - известно одним лишь разработчикам. Учитывая, что функционал iscsi-шаринг, nfs-шаринг до сих пор реализован, это наталкивает на мысль, что в фряхе не все точно так же. Заявляли, что ZFS готова к production еще в 8.0, в реальности же более-менее оно готово только в 8.2 да и то с натяжкой...

Ну да ладно, предположим, что проблема не в фрагментации... Подойдем к вопросу с другой стороны - каким образом можно повысить скорость отдачи торрентов хотя бы до 50 Мбайт/c?

[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

[Oddentity]

При одном файле на раздачу проблем нет. Но ведь это не домашний комп, а сидбокс с гигабитным подключением.
ОЗУ у меня 12 Гб, 2 проца 4-ядерных.
Тюнинг системы уже пробовал делать самый разный.
Просто не очень понимаю, почему такая разница в дисковой производительности. Сравнивал с ноутбуком, к которому подключен внешний 2,5" веник через USB 2.0 - тот же набор торрентов (15 раздач, около 100 Гб) легко раздается на скорости 10 Мбайт/c. С внешнего самого обычного веника. Почему не удается получить бОльшую скорость на мощном сервере с 4-мя SATA-шными дисками? Разница только в том, что на ноуте винда, NTFS и uTorrent, а на сервере FreeBSD, ZFS и rtorrent

[BirdGovorun]

Может проблема в rtorrent? Глобу спросить, так не ответит
Как вариант попробовать другог клиента, например Transmission.
У меня больше мыслей нет, может кто подтянется, что-нибудь подскажут.

[BirdGovorun]

Вот мысль пробила, мне так кажется, если сделаете зеркало, то будет всё в норме,
но это из области телепатии

[Ikinoki]

А что говорит systat -vm?
top -m io?
куда нагрузка собственно? rtorrent под 100 процентов и висит в zfs->i?

[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 при небольшой дисковой нагрузке.

[Ikinoki]

А что там с кешем? Какие в sysctl параметры для zfs?

[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

[JSN]

А какие винты стоят на сервере? Случаем не Western Digital? Они очень плохо себя ведут при многопоточной работе, особенно (если не ошибаюсь) на чтение.

[Aligarh]

Клиент Transmission-daemon умеет избегать фрагментации - если в конфиге поставить preallocate равным 2, то вначале будет выделено и забито нулями всё место, а потом начнется закачка.
А вообще, надо бы попробовать просто dd в /dev/null любого большого файла из торрентовских закачек, посмотреть, сколько система выдает на чистом чтении.