ZFS NAS Performance Issues - Opslag en back-up

zaterdag 17 december 2011 17:29

Acties:

0 Henk 'm!

Topicstarter

Naar aanleiding van de problemen van mijn ZFS NAS doorvoersnelheid hier een aparte topic. Mijn systemen zijn als volgt samengesteld: gallery: CurlyMo

Vanaf het begin heb ik een RAIDZ pool gedraaid.

Mijn eerste build:
Supermicro X7SPA-HF
2GB DDR2
3x Samsung EcoGreen F4EG HD204UI, 2TB
Solaris 11 Express

De doorvoersnelheden waren dramatisch slecht. Hieronder een lijstje van alles wat ik op dit systeem heb geprobeerd.

iperf

code:

Iperf:
(Server) --> (Cliënt)
Solaris --> Windows 7:
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 125 KByte (default)
------------------------------------------------------------
[ 4] local 10.0.0.140 port 5001 connected with 10.0.0.144 port 50633
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 345 MBytes 289 Mbits/sec

Windows 7 --> Solaris
------------------------------------------------------------
Client connecting to 10.0.0.144, TCP port 5001
TCP window size: 48.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.139 port 53137 connected with 10.0.0.144 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 906 MBytes 759 Mbits/sec

DD

code:

DD Test

Write: +/- 110
Read: +/- 231

Samba

code:

socket options = TCP_NODELAY SO_RCVBUF=13172 SO_SNDBUF=13172 SO_KEEPALIVE IPTOS_LOWDELAY IPTOS_THROUGHPUT
use sendfile = yes
min receivefile size = 16384
aio read size = 16384
aio write size = 16384
aio write behind = yes

Allemaal verschillende combinaties geprobeerd zonder succes.

iperf test nr. 2

code:

Windows 7   --> Solaris 11
8KB (default)   252Mb/s 125KB (default)
16KB    559Mb/s 125KB
32KB    800Mb/s 125KB
64KB    1.08Gb/s    125KB
Windows 7   <-- Solaris 11
8KB (default)   1001Mb/s    48KB (default)
64KB    1009Mb/s    125KB

Tweede build
inventaris: NAS
Solaris 11 Express

iperf

code:

Solaris --> Ubuntu:
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 10.0.0.142 port 5001 connected with 10.0.0.140 port 59001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 1.00 GBytes 862 Mbits/sec

Ubuntu --> Solaris
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 125 KByte (default)
------------------------------------------------------------
[ 4] local 10.0.0.140 port 5001 connected with 10.0.0.142 port 59379
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 1.05 GBytes 903 Mbits/sec

code:

Solaris --> Windows 7
------------------------------------------------------------
Client connecting to 10.0.0.140, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[208] local 10.0.0.142 port 50168 connected with 10.0.0.140 port 5001
[216] local 10.0.0.142 port 50169 connected with 10.0.0.140 port 5001
[200] local 10.0.0.142 port 50167 connected with 10.0.0.140 port 5001
[176] local 10.0.0.142 port 50164 connected with 10.0.0.140 port 5001
[168] local 10.0.0.142 port 50163 connected with 10.0.0.140 port 5001
[156] local 10.0.0.142 port 50162 connected with 10.0.0.140 port 5001
[192] local 10.0.0.142 port 50166 connected with 10.0.0.140 port 5001
[184] local 10.0.0.142 port 50165 connected with 10.0.0.140 port 5001
[ ID] Interval Transfer Bandwidth
[ 208] 0.0-10.0 sec 136 MBytes 114 Mbits/sec
[ 192] 0.0-10.0 sec 132 MBytes 111 Mbits/sec
[ 184] 0.0-10.0 sec 135 MBytes 113 Mbits/sec
[ 156] 0.0-10.0 sec 136 MBytes 114 Mbits/sec
[ 176] 0.0-10.0 sec 136 MBytes 115 Mbits/sec
[ 200] 0.0-10.0 sec 138 MBytes 116 Mbits/sec
[ 168] 0.0-10.0 sec 138 MBytes 115 Mbits/sec
[ 216] 0.0-10.0 sec 141 MBytes 118 Mbits/sec
[SUM] 0.0-10.0 sec 1.07 GBytes 917 Mbits/sec

DD
time sh -c "dd if=/dev/zero of=/zpool/testfile.bin bs=8k count=8000000 && sync"
166 MB/s

time sh -c "dd of=/dev/zero if=/zpool/testfile.bin bs=8k count=8000000 && sync"
169 MB/s
[/code]

IOZone -a

