Свежие комментарии

Title	Comment
Ну вот на пяти вышкупомянутых	Ну вот на пяти вышеупомянутых сигейтах (ada0-ada4) картинка выглядит так: 17,8%Sys 2,2%Intr 0,0%User 0,0%Nice 80,0%Idle %ozfod uhci2 uhci \| \| \| \| \| \| \| \| \| \| \| daefr 1091 hpet0 20 =========+ prcfr uhci3 ehci 22 dtbuf 130053 totfr 1 em0 256 Namei Name-cache Dir-cache 269754 desvn react hdac0 257 Calls hits % hits % 2094 numvn pdwak 3690 ahci0 258 3 3 100 95 frevn pdpgs ib_mthca0 intrn ib_mthca0 Disks ada0 ada1 ada2 ada3 ada4 da0 pass0 4637952 wire ib_mthca0 KB/t 112 113 113 115 115 31,43 0,00 45172 act tps 760 756 767 758 750 6 0 30932 inact MB/s 83,46 83,62 84,80 85,37 84,60 0,17 0,00 348 cache %busy 75 76 76 77 90 1 0 7414948 free Это mv SOMEDIR /zfs/another-fs/ (большие файлы) Не сказать, чтобы я был особо доволен, но ~200M чтения и 200 записи одновременно - ну приятно, да.
Ну вроде между X58 и IO-чипом рисуют 2Gb/sec: http://en.wiki	Ну вроде между X58 и IO-чипом рисуют 2Gb/sec: http://en.wikipedia.org/wiki/File:X58_Block_Diagram.png
А не возможен где-то затык? Ну то есть 400MB/s где-то недале	А не возможен где-то затык? Ну то есть 400MB/s где-то недалеко от PCI-E v2 per lane.
Два да, больше уже не надо.	Два да, больше уже не надо.
А прилично писать сразу в два, с cc: ?	А прилично писать сразу в два, с cc: ?
freebsd-stable@ freebsd-net@ (мне кажется, это логичнее, чем	freebsd-stable@ freebsd-net@ (мне кажется, это логичнее, чем -scsi@) Быть подписанным заранее не обязательно.
Это фрагментация. Процентов	Это фрагментация. Процентов 10 свободных надо иметь, а то плохо все.
Ну вот забили на 100% -	Ну вот забили на 100% - теперь не обижайтесь.
Ощущение такое, что операция	Ощущение такое, что операция вообще никак не кешируется. У винтов бизи 100%, при этом трансфер 10 Мб.
А там процессор не загружен	А там процессор не загружен особо. Вот я эту запись запустил, и в соседней консоли вывел systat -vm 2 users Load 0,94 0,30 0,21 19 мар 19:50 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 415540 4544 3254684 13860 233180 count 6 All 2850384 4972 1077125k 65524 pages 27 Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt 7 cow 2447 total 104 9756 60 497 2448 1054 19 4 zfod ehci0 ehci ozfod ohci0 ohci 12,8%Sys 0,9%Intr 0,5%User 0,0%Nice 85,8%Idle %ozfod hdac0 256 \| \| \| \| \| \| \| \| \| \| \| daefr 182 bge0 257 ======+ 5 prcfr 949 ahci0 258 129 dtbuf 18766 totfr 870 hpet0:t0 Namei Name-cache Dir-cache 142837 desvn react 446 hpet0:t1 Calls hits % hits % 44413 numvn pdwak 59 49 83 35708 frevn 14738 pdpgs intrn Disks ada0 ada1 ada2 ada3 ada4 pass0 pass1 3387484 wire KB/t 38,70 41,07 38,17 41,86 16,61 0,00 0,00 111580 act tps 207 252 181 240 7 0 0 295916 inact MB/s 7,83 10,12 6,73 9,80 0,11 0,00 0,00 90928 cache %busy 97 92 100 96 0 0 0 142080 free 427424 buf
а к scsi похоже относят нынче все, что не сетевые карты и с	а к scsi похоже относят нынче все, что не сетевые карты и с проводами. но может и не scsi. но точно стабле. ну да, лучше подписаться. линки есть в хэндбуке, хэндбук на сайте.
scsi то тут коим боком? SRP нету. И, я не шучу, я честно не	scsi то тут коим боком? SRP нету. И, я не шучу, я честно не знаю как туда писать. Надо подписаться куда-то?
я думаю stable и scsi	я думаю stable и scsi
А какие листы - профильные и как туда писать (читать я умею:	А какие листы - профильные и как туда писать (читать я умею:) ? С ramdrive придумаю что-нибудь, но не сейчас. У меня это freebsd-freebsd для переливки терабайтов с zfs на zfs, а не ради развлечения (в connected mode, кстати, оно полилось процентов на 20 быстрее, хотя упирается вроде в диски)
я думаю тебя очень ждут в профильных листах с отчетами. сде	я думаю тебя очень ждут в профильных листах с отчетами. сделай, кстати ram-disk и с него файл отдай (для бенчмарки), а то ftpd поди не может sendfile к /dev/zero применить.
Как я уже выше по треду	Как я уже выше по треду ссылался, процессор - важен. Хотя вот 16Mb/sec даже для такого процессора мне кажется маловато.
Я такой скорости могу только	Я такой скорости могу только позавидовать... [ paul@biggiesmalls /mnt/Quattro ] # grep -w CPU: /var/run/dmesg.boot [ 20:22 ] CPU: AMD Athlon(tm) II Neo N36L Dual-Core Processor (1297.87-MHz K8-class CPU) [ paul@biggiesmalls /mnt/Quattro ] # grep memory /var/run/dmesg.boot [ 20:24 ] real memory = 4294967296 (4096 MB) avail memory = 4095074304 (3905 MB) [ paul@biggiesmalls /mnt/Quattro/torrents ] # uname -a [ 14:07 ] FreeBSD biggiesmalls 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 `dd if=/dev/zero of=file bs=1024k count=10000 [ 14:07 ] 10000+0 records in 10000+0 records out 10485760000 bytes transferred in 648.398978 secs (16171771 bytes/sec)` Правда, он забит на 100%: `Quattro 5.2T 5.2T 17G 100% /mnt/Quattro` Состоит массив из 4-х самсунгов по 2 тб. И, главное, кажется все перепробовал, но принципиальных отличий в скорости так и не заметил.
Чтение - не та бенчмарка. Горб по скорости в районе 1-го тер	Чтение - не та бенчмарка. Горб по скорости в районе 1-го терабайта меня удивил: lexa@new-gw:/archive# dd if=/dev/ada0 of=/dev/null bs=1G count=10 10+0 records in 10+0 records out 10737418240 bytes transferred in 57.559866 secs (186543489 bytes/sec) lexa@new-gw:/archive# dd if=/dev/ada0 of=/dev/null bs=1G count=10 skip=500 10+0 records in 10+0 records out 10737418240 bytes transferred in 51.813996 secs (207230074 bytes/sec) lexa@new-gw:/archive# dd if=/dev/ada0 of=/dev/null bs=1G count=10 skip=1000 10+0 records in 10+0 records out 10737418240 bytes transferred in 55.373747 secs (193908103 bytes/sec) lexa@new-gw:/archive# dd if=/dev/ada0 of=/dev/null bs=1G count=10 skip=2000 10+0 records in 10+0 records out 10737418240 bytes transferred in 69.051609 secs (155498451 bytes/sec) lexa@new-gw:/archive# dd if=/dev/ada0 of=/dev/null bs=1G count=10 skip=2700 10+0 records in 10+0 records out 10737418240 bytes transferred in 96.443796 secs (111333426 bytes/sec)
чтение -- процесс не дуструктивный	чтение -- процесс не дуструктивный
Поздно уже мерять, на этом массиве уже несколько терабайт ки	Поздно уже мерять, на этом массиве уже несколько терабайт кина налито.
Все тесты делались с дисками лежащими на спинке, фото - позж	Все тесты делались с дисками лежащими на спинке, фото - позже. И загрузка (svc_t, всякий %load) по дискам была одинаковая, вряд-ли там все пять заглючили одинаково.
не верю. это противоречит физике. у тебя ведь есть собственн	не верю. это противоречит физике. у тебя ведь есть собственный дд, померяй.
один раз винт глючил, я думал уже, что умирает, а это оказал	один раз винт глючил, я думал уже, что умирает, а это оказался провод виноват, потом через этот провод вообще данные ходить перестали, хотя никаких перегибов не было... Может они виноваты в снижении скорости?
На ем, родимом. Но не хватает длины питания.	На ем, родимом. Но не хватает длины питания.
В теории да, а на практике там вот чего намеряют: http://ben	В теории да, а на практике там вот чего намеряют: http://benchmarkreviews.com/index.php?option=com_content&task=view&id=84...
Там было 121-125k Т.е. подозреваю что 128+мелочь на данные+	Там было 121-125k Т.е. подозреваю что 128+мелочь на данные+метаданные. А размер блока можно и через ashift дотянуть до любого желаемого. И на чтение и на запись. Но сдается мне, это для ZFS будет скорее вредно. Чтение в любом случае префетчится, а растить блок на запись без нужды как-то глупо.
Про недостаточную длину проводов не подумал. Они ведь на SAT	Про недостаточную длину проводов не подумал. Они ведь на SATA2?
Во время копирования надо параллельно запустить systat -vm 3	Во время копирования надо параллельно запустить systat -vm 3 и смотреть строчку KB/t - килобайт на "транзакцию", то есть выяснить, блоками какого размера ZFS обращается к носителю. Подозреваю, что мелкими, а современным дискам от этого значительно плохеет в смысе скорости. Либо как-то заставить ZFS работать с носителем блоками не менее чем по 64K (а лучше всего по MAXPHYS=128K), либо поверх дисков создавать geom_cache с размером блока 128K, а ZFS уже на gcache создавать. Резко лучше становится, когда gcache форсирует работу с дисками блоками по 128K (правда, он только на чтение влияет, на запись он прозрачный и на запись ничего не кеширует).
ну то, что там намеряли -- это филькина грамота. трансфер-то	ну то, что там намеряли -- это филькина грамота. трансфер-то на внешних и внутренних дорожках существенно разный.
Не, ну 10 - это совсем другая	Не, ну 10 - это совсем другая избыточность. По моему опыту, raidz любит CPU и сильно. Я вот про это писал: http://blog.lexa.ru/2010/11/06/freebsd_zfs_performance_prosto_vozmite_mo... Вместе с тем, вот для хранилища, куда суточный трафик - ну 200Gb в плохом случае (100G бэкапов ну и допустим два фильма в BD) - я однозначно за raidz. Оно настолько удобнее администрируется, что аппаратный массив просто в топку. А вот что делать с задуманной, но пока не сделанной "внешней дисковой полкой" - я пока не решил. Но диски свободные есть, поэкспериментируем и так и эдак.

Свежие комментарии

Pages