code:

                                                            random  random    bkwd   record   stride
              KB  reclen   write rewrite    read    reread    read   write    read  rewrite     read   fwrite frewrite   fread  freread
              64       4  192775  349627  1065453  1164490  771871  319833  913733   438026   928745   447763   466884  761754   941544
              64       8  344180  719961  1423256  1121540 1164744  582179 1105563   604394  1208201   556618   645896  998544  1526297
              64      16  447608  800261  2904533  3191614 2204640  955301 1458477   939851  1831353  1425489   998769 1641233  2057954
              64      32  753122 1309144  4293656  5291248 3355605 1333578 1882776  1360525  2452831  1105287  1361883 1945645  2672829
              64      64 1282262 1596289  5795012  5790434 2677450 1774195 2364133  1779409  3040650   781010  1522316 1527820  3034356
             128       4  194857  561125  1360480  1622540 1049850  505987  941559   498193  1040172   571296   556664  913964   984784
             128       8  313806  707273  1709234  2169860 1094335   15342 1268107   680623  1254116   684226   711319 1254522  1561726
             128      16  377664 1122960  3046826  3197239 1999035 1075087 1880532  1163349  2101745  1067160  1093763 1601609  2206312
             128      32  901760 1439023  4431744  4922046 3554700 1599084 2615617  1706261  3049108  1378074  1599547 2838943  3880509
             128      64 1727634 1937519  7965970  9083189 6728748 2672888 4587069  2843208  5569204  2556224  2561220 3460858  4567803
             128     128 2102147 2331444  7130838  7545679 5806459 2460571 2848224  2027975  4272070   780347  1048858 2134853  2508862
             256       4  246877  555414  1532322  1651533 1153321  489552 1053125   492273   892199   514069   531150  955023   992425
             256       8  430195  740086  1827112  1742827 1524608  661535 1305623   656232  1413558   577994   689922 1560178  1650856
             256      16  717285 1190233  3085114  3240170 2440327 1098250 2152391  1023781  2369659  1137638  1108265 2151321  2327446
             256      32 1108214 1684293  4570956  4923512 3766669 1651042 2696130  1650949  3043773  1580481  1663543 2725259  3013483
             256      64 1571418 2247630  6079351  6569836 5325851 2227675 3509486  2461296  6258033  2751988  1895274 2879591  3464294
             256     128 2563035 2640698  6915970  7735465 6094886 2640501 3414987  2639902  4407875  1361231  1306317 2031396  2245461
             256     256 2169288 2667105  3657698  3706214 3506022 2666423 2876100  3706664  2669190   812823  1561832 1840690  1924980
             512       4   51200  412885  1145446  1204937  851827  364927  802516   364654   775703    52941   392654  893358  1011713
             512       8  513081  767512  1735936  2142059 1542020  673666 1177159   678969  1426256   724164   705328 1575938  1684578
             512      16  828348 1254581  2437665  3218472 2474149 1147748 2254759  1202028  2316811  1168884  1137529 2179184  2317980
             512      32 1590345 2474027  5630587  6742098 5278582 2286071 4263862  2509757  5168025  2284903  2317197 3846214  4342642
             512      64 1624926 2402541  5957845  6481850 4923849 2347646 4527748  2611844  4783027  2022977  2811965 4455026  4973078
             512     128 3030821 2944022  6729409  7422261 6394637 2890901 4342934  3102428  6329134  1646922  1636275 2640459  2860516
             512     256 2996148 2890840  4002608  3999507 3935337 2892437 3461145  3141365  3767008  1604487  1528258 1777083  1960908
             512     512 2975637 3086543  5024856  5067807 4970992 3846651 4377219  3938106  4745656  1112848  2246400 2611516  2640704
            1024       4   89864  420875  1110698  1141536  838626  365307  800050   359284   795598   402824   402531  908694  1015882
            1024       8  582508   91103  2540958  2942615 2129267  110332 1410396   668423  1337021   724149   695200 1549022  1698215
            1024      16  935154 1317748  2805074  3251552 2521471 1159755 2155666  1207411  2178520  1175767  1116600 2076963  2398265
            1024      32 1678669 1992526  3437290  4786314 3969841 1738361 2852996  1862125  3291348  1750405  1670230 2667176  3092555
            1024      64 2256021 2592302  5503119  6439429 5474431 2376399 4411691  2270243  5690961  2241256  2192763 3249793  3671230
            1024     128 3314025 3435611  6281877  7476428 6559328 2926498 6356632  4078097  6917902  1700959  2211831 2695288  2933383
            1024     256 3313866 4340129  5391698  5567281 5388349 4097806 4901523  4284312  4127836  1789885  1759746 2036222  2760350
            1024     512 3261362 3113207  4094268  4180523 4063427 3039314 3710437  3357843  4017474  1765440  1721284 1996560  2039573
            1024    1024 3130428 3219024   121369   120641 4971965 4063843 4452550  4195474  3542486   111838  2003545 1976417  2020105
            2048       4   98655  583804  1111861  1189292  839347   95340  798163   365586   784658   401338   389436  198217   208385
            2048       8  627056  191292  1856661  2120118 1549306  684470 1452497   698233  1386553   716854   700390 1537422  1681573
            2048      16  989802 1363450  2824872  3179720 2372834 1171673 2265503  1222035  2228722  1185136  1131459 2162652   226372
            2048      32 1335869 2085363  3946907  4582199 3841912 1780920 3266188  1937737  3281504  1791721  2270448 2760046  3089035
            2048      64 2265626 3657000  5030614  5186323 5043674 2340489 4491725  2844277  6321514  3070436  2172036 3224752  3518912
            2048     128 3524471 3384610  5643040  5198856 6057744 2863943 4644763  3308283  7338238  1729806  1728211 2656370  2884398
            2048     256 3495297 3549589  4024291  4223446 4105018 3220471 3879434  3663348  4376496   220594  2381349 2096145  2338061
            2048     512 4572515 3345834  4187370  4285520 4196619 3234959 3953290  3643398  4356709  1845013  1860031 2107170  2107093
            2048    1024 4385513 3373853  5318569  5519501 5360070 4312335 4947371  4328922  5007768  2461578  1933986 2054082  2087888
            2048    2048 3292854  233711  3765365  3792212 3786109 4321298 3555358   237337  3592311  1168299   221743  224218   225279
            4096       4  209761  430706  1121237  1153444  139738  100560  817417   415925   138042   221406   389943  954563  1041986
            4096       8  132668  805200   386447  1998965 1500981  739231  370711   701378  1407570   716967   185013 1526664  1606278
            4096      16 1014356 1377245  2794077  2908914 2340586 1162007 2265556  1222708  2169438   205519  1519293 2117771  2233318
            4096      32 1379577  405060  4871005  5298413 4676366  228597 4096273  2646193  4128584  2350016  1693946 3726975  3842105
            4096      64  386813 2966191  4881389   455470 4541454  418509 4343655  2866386  4432952  2199790  2184470  433809  3253646
            4096     128 3586414 4780024  6748748  7037388 6883682 4329987 6379508  4971066  4958831  1723824  1719518 2696350   422354
            4096     256 4639209 4735258   432022   457909 5177933 4491073 3842240  3537267  4546241  1837507  1833392 2088681  2080355
            4096     512 3558742 4665530  4141112  4289331 4231167 3410781 4003792   444969  6032676  2464582  1889396  406953  2743562
            4096    1024 3555378  447604  5475340  5468447 5411436 4526465 4035284  3733579  4375774  1898838  1910361 2136556  2082368
            4096    2048 3430825  452695  4015738  4047558 5132116 4602772  445896  4756888  4047682  1909505  1908601 2090769  2121272
            4096    4096 4092046  434220   456281  5113145 5051216 4096023  451105   449027  3904979   902405  1952240 2181161  2206825
            8192       4  280335  266407  1137130   608071 1109290  337133  200225   503785   308840   221687   139341  202566   267319
            8192       8  399199 1086338  1909092  2001013  592375  292917  398908   138373   655413   962410   946732  405706   407319
            8192      16  269730  597909  2757334  2835606  740214 1648305  626010  1662017  2239494   533053   532014 2875426  2958464
            8192      32 1487276 2872318  3820987  3974616 3375388 1885801  396264  1966870  3351741  1726473  1705935  738091  2895656
            8192      64 1737845 2959629  4743791  4885051 4401657 2713511 4218115  2827653  4246652  2240017   690142 3254673  4192421
            8192     128 3629691 3648891  5132861  5339883 5079051 3463730  827315  3812193  5022702   632489   387840 2687720  2698267
            8192     256 3637563  812385  3821044  4017610 3996047 3511442  804392   838665  3919674  1820000  2391756 2097330   724568
            8192     512  784222  787840   805662   811568  843406  826811 4063462  3723507  4683793  1894574  1904625 2129455   406812
            8192    1024  828320 3600883  4218387  4282333 4203308  780266 4122695  3796166   821752   414300   408763 2178715  2171152
            8192    2048 3497687 3605618  4055550  5312786 5244821 4716097 4047239  3639208  5494691   406250  1929779 2144479   724828
            8192    4096 4222745 4293530  4114531  4007639 5241428 4240250 4067736  4390103  4175193   656568  2463020  409026   410398
            8192    8192 3160470 3259781  5319463   845321 5319846 4027649 5278038  4141326  4173345   525192  1972129 2230335  2238875

IOzone -t 2

code:

        Children see throughput for  2 initial writers  =  635968.72 KB/sec
        Parent sees throughput for  2 initial writers   =   13804.81 KB/sec
        Min throughput per process                      =  311928.91 KB/sec
        Max throughput per process                      =  324039.81 KB/sec
        Avg throughput per process                      =  317984.36 KB/sec
        Min xfer                                        =     496.00 KB

        Children see throughput for  2 rewriters        =  492281.19 KB/sec
        Parent sees throughput for  2 rewriters         =   10322.56 KB/sec
        Min throughput per process                      =       0.00 KB/sec
        Max throughput per process                      =  492281.19 KB/sec
        Avg throughput per process                      =  246140.59 KB/sec
        Min xfer                                        =       0.00 KB

        Children see throughput for  2 readers          = 1926058.31 KB/sec
        Parent sees throughput for  2 readers           =   94095.60 KB/sec
        Min throughput per process                      =  952574.81 KB/sec
        Max throughput per process                      =  973483.50 KB/sec
        Avg throughput per process                      =  963029.16 KB/sec
        Min xfer                                        =     500.00 KB

        Children see throughput for 2 re-readers        = 1163698.00 KB/sec
        Parent sees throughput for 2 re-readers         =   48493.98 KB/sec
        Min throughput per process                      =       0.00 KB/sec
        Max throughput per process                      = 1163698.00 KB/sec
        Avg throughput per process                      =  581849.00 KB/sec
        Min xfer                                        =       0.00 KB

        Children see throughput for 2 reverse readers   =  835271.88 KB/sec
        Parent sees throughput for 2 reverse readers    =   48462.35 KB/sec
        Min throughput per process                      =       0.00 KB/sec
        Max throughput per process                      =  835271.88 KB/sec
        Avg throughput per process                      =  417635.94 KB/sec
        Min xfer                                        =       0.00 KB

        Children see throughput for 2 stride readers    = 1502496.31 KB/sec
        Parent sees throughput for 2 stride readers     =  102410.81 KB/sec
        Min throughput per process                      =  749671.31 KB/sec
        Max throughput per process                      =  752825.00 KB/sec
        Avg throughput per process                      =  751248.16 KB/sec
        Min xfer                                        =     512.00 KB

        Children see throughput for 2 random readers    =  820612.50 KB/sec
        Parent sees throughput for 2 random readers     =   48111.54 KB/sec
        Min throughput per process                      =       0.00 KB/sec
        Max throughput per process                      =  820612.50 KB/sec
        Avg throughput per process                      =  410306.25 KB/sec
        Min xfer                                        =       0.00 KB

        Children see throughput for 2 mixed workload    = 1116094.59 KB/sec
        Parent sees throughput for 2 mixed workload     =    9078.51 KB/sec
        Min throughput per process                      =  337888.66 KB/sec
        Max throughput per process                      =  778205.94 KB/sec
        Avg throughput per process                      =  558047.30 KB/sec
        Min xfer                                        =     220.00 KB

        Children see throughput for 2 random writers    =  424610.14 KB/sec
        Parent sees throughput for 2 random writers     =    8556.80 KB/sec
        Min throughput per process                      =    6666.64 KB/sec
        Max throughput per process                      =  417943.50 KB/sec
        Avg throughput per process                      =  212305.07 KB/sec
        Min xfer                                        =      56.00 KB

Laatste Config
Zelfde systeem
ZFSguru FreeBSD 8.2

memtest

code:

memtest 486m 2

  Stuck Address       : ok
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok
  Block Sequential    : ok
  Checkerboard        : ok
  Bit Spread          : ok
  Bit Flip            : ok
  Walking Ones        : ok
  Walking Zeroes      : ok
  8-bit Writes        : ok
  16-bit Writes       : ok

DD

code:

dd if=/dev/label/disk1 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 7.965443 secs (134800015 bytes/sec)

dd if=/dev/label/disk2 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 8.320615 secs (129045972 bytes/sec)

dd if=/dev/label/disk3 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 7.793387 secs (137776014 bytes/sec)

Samba
Zie eerste kopje m.b.t. Samba.

Windows 7
Aan de cliënt side heb ik het volgende geprobeerd:

Energy Efficient Ethernet = Ingeschakeld -> uit
Groen Ethernet = Ingeschakeld -> uit
Prioriteit & VLAN = Prioriteit & VLAN ingeschakeld -> uit, tenzij je QoS of VLAN tagging gebruikt, maar verwacht van niet

Snelheid & duplex = Automatisch onderhandelen -> Force 1Gbit

Resultaten
Leesheden:
De snelheid is nu gemiddeld 25000 kbytes/s waar die voorheen gemiddeld 14000 kbytes/s
Het kopiëren begint met met gemiddeld 50000 kbytes/s maar zakt dan snel weg tot de hierboven genoemde resultaten.

Schrijven:
De snelheid is nu gemiddeld 7500 kbytes/s waar die voorheen gemiddeld 14000 kbytes/s
Het kopiëren begint met met gemiddeld 50000 kbytes/s maar zakt dan héél snel weg tot ongeveer 1000 kbytes/s met dus pieken naar de 14000 kbytes/s.

Wie o wie kan mij helpen om op de gehoopte doorvoersnelheden te komen zoals verwacht bij een gigabit netwerk....

Sinds de 2 dagen regel reageer ik hier niet meer

zaterdag 17 december 2011 19:31

Acties:

0 Henk 'm!

nielsdc

Wat zijn je ZFS settings?
Zijn er verder nog system settings getuned?

Ik neem aan dat ZFSGuru dat regelt, maar het kan geen kwaad dat te controleren.

Je hebt 4K sector drives, dus moet je pool aangemaakt zijn met ashift=12
Ook moeten je partities 4K aligned zijn.

Gebruik je dedup of compressie?

Deze thread heeft wat tuning tips voor freebsd: http://forums.freebsd.org/showthread.php?t=9187
Gebruik je inderdaad async io? samba moet hier support voor hebben en de aio kernel module moet geladen zijn.

Je hebt erg weinig geheugen voor een ZFS setup, hoewel het wel gewoon zou moeten kunnen.
De output van "vmstat 1" en "iostat 1" tijdens het testen van samba performance zou nuttig zijn, dat geeft een idee waar het systeem mee bezig is.

Waarschijnlijk staat zfs prefetch uit, als je dat aan zet zou je read performance omhoog moeten gaan.

Je lage schrijf snelheid wordt waarschijnlijk veroorzaakt doordat samba in kleinere blokken schrijft dan de ZFS blocksize. De ZFS blocksize is waarschijnlijk 128KB. Als samba nu een block van 16KB wegschrijft, dan moet ZFS eerst het hele 128KB blok inlezen, 16KB daarvan overschrijven in het geheugen, partity opnieuw berekenen over het hele blok, en het hele 128KB blok weer wegschrijven. Als je een 128KB wegschrijft is het alleen parity bereken en het blok wegschrijven. Het wordt erger als samba daarna het volgende 16KB blok wegschrijft, want dan wordt het hele proces nog een keer herhaald.

Je wilt dus kleine sync writes voorkomen, en het liefst alles async schrijven, zodat een aantal kleine writes samengevoegd worden. Controleer je samba config dus goed! (is aio module geladen, is samba gecomiled met aio support, is use strict false?)
Je aio read size en aio write size doen nu precies het verkeerde! Lees of schrijf requests kleiner dan deze waarde worden sync gedaan! Beide waarden moeten 0 zijn!!!

Je kan eventueel ook dat ZFS blocksize kleiner zetten, en kijken wat dat voor effect heeft.

Het is ook een goed idee om 2 status scripts the downloaden: http://jhell.googlecode.com/files/arcstat.pl en http://jhell.googlecode.com/files/arc_summary.pl
Die output geeft info over over de interne caching, parameters etc.

Ik verwacht dat als je je samba config goed zet en prefetching aanzet je al behoorlijke performance moet hebben. Normaal gesproken moet je met jou setup gewoon wirespeed moeten halen.

zaterdag 17 december 2011 19:51

Acties:

0 Henk 'm!

CurlyMo

Topicstarter

nielsdc schreef op zaterdag 17 december 2011 @ 19:31:
Wat zijn je ZFS settings?
Zijn er verder nog system settings getuned?

Ik neem aan dat ZFSGuru dat regelt, maar het kan geen kwaad dat te controleren.

Je hebt 4K sector drives, dus moet je pool aangemaakt zijn met ashift=12
Ook moeten je partities 4K aligned zijn.

Heb ik gedaan

Gebruik je dedup of compressie?

Nope

Deze thread heeft wat tuning tips voor freebsd: http://forums.freebsd.org/showthread.php?t=9187
Gebruik je inderdaad async io? samba moet hier support voor hebben en de aio kernel module moet geladen zijn.

Dit is een van de configuratie variaties die ik heb geprobeerd zonder dat dit voor aanzienlijke winst heeft gezorgd. Die AIO kan je dus als niet al te relevant beschouwen voor dit moment.

Je hebt erg weinig geheugen voor een ZFS setup, hoewel het wel gewoon zou moeten kunnen.

7.9GiB voor 4TB zou toch genoeg moeten zijn?

De output van "vmstat 1" en "iostat 1" tijdens het testen van samba performance zou nuttig zijn, dat geeft een idee waar het systeem mee bezig is.

Heb ik gedaan

Waarschijnlijk staat zfs prefetch uit, als je dat aan zet zou je read performance omhoog moeten gaan.

Zover ik weet staat dat standaard aan wanneer er genoeg geheugen is en het een 64bit systeem betreft.

Je lage schrijf snelheid wordt waarschijnlijk veroorzaakt doordat samba in kleinere blokken schrijft dan de ZFS blocksize. De ZFS blocksize is waarschijnlijk 128KB. Als samba nu een block van 16KB wegschrijft, dan moet ZFS eerst het hele 128KB blok inlezen, 16KB daarvan overschrijven in het geheugen, partity opnieuw berekenen over het hele blok, en het hele 128KB blok weer wegschrijven. Als je een 128KB wegschrijft is het alleen parity bereken en het blok wegschrijven. Het wordt erger als samba daarna het volgende 16KB blok wegschrijft, want dan wordt het hele proces nog een keer herhaald.

Je wilt dus kleine sync writes voorkomen, en het liefst alles async schrijven, zodat een aantal kleine writes samengevoegd worden. Controleer je samba config dus goed! (is aio module geladen, is samba gecomiled met aio support, is use strict false?)
Je aio read size en aio write size doen nu precies het verkeerde! Lees of schrijf requests kleiner dan deze waarde worden sync gedaan! Beide waarden moeten 0 zijn!!!

Hier ga ik gelijk naar kijken.

Je kan eventueel ook dat ZFS blocksize kleiner zetten, en kijken wat dat voor effect heeft.

Hoe doe ik dit?

Het is ook een goed idee om 2 status scripts the downloaden: http://jhell.googlecode.com/files/arcstat.pl en http://jhell.googlecode.com/files/arc_summary.pl
Die output geeft info over over de interne caching, parameters etc.

Ik verwacht dat als je je samba config goed zet en prefetching aanzet je al behoorlijke performance moet hebben. Normaal gesproken moet je met jou setup gewoon wirespeed moeten halen.

Sinds de 2 dagen regel reageer ik hier niet meer

zaterdag 17 december 2011 20:57

Acties:

0 Henk 'm!

nielsdc

I had alleen de 2GB van de eerste config gezien, maar 8GB is inderdaad zat.

De write performance moet haast wel een probleem met sync writes zijn. Ik kan me niet voorstellen wat anders zo'n performance probleem zou veroorzaken.

Je kan zelf de impact van sync writes testen door een dd naar een file te doen met een 8K blocksize.
Dat zou behoorlijk snel moeten zijn. Doe nu hetzelfde met oflag=dsync.

Voor samba zouden de volgende settings moeten werken:

aio read size = 0
aio write size = 0
aio write behind=true
strict sync = no
strict allocate = no
sync always = no
min receivefile size = 131072

Je kan dit testen door een grote write te doen op de samba client, en de iostat output op de server in de gaten te houden. Als je een hoop reads ziet gaat er nog steeds iets fout.

Je kan de zfs properties bekijken met: "zfs get all <poolname>"
Je kan de blocksize kleiner maken met: zfs set recordsize=8k <poolname> of als je het alleen voor een bepaald filesystem wil doen: zfs set recordsize=8k <poolname/filesystemname>
Ik zou ook atime updates uitzetten: zet set atime=off <poolname>

sysctl vfs.zfs geeft je de module parameters
sysctl kstat.zfs geeft je een aantal interne staistieken.

Kan je de output van de 2 sysctl commando's posten?

zaterdag 17 december 2011 21:07

Acties:

0 Henk 'm!

CurlyMo

Topicstarter

sysctl vfs.zfs

code:

vfs.zfs.l2c_only_size: 0
vfs.zfs.mfu_ghost_data_lsize: 786104832
vfs.zfs.mfu_ghost_metadata_lsize: 49627648
vfs.zfs.mfu_ghost_size: 835732480
vfs.zfs.mfu_data_lsize: 321442304
vfs.zfs.mfu_metadata_lsize: 98996736
vfs.zfs.mfu_size: 427326464
vfs.zfs.mru_ghost_data_lsize: 853762560
vfs.zfs.mru_ghost_metadata_lsize: 55821824
vfs.zfs.mru_ghost_size: 909584384
vfs.zfs.mru_data_lsize: 240718336
vfs.zfs.mru_metadata_lsize: 177818112
vfs.zfs.mru_size: 559819776
vfs.zfs.anon_data_lsize: 0
vfs.zfs.anon_metadata_lsize: 0
vfs.zfs.anon_size: 2409984
vfs.zfs.l2arc_norw: 1
vfs.zfs.l2arc_feed_again: 1
vfs.zfs.l2arc_noprefetch: 1
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: 1780720640
vfs.zfs.arc_meta_used: 791596856
vfs.zfs.arc_min: 890360320
vfs.zfs.arc_max: 7122882560
vfs.zfs.dedup.prefetch: 1
vfs.zfs.mdcomp_disable: 0
vfs.zfs.write_limit_override: 0
vfs.zfs.write_limit_inflated: 25441591296
vfs.zfs.write_limit_max: 1060066304
vfs.zfs.write_limit_min: 33554432
vfs.zfs.write_limit_shift: 3
vfs.zfs.no_write_throttle: 0
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.synctime_ms: 1000
vfs.zfs.txg.timeout: 5
vfs.zfs.scrub_limit: 10
vfs.zfs.vdev.cache.bshift: 16
vfs.zfs.vdev.cache.size: 0
vfs.zfs.vdev.cache.max: 16384
vfs.zfs.vdev.write_gap_limit: 4096
vfs.zfs.vdev.read_gap_limit: 32768
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.vdev.bio_flush_disable: 0
vfs.zfs.cache_flush_disable: 0
vfs.zfs.zil_replay_disable: 0
vfs.zfs.zio.use_uma: 0
vfs.zfs.version.zpl: 5
vfs.zfs.version.spa: 28
vfs.zfs.version.acl: 1
vfs.zfs.debug: 0
vfs.zfs.super_owner: 0

kstat.zfs

code:

kstat.zfs.misc.xuio_stats.onloan_read_buf: 0
kstat.zfs.misc.xuio_stats.onloan_write_buf: 0
kstat.zfs.misc.xuio_stats.read_buf_copied: 0
kstat.zfs.misc.xuio_stats.read_buf_nocopy: 0
kstat.zfs.misc.xuio_stats.write_buf_copied: 0
kstat.zfs.misc.xuio_stats.write_buf_nocopy: 2889
kstat.zfs.misc.zfetchstats.hits: 7152739
kstat.zfs.misc.zfetchstats.misses: 4019666
kstat.zfs.misc.zfetchstats.colinear_hits: 176
kstat.zfs.misc.zfetchstats.colinear_misses: 4019490
kstat.zfs.misc.zfetchstats.stride_hits: 7077394
kstat.zfs.misc.zfetchstats.stride_misses: 27
kstat.zfs.misc.zfetchstats.reclaim_successes: 35308
kstat.zfs.misc.zfetchstats.reclaim_failures: 3984182
kstat.zfs.misc.zfetchstats.streams_resets: 17
kstat.zfs.misc.zfetchstats.streams_noresets: 75369
kstat.zfs.misc.zfetchstats.bogus_streams: 0
kstat.zfs.misc.arcstats.hits: 3966528
kstat.zfs.misc.arcstats.misses: 95618
kstat.zfs.misc.arcstats.demand_data_hits: 1241975
kstat.zfs.misc.arcstats.demand_data_misses: 8434
kstat.zfs.misc.arcstats.demand_metadata_hits: 2407992
kstat.zfs.misc.arcstats.demand_metadata_misses: 64001
kstat.zfs.misc.arcstats.prefetch_data_hits: 14
kstat.zfs.misc.arcstats.prefetch_data_misses: 3261
kstat.zfs.misc.arcstats.prefetch_metadata_hits: 316547
kstat.zfs.misc.arcstats.prefetch_metadata_misses: 19922
kstat.zfs.misc.arcstats.mru_hits: 795326
kstat.zfs.misc.arcstats.mru_ghost_hits: 6440
kstat.zfs.misc.arcstats.mfu_hits: 2854744
kstat.zfs.misc.arcstats.mfu_ghost_hits: 853
kstat.zfs.misc.arcstats.allocated: 168673
kstat.zfs.misc.arcstats.deleted: 25
kstat.zfs.misc.arcstats.stolen: 0
kstat.zfs.misc.arcstats.recycle_miss: 0
kstat.zfs.misc.arcstats.mutex_miss: 0
kstat.zfs.misc.arcstats.evict_skip: 595
kstat.zfs.misc.arcstats.evict_l2_cached: 0
kstat.zfs.misc.arcstats.evict_l2_eligible: 0
kstat.zfs.misc.arcstats.evict_l2_ineligible: 6144
kstat.zfs.misc.arcstats.hash_elements: 119504
kstat.zfs.misc.arcstats.hash_elements_max: 126406
kstat.zfs.misc.arcstats.hash_collisions: 513824
kstat.zfs.misc.arcstats.hash_chains: 30574
kstat.zfs.misc.arcstats.hash_chain_max: 7
kstat.zfs.misc.arcstats.p: 3653291008
kstat.zfs.misc.arcstats.c: 7122882560
kstat.zfs.misc.arcstats.c_min: 890360320
kstat.zfs.misc.arcstats.c_max: 7122882560
kstat.zfs.misc.arcstats.size: 1356591336
kstat.zfs.misc.arcstats.hdr_size: 30479928
kstat.zfs.misc.arcstats.data_size: 992244736
kstat.zfs.misc.arcstats.other_size: 333866672
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: 3
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: 0
kstat.zfs.misc.vdev_cache_stats.hits: 0
kstat.zfs.misc.vdev_cache_stats.misses: 0

Ik probeer samba nu opnieuw te installeren met de aio support

De dd parameter wordt niet herkend. Zou je kunnen aangeven hoe de twee commando's zouden moeten zijn om dat te testen.

Sinds de 2 dagen regel reageer ik hier niet meer

zaterdag 17 december 2011 21:45

Acties:

0 Henk 'm!

nielsdc

Hier is een voorbeeld van mijn systeem:

root@tbox:/data/backup/tmp# dd if=/dev/zero of=dd.test bs=8K count=1000000 && sync
1000000+0 records in
1000000+0 records out
8192000000 bytes (8.2 GB) copied, 17.0645 s, 480 MB/s
root@tbox:/data/backup/tmp# dd oflag=dsync if=/dev/zero of=dd.test bs=8K count=1000000 && sync
1000000+0 records in
1000000+0 records out
8192000000 bytes (8.2 GB) copied, 181.102 s, 45.2 MB/s

Ik gebruik ZFS op linux, maar ik verwacht dat jou waardes vergelijkbaar zullen zijn.
Het schrijven van kleine blokken is sync dus 10x target dan async!!

zaterdag 17 december 2011 21:48

Acties:

0 Henk 'm!

CurlyMo

Topicstarter

dd: unknown operand oflag

code:

dd if=/dev/zero of=/data/dd.test bs=8K count=1000000 && sync
1000000+0 records in
1000000+0 records out
8192000000 bytes transferred in 45.137829 secs (181488570 bytes/sec)

Daarnaast heb ik dus geprobeerd om Samba te hercompileren maar dat lukt maar niet. In de ports versie van samba krijg in de recycle bin niet werkend. Daarom heb ik een custom samba 3.5.12 gecompileerd. Aanvankelijk zonder aio support maar met een werkende recycle bin. Nu ik deze zelfde samba probeer te compileren met aio support krijg ik de volgende fout melding bij het opstarten "Abnormal server exit: Failed to setup RT_SIGNAL_AIO handler". Ik heb hierbij voor nu dus de keuze voor een samba met werkende recycle bin of met een werkende aio... Dus als iemand me kan helpen om dit in de ports versie van FreeBSD werkend te krijgen, graag. Aio testen gaat dus wel lukken, maar dan moet ik even de andere samba versie opstarten.

[ Voor 62% gewijzigd door CurlyMo op 18-12-2011 00:28 ]

Sinds de 2 dagen regel reageer ik hier niet meer

zondag 18 december 2011 05:04

Acties:

0 Henk 'm!

Verwijderd

CurlyMo, kun je me de volgende info nog geven?

1) Je draait denk ik RAID-Z? Mag ik de output van 'zpool status' zien?

2) kun je op FreeBSD nog even wat dd benchmarks doen?
# 32GB write
dd if=/dev/zero of=/tank/zerofile bs=1m count=32000 && sync
# read
dd if=/tank/zerofile of=/dev/null bs=1m

3) welke systeemversie van ZFSguru draai je? Kijk onder Status tab bij 'system version'.

4) je hebt de disks geformatteerd met ZFSguru? Zie je onder de Pools pagina ook dat het ashift=12 geoptimaliseerd is?

5) waar staat je OS op geïnstalleerd? De RAID-Z pool of iets anders?

Eventueel nog een aanbod om via SSH persoonlijk je systeem te testen, als je daar zin in hebt. Anders doen we het gewoon via adviezen.

zondag 18 december 2011 10:18

Acties:

0 Henk 'm!

CurlyMo

Topicstarter

1.

code:

  pool: backup
 state: ONLINE
 scan: scrub repaired 0 in 2h52m with 0 errors on Wed Dec 14 03:52:59 2011
config:

        NAME            STATE     READ WRITE CKSUM
        backup          ONLINE       0     0     0
          label/backup  ONLINE       0     0     0

errors: No known data errors

  pool: data
 state: ONLINE
 scan: scrub repaired 4K in 1h49m with 0 errors on Tue Dec 13 02:49:08 2011
config:

        NAME             STATE     READ WRITE CKSUM
        data             ONLINE       0     0     0
          raidz1-0       ONLINE       0     0     0
            label/disk1  ONLINE       0     0     0
            label/disk2  ONLINE       0     0     0
            label/disk3  ONLINE       0     0     0

errors: No known data errors

  pool: rpool
 state: ONLINE
 scan: scrub repaired 0 in 0h8m with 0 errors on Mon Dec 12 01:08:30 2011
config:

        NAME          STATE     READ WRITE CKSUM
        rpool         ONLINE       0     0     0
          gpt/System  ONLINE       0     0     0

errors: No known data errors

2.

code:

dd if=/dev/zero of=/data/test bs=1m count=32000 && sync
32000+0 records in
32000+0 records out
33554432000 bytes transferred in 174.919153 secs (191828233 bytes/sec)

dd if=/data/test of=/dev/null bs=1m
32000+0 records in
32000+0 records out
33554432000 bytes transferred in 160.433408 secs (209148658 bytes/sec)

3.

code:

Product     ZFSguru 0.1.9
Product build date  2011-Dec-07 @ 23:33 UTC
Distribution type   rootonzfs
System version  8.3-001 (checksum: 56cdda51f63c878e5e2874a82ad6567e)
FreeBSD version     8.2-STABLE
ZFS version     SPA: 28, ZPL: 5

4.

code:

Pool name   backup
Status  ONLINE
Scrub   scrub repaired 0 in 2h52m with 0 errors on Wed Dec 14 03:52:59 2011
Ashift  pool is optimized for 512 B sector disks (ashift=9)

Pool name   data
Status  ONLINE
Scrub   scrub repaired 4K in 1h49m with 0 errors on Tue Dec 13 02:49:08 2011
Ashift  pool is optimized for 4 KiB sector disks (ashift=12)

Pool name   rpool
Status  ONLINE
Scrub   scrub repaired 0 in 0h8m with 0 errors on Mon Dec 12 01:08:30 2011
Ashift  pool is optimized for 512 B sector disks (ashift=9)

5.

code:

1	ada0 GPT: System 250.1 GB 232.9 GiB 512 B <SAMSUNG HM251JI 2SS00 01> ATA-8 SATA 1.x device

Had wel gemogen maar ik heb geen mogelijkheid om de NAT instellingen van de router aan te passen waarachter ik zit.

[ Voor 3% gewijzigd door CurlyMo op 18-12-2011 10:20 ]

Sinds de 2 dagen regel reageer ik hier niet meer

zondag 18 december 2011 10:36

Acties:

0 Henk 'm!

Verwijderd

Je haalt dus 190-200MB/s aan interne doorvoer. Dat zou genoeg moeten zijn voor gigabit. Je netwerkthroughput lijkt ook goed.

Misschien kun je wat meer over je client vertellen? Je hebt één workstation getest of meerdere? Windows versie? Heb je ook behalve CIFS (Samba) zaken als SFTP, FTP, NFS of iSCSI getest? Met andere woorden, krijg je dezelfde performance bij andere protocollen?

Als je meerdere clients hebt is dat wel beter om ook te testen.

zondag 18 december 2011 12:19

Acties:

0 Henk 'm!

CurlyMo

Topicstarter

Op dit moment heb ik één cliënt met een gigabit netwerkkaart. Binnenkort komt er een nieuwe laptop waarin ook een gigabit kaart zodat ik het met twee cliënts kan testen. Op alle systemen draai ik Windows 7.

Ik draai hier voornamelijk CIFS en (S)FTP. Daarbij heb ik zojuist even een ISCSI schijf aangemaakt. NFS heb ik ooit wel gehad maar vond ik niet fijner werken dan CIFS.

Performance gemeten in Total Commander met een bestand van 4.684.907.418 bytes

Samba:
C->S: 52sec
S->C: 162sec

FTP:
C->S: 206sec
S->C: 144sec

ISCSI:
C->S: 50sec
S->C: 105sec

Bij het lezen vanaf iSCSI piekt tussen 600000 bytes/s en 300 bytes/s maar dat zal waarschijnlijk liggen aan de cache instellingen of iets dergelijks.

NFS mogelijkheden heb ik niet op mijn client.

Conclusie: vooral de leessnelheden zijn nog steeds erg slecht ondanks dat ik kopiëer naar een Intel SSD

Sinds de 2 dagen regel reageer ik hier niet meer

zondag 18 december 2011 12:38

Acties:

0 Henk 'm!

Verwijderd

Wat je kunt proberen is op je client een memory disk aan te maken en daar naartoe te kopiëren. Als je van je client naar je server stuurt haal je dus tegen de 94MB/s aan wat een prima score is. Alleen schrijven op je client is een stuk trager.

Kun je ook nog eens een CrystalDiskMark posten van je Samba share?

zondag 18 december 2011 14:37

Acties:

0 Henk 'm!

CurlyMo

Topicstarter

CrystalDiskMark heeft hier geen optie om share the benchen...

Sinds de 2 dagen regel reageer ik hier niet meer

zondag 18 december 2011 14:39

Acties:

0 Henk 'm!

Verwijderd

Jawel. Je moet je share naar een drive letter mappen. Als je dat nog niet gedaan hebt: ga naar de share toe en klik rechts, dan zie je Map network drive en kun je er X: van maken ofzo. Dan kun je met CDM je Samba share benchmarken.

zondag 18 december 2011 14:42

Acties:

0 Henk 'm!

CurlyMo

Topicstarter

Aha, de x64 versie van CDM heeft de optie niet, de 32bit versie wel...

Edit: De resultaten Samba:

	Read [MB/s]	Write [MB/s]
Seq	53.52	95.33
512k	53.76	78.19
4k	8.94	5.22
4k QD32	33.29	5.46

iSCSI:

	Read [MB/s]	Write [MB/s]
Seq	91.46	81.86
512k	86.73	73.66
4k	13.03	2.90
4k QD32	40.15	4.815

[ Voor 181% gewijzigd door CurlyMo op 18-12-2011 15:05 ]

Sinds de 2 dagen regel reageer ik hier niet meer

zondag 18 december 2011 15:08

Acties:

0 Henk 'm!

Verwijderd

iSCSI ziet er prima uit, Samba qua writes ook. Alleen de read is inderdaad laag. Dat is waarschijnlijk een Samba-specifiek probleem.

Maar dit zijn betere scores dan 10-20MB/s ik weet niet precies waar je eerst last van had? Mijn scores zijn 85MB/s read en 90-105MB/s write.

zondag 18 december 2011 15:27

Acties:

0 Henk 'm!

CurlyMo

Topicstarter

Heeft het zin om ook nog uit te zoeken waar de reads vandaan komen? De iperf test toont namelijk ook een groot verschil aan tussen de richting van de communicatie.

Sinds de 2 dagen regel reageer ik hier niet meer

zondag 18 december 2011 15:31

Acties:

0 Henk 'm!

Verwijderd

Ik denk dat je met Samba + AsyncIO support hogere reads haalt, zodat je het principe van queue depth via network storage kan toepassen. Als ik me niet vergis heeft ZFSguru standaard al Samba met AIO support gecompileerd, en wordt de AIO kernel module ook geladen (zie `kldstat`). Dus hoef je alleen nog maar AIO support in de smb.conf file te activeren. Daar had je laatst nog wat problemen mee begreep ik?

Verder zou je nog jumbo frames kunnen proberen, mits je router (switch) dit ondersteunt.

zondag 18 december 2011 15:35

Acties:

0 Henk 'm!

CurlyMo

Topicstarter

Klopt, ik krijg met de standaard samba versie in ZFSguru de vfs recycle object niet aan de gang. In mijn huidig gecompileerde versie werkt dat wel, maar dan AIO weer niet.

Ik zal wel even proberen hoe de scores zijn mét AIO door de andere samba te draaien.

Resultaten met een geconfigureerde AIO zoals in een eerdere reactie te lezen is:

	Read [MB/s]	Write [MB/s]
Seq	54.06	97.32
512k	54.15	95.72
4k	13.22	6.598
4k QD32	93.43	5.928

Conclusie AIO doet een hele hoop maar niet voor het lezen van grote bestanden

Nog andere suggesties? Zoals eerder aangegeven, ligt de oorzaak niet in de iperf resultaten van de server naar de cliënt?

[ Voor 55% gewijzigd door CurlyMo op 18-12-2011 15:50 ]

Sinds de 2 dagen regel reageer ik hier niet meer

zondag 18 december 2011 16:21

Acties:

0 Henk 'm!

Verwijderd

Je haalt in beide richtingen goede performance (4K QD32 read performance en sequential write) dus netwerk lijkt me geen issue. Enige is dat met de 4K QD32 er een hoge queue depth is wat enigszins nog van invloed kan zijn op netwerkperformance. De normale sequential I/O heeft een veel hogere queue depth (doorgaans

. Wellicht dat je met jumbo frames nog meer performance kunt krijgen. Toch wel raar dat je sequential read wat tegenvalt. Ik denk dat het combinatie is van netwerklatency en Samba settings. Je hardware inclusief netwerk is wel tot hogere snelheden in staat.

zondag 18 december 2011 16:25

Acties:

0 Henk 'm!

CurlyMo

Topicstarter

Zijn er nog gouden tips qua samba die ik zou kunnen proberen? Ik heb op dit moment een TP-Link WR-1043ND als router. Weet niet of daar jumbo frames support op zit.

Sinds de 2 dagen regel reageer ik hier niet meer

zondag 18 december 2011 16:28

Acties:

0 Henk 'm!

Verwijderd

Direct aansluiten zonder switch ertussen kun je proberen, en dan beide zijden MTU 7000 (jumbo frames) instellen.

maandag 19 december 2011 09:09

Acties:

0 Henk 'm!

Verwijderd

Maar dit zijn betere scores dan 10-20MB/s ik weet niet precies waar je eerst last van had? Mijn scores zijn 85MB/s read en 90-105MB/s write.

Dat zijn tenminste waardes waar je mee aan kunt komen.

Zou jij jou /etc/sysctl.conf, /usr/local/etc/smb.conf ens willen posten.
Ik krijg deze snelheden gewoon niet!
En dat terwijl ik toch een redelijk machine heb met Intel kaarten.

Alvast bedankt
Johan

maandag 19 december 2011 09:44

Acties:

0 Henk 'm!

nielsdc

Waarschijnlijk zit er een bug in de freebsd/zfs sendfile implementatie.

Hij zat in ieder geval nog in FREEBSD-8.1:

http://lists.freebsd.org/...2010-November/009945.html

Probeer sendfile eens uit te zetten in je samba config, dat zou dan moeten helpen.

maandag 19 december 2011 10:14

Acties:

0 Henk 'm!

Verwijderd

FreeBSD 9.0-RC2 kun je ook proberen, waarschijnlijk is die bug in elk geval daar wel opgelost. ZFSguru heeft een experimental system image met die FreeBSD versie.

Maar je kunt ook eerst het volgende in je smb.conf proberen:

code:

[global]
  use sendfile = no
  aio read size    = 16384
  aio write size   = 16384
  aio write behind = true
  socket options   = SO_KEEPALIVE TCP_NODELAY SO_RCVBUF=16384 SO_SNDBUF=16384

(eventueel alleen the use sendfile = no als je problemen krijgt met AIO support)

maandag 19 december 2011 18:14

Acties:

0 Henk 'm!

CurlyMo

Topicstarter

Verwijderd schreef op maandag 19 december 2011 @ 09:09:
[...]

Dat zijn tenminste waardes waar je mee aan kunt komen.

Zou jij jou /etc/sysctl.conf, /usr/local/etc/smb.conf ens willen posten.
Ik krijg deze snelheden gewoon niet!
En dat terwijl ik toch een redelijk machine heb met Intel kaarten.

Alvast bedankt
Johan

Mijn sysctl is helemaal leeg.

Mijn samba (alle unquoted):

code:

unix extensions = no
workgroup = WORKGROUP
server string = server
dns proxy = no
name resolve order = wins lmhost host
log file = /var/log/samba/log.%m
max log size = 50
syslog = 0
panic action = /usr/share/samba/panic-action %d
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
socket options = TCP_NODELAY SO_RCVBUF=131072 SO_SNDBUF=131072 SO_KEEPALIVE IPTOS_LOWDELAY IPTOS_THROUGHPUT

Let wel dat ik een standaard gecompileerde versie van Samba 3.5.12 heb gebruikt ipv van de ports versie van Samba. In die laatste doet de vfs recycle object het namelijk niet bij mij.

Sinds de 2 dagen regel reageer ik hier niet meer

dinsdag 20 december 2011 20:28

Acties:

0 Henk 'm!

FireDrunk

In je IPERF test in je TS staat 400Mbit van Solaris naar Windows? Lijkt me erg traag... Daar zou je read probleem ook wel eens kunnen liggen...

@CiPHER en TS, Jumbo Frames zijn 9000 bytes volgens mij...

Even niets...

dinsdag 20 december 2011 22:05

Acties:

0 Henk 'm!

CurlyMo

Topicstarter

FireDrunk schreef op dinsdag 20 december 2011 @ 20:28:
In je IPERF test in je TS staat 400Mbit van Solaris naar Windows? Lijkt me erg traag... Daar zou je read probleem ook wel eens kunnen liggen...

Let wel dat ik op dit moment ZFSguru draai en geen Solaris meer. De resultaten van die iperf tests staan volgens mij ook in de TS.

Sinds de 2 dagen regel reageer ik hier niet meer

woensdag 21 december 2011 06:49

Acties:

0 Henk 'm!

Verwijderd

Note: hele late edit (6-april-2012), maar wat ik hieronder schrijf klopt niet. Ik schreef 7000 MTU dat moet alles boven de 1500 zijn. Of zoals in de manpages van FreeBSD:

Selecting an MTU larger than
1500 bytes with the ifconfig( 8 ) utility configures the adapter to receive
and transmit jumbo frames.

FireDrunk schreef op dinsdag 20 december 2011 @ 20:28:
@CiPHER en TS, Jumbo Frames zijn 9000 bytes volgens mij...

Jumbo frames zijn boven de 7000 1500 MTU (Maximum Transmission Unit). Sommige adapters kunnen inderdaad 9000 MTU aan, maar anderen maar 7000 of een waarde hier ergens tussenin. Veelal staat in de manpage welke MTU wordt ondersteund door de hardware en de driver.

Voor de Intel-driver (em) is dit bijvoorbeeld:

The maximum MTU size for Jumbo Frames is 16114.

Besef wel: je switch moet de MTU ook ondersteunen, en dat is zeker niet altijd het geval. Daarom als je netwerk performanceproblemen hebt kun je het beste de switch even overslaan en direct verbinden. Echter, in geval van de TS lijkt zijn netwerk prima te zijn. Het enige wat een probleem vormt is de Samba read performance, aangezien hij met iSCSI read en Samba write performance zeer dicht bij de limiet van gigabit komt.

[ Voor 15% gewijzigd door Verwijderd op 06-04-2012 14:39 ]

woensdag 21 december 2011 15:27

Acties:

0 Henk 'm!

FireDrunk

Ah, nu zie ik het, ik zat naar de oude build te kijken

Je netwerk ziet er inderdaad prima uit.

Heel basaal misschien, maar heb je wel eens 4 SMB transfers tegelijk geprobeerd?

Even niets...

maandag 2 januari 2012 17:05

Acties:

0 Henk 'm!

CurlyMo

Topicstarter

Sinds kort heb ik een laptop met een gigabit netwerk kaart. De prestaties zijn precies hetzelfde als op mijn desktop. Lezen vanaf mijn NAS gaat twee keer zo langzaam als het schrijven. Jumbo frames lossen het probleem niet op.

Sinds de 2 dagen regel reageer ik hier niet meer

maandag 2 januari 2012 17:39

Acties:

0 Henk 'm!

Verwijderd

Kun je het volgende eens proberen?
In Windows vanaf je NAS twee grote bestanden kopiëren, beide naar iets wat lokaal snel genoeg is. Bijvoorbeeld naar twee losse snelle hardeschijven. Anders een memory disk kun je proberen.

Stel je haalt 45MB/s voor 1 en 45MB/s voor 2, dan zit je gecombineerd dus aan 90MB/s. Dit kan een indicatie zijn dat je sequential reads veroorzaakt door Windows niet genoeg queue depth hebben. Je 4K32 random read score zit boven de 90MB/s dus als er genoeg queue depth is zou dat ook voor sequential read moeten gelden.

donderdag 5 januari 2012 21:41

Acties:

0 Henk 'm!

CurlyMo

Topicstarter

Als ik twee grote bestanden kopieer naar mijn Samsung 470 SSD (via het netwerk) dan wordt de snelheid per kopieer actie twee keer zo langzaam.

Sinds de 2 dagen regel reageer ik hier niet meer

donderdag 5 januari 2012 21:45

Acties:

0 Henk 'm!

Verwijderd

Is dat met AIO support ingeschakeld? Dat is wel cruciaal voor deze test namelijk.

Zo ja, dan blijft er niet zoveel over behalve te constateren dat je Samba sequential read te laag is, maar andere protocollen wel degelijke performance geven. Zelf zou ik nog proberen een andere NIC in je server of liefst beide te plaatsen, maar dat is natuurlijk maar een gok. Ligt eraan hoe belangrijk je de hogere sequential read vindt, anders kun je het er ook gewoon bij laten.