[ZFS oud systeem] lage kopieer snelheden (Normaal/FTP/Samba)

[Simkin]

Ik heb op mijn oude Qnap NAS het Debian OS geïnstalleerd (de DOM vervangen door een SSD). De SSD maakt gebruik van het EXT4 bestandssysteem en de diskaray van ZFS. Functioneel gezien werkt alles maar ik ben niet tevreden over de snelheid van de bestandsoverdracht via Samba en/of FTP. deze komt niet boven de 30MB/s terwijl dit voorheen dik 90MB/s was.

Systeem
Qnap ts-509
Intel(R) Core(TM)2 Duo CPU E7500 // 4 GB RAM
Debian Linux 7

fstab
root@nas:/opt# cat /etc/fstab

code:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdg1 during installation
UUID=446d7473-7795-4628-aa4f-c77930facd3b /               ext4    noatime,nodiratime,discard,errors=remount-ro 0       1
# /tmp was on /dev/sdg2 during installation
UUID=19c17f7b-2104-4c4c-9b93-403fc17257f2 /tmp            ext4    noatime,nodev,noexec,nosuid    0       2
# swap was on /dev/sdg3 during installation
UUID=c1513eb8-83f3-4599-80a1-db1cdbf3277e none            swap    sw              0       0

mountpoints
root@nas:/opt# mount

code:

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=448743,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=360292k,mode=755)
/dev/disk/by-uuid/446d7473-7795-4628-aa4f-c77930facd3b on / type ext4 (rw,noatime,nodiratime,errors=remount-ro,user_xattr,barrier=1,data=ordered,discard)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5219820k)
/dev/sdf2 on /tmp type ext4 (rw,nosuid,nodev,noexec,noatime,user_xattr,barrier=1,data=ordered)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
naspool/data on /mnt/data type zfs (rw,noatime,xattr)

SSD snelheid
De SSD waarop het OS geïnstalleerd staat lijkt erg langzaam te zijn maar volgens mij niet langzamer dan de DOM die er in zat:
root@nas:/opt# time dd if=/dev/zero of=test bs=1M count=10240

code:

10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 325.032 s, 33.0 MB/s

Zpool snelheid
Als ik naar mijn ZFS mounted pool schrijf gaat het gelukkig beter:
root@nas:/mnt/data# time dd if=/dev/zero of=foo bs=1M count=10240

code:

10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 27.5021 s, 390 MB/s

Kopieren op de zpool zelf gaat wel erg langzaam (ongeveer 70MB/s)

code:

root@nas:/mnt/data/Storage1/Video/Movies/Akira (1988)# rsync --progress Akira.mk
Akira.mkv
  8529536715 100%   69.83MB/s    0:01:56 (xfer#1, to-check=0/1)

sent 8530577990 bytes  received 31 bytes  71988000.18 bytes/sec
total size is 8529536715  speedup is 1.00

En als ik puur de doorvoer test:
root@nas:/mnt/data# dd if=/dev/zero of=/dev/null bs=1M count=128000

code:

128000+0 records in
128000+0 records out
134217728000 bytes (134 GB) copied, 18.4878 s, 7.3 GB/s

Zpool config
Mijn ZFS pool is als volgt geconfigureerd:
root@nas:/opt# zfs get all naspool

code:

NAME     PROPERTY              VALUE                  SOURCE
naspool  type                  filesystem             -
naspool  creation              Mon Aug 19 19:40 2013  -
naspool  used                  7.02T                  -
naspool  available             3.70T                  -
naspool  referenced            217K                   -
naspool  compressratio         1.00x                  -
naspool  mounted               no                     -
naspool  quota                 none                   default
naspool  reservation           none                   default
naspool  recordsize            128K                   default
naspool  mountpoint            none                   local
naspool  sharenfs              off                    default
naspool  checksum              on                     default
naspool  compression           on                     local
naspool  atime                 off                    local
naspool  devices               on                     default
naspool  exec                  on                     default
naspool  setuid                on                     default
naspool  readonly              off                    default
naspool  zoned                 off                    default
naspool  snapdir               hidden                 default
naspool  aclinherit            restricted             default
naspool  canmount              on                     default
naspool  xattr                 on                     default
naspool  copies                1                      default
naspool  version               5                      -
naspool  utf8only              off                    -
naspool  normalization         none                   -
naspool  casesensitivity       sensitive              -
naspool  vscan                 off                    default
naspool  nbmand                off                    default
naspool  sharesmb              off                    default
naspool  refquota              none                   default
naspool  refreservation        none                   default
naspool  primarycache          all                    default
naspool  secondarycache        all                    default
naspool  usedbysnapshots       0                      -
naspool  usedbydataset         217K                   -
naspool  usedbychildren        7.02T                  -
naspool  usedbyrefreservation  0                      -
naspool  logbias               latency                default
naspool  dedup                 off                    local
naspool  mlslabel              none                   default
naspool  sync                  standard               default
naspool  refcompressratio      1.00x                  -
naspool  written               217K                   -
naspool  snapdev               hidden                 default

Zoals je ziet vallen deze snelheden erg tegen. Kan het zijn dat ZFS geen goede keuze is geweest, heb ik ergens een fout gemaakt in de configuratie of ligt de oorzaak bij de langzame ssd waarop het OS geïnstalleerd staat? Advies is zeer welkom!

[CAPSLOCK2000]

ZFS staat bekend als niet bijzonder snel en nogal veeleisend voor je hardware. Misschien is het inderdaad wat te veel gevraagd. Probeer je SSD eens via het netwerk te gebruiken, dan weten we of het aan ZFS ligt of niet.

[Hero of Time]

Niet om 't een of ander, mare:

De SSD maakt gebruik van het EXT4 bestandssysteem en de diskaray van ZFS.

ZFS op de SSD is 't dus niet. De performance op de SSD zou prima moeten zijn.

Wat ik zo zie met wat er is gedaan, performt de ZFS array prima. Tegelijk lezen en schrijven geeft een write speed van zo'n 70 MB/s. Dat is prima in orde. De SSD daarentegen geeft maar 30 MB/s, wat ver onder de norm is.
Ter vergelijking, op mijn SSD (bestand van 2 GB):

$ dd if=/dev/zero of=bigfile bs=1M count=2048
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 6.14292 s, 350 MB/s

En op een mechanische schijf, 1 TB WD Green met 2 GB:

$ dd if=/dev/zero of=bigfile bs=1M count=2048
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 41.3886 s, 51.9 MB/s

En 3 TB WD Green:

$ dd if=/dev/zero of=tempfile bs=1M count=2048
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 13.6617 s, 157 MB/s

De mechanische schijven staan niet in RAID, en de 1 TB is wat ouder dan de 3 TB, vandaar het verschil er tussen. Ik heb ook nog een hele oude, SATAI 500 GB schijf op 7200 RPM en die geeft zo'n 60 MB/s. Dat is nog steeds 2x je SSD. Ergens is er iets goed mis met dat ding. Maar zonder verdere specs van schijven en controller is er niet veel meer over te zeggen.

[Simkin]

Ik zal vanavond de snelheid naar een share op de SSD testen maar ben ook bang dat dat niet veel zal helpen. Is het te verklaren dat de snelheid naar de Zpool traag is vanwege de snelheid van de SSD waar het OS op staat?

Wat ik verder niet had gemeld is dat de SSD is aangesloten met een 44 pins pata kabel
De SSD volgens webmin:

code:

Disk size: 122.11 GB | Make and model: ATA SanDisk SDSSDP12 | Cylinders: 15567 | Partition format: MSDOS

SMART test:

code:

smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model:     SanDisk SDSSDP128G
Serial Number:    133230401711
LU WWN Device Id: 5 001b44 a10bb94af
Firmware Version: 2.0.0
User Capacity:    128,035,676,160 bytes [128 GB]
Sector Size:      512 bytes logical/physical
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  ACS-2 revision 3
Local Time is:    Tue Feb 25 11:10:09 2014 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                    was never started.
                    Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                    without error or no self-test has ever 
                    been run.
Total time to complete Offline 
data collection:        (  120) seconds.
Offline data collection
capabilities:            (0x51) SMART execute Offline immediate.
                    No Auto Offline data collection support.
                    Suspend Offline collection upon new
                    command.
                    No Offline surface scan supported.
                    Self-test supported.
                    No Conveyance Self-test supported.
                    Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                    power-saving mode.
                    Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                    General Purpose Logging supported.
Short self-test routine 
recommended polling time:    (   2) minutes.
Extended self-test routine
recommended polling time:    (  24) minutes.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0002   100   100   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0002   100   100   000    Old_age   Always       -       3460
 12 Power_Cycle_Count       0x0002   100   100   000    Old_age   Always       -       17
171 Unknown_Attribute       0x0002   100   100   000    Old_age   Always       -       0
172 Unknown_Attribute       0x0002   100   100   000    Old_age   Always       -       0
173 Unknown_Attribute       0x0002   100   100   000    Old_age   Always       -       91
174 Unknown_Attribute       0x0002   100   100   000    Old_age   Always       -       13
187 Reported_Uncorrect      0x0002   100   100   000    Old_age   Always       -       0
230 Head_Amplitude          0x0002   100   100   000    Old_age   Always       -       303
232 Available_Reservd_Space 0x0003   100   100   005    Pre-fail  Always       -       0
234 Unknown_Attribute       0x0002   100   100   000    Old_age   Always       -       501
241 Total_LBAs_Written      0x0002   100   100   000    Old_age   Always       -       24841496200
242 Total_LBAs_Read         0x0002   100   100   000    Old_age   Always       -       25311754012

SMART Error Log Version: 1
No Errors Logged

Warning! SMART Self-Test Log Structure error: invalid SMART checksum.
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      3460         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

[Hero of Time]

Je maakt niet gebruik van een SSD, maar een flash geheugen kaartje. Daar ga je geen 300 MB/s mee halen. Je ZFS draait zoals ik zei redelijk. Omdat we niet weten welke schijven je gebruikt, kunnen we niet meer zeggen.

[Simkin]

Pardon, had niet door dat dat nog relevant was. Mijn overige disks (Seagate Baracuda):
4x ATA ST3000DM001-9YN1
1x ATA ST3000DM001-1CH1

flash geheugen kaartje?

Ik merk dat ik het nog steeds niet begrijp. Waarom is bvb de snelheid naar mijn Zpool gelimiteerd tot ongeveer 30 MB/s als de Zpool snelheid zelf blijkbaar acceptabel is? Wordt die limitatie dan toch veroorzaakt door de langzame Sandisk disk/kaart waar enkel het OS op draait? en wordt die trage disk snelheid mogelijk veroorzaakt omdat ik een pata-sata adapter gebruik?

Waar kan ik het beste verder gaan met mijn onderzoek?

[Hero of Time]

Waar heb je 't over dat je array maar 30 MB/s haalt? Enige wat ik zie in je TS is dat je in /opt die snelheid haalt, want dus NIET je array is. Zit jij verkeerd te kijken, zien wij het verkeerd, of heb je niet alle informatie gegeven?

[Ultraman]

SATA SSDs middels een SATA->PATA adapter aansluiten op een PATA controller is inderdaad geen aanrader. Daadwerkelijke resultaten die je er mee behaald zullen verschillen per controller...
Verder eens met Hero of Time, let goed op wat je aan het meten bent!

De benchmark met dd geeft een vertekend beeld omdat je transparante compressie toepast. Als je daar allemaal nullen naartoe schrijf mag je raden wat er met die nullen gebeurd

En de andere test is een "rsync" waarmee je een file op de pool zelf inleest en wegschrijft, tegelijkertijd.
Als je daar 70MB/s haalt is dat denk ik niet slecht, maar ik weet te weinig over je pool om er iets nuttigs over te zeggen.
Hoe is je pool ingedeeld? Want dat zie ik niet terug. Is dit toevallig een "raidz" (gok ik als ik de size zo bekijk icm 5x3TB disks)? Want dan lijkt 70MB/s voor tegelijkertijd lezen en schrijven op dezelfde pool mij in orde.

Wat doet het als je van de pool kopieert naar het RAM (of naar /dev/null)?
Bijvoorbeeld:

stefan@bacchus:~/Downloads$ rsync --progress Fedora-Live-Desktop-x86_64-20-1.iso /dev/shm/
Fedora-Live-Desktop-x86_64-20-1.iso
   999292928 100%   79.89MB/s    0:00:11 (xfer#1, to-check=0/1)

sent 999415008 bytes  received 31 bytes  79953203.12 bytes/sec
total size is 999292928  speedup is 1.00

Dit is een single 320GB WD Blue uit 2007/8 welke tegen de 80MB/s haalt met puur sequentieel lezen als ik een Fedora 20 Live image van tegen de 1GB naar een tmpfs (=RAMdisk) kopieer.

[ Voor 3% gewijzigd door Ultraman op 25-02-2014 13:45 ]

[Simkin]

Hero of Time schreef op dinsdag 25 februari 2014 @ 13:19:
Waar heb je 't over dat je array maar 30 MB/s haalt? Enige wat ik zie in je TS is dat je in /opt die snelheid haalt, want dus NIET je array is. Zit jij verkeerd te kijken, zien wij het verkeerd, of heb je niet alle informatie gegeven?

Ik heb je niet alle informatie gegeven:

ik ben niet tevreden over de snelheid van de bestandsoverdracht via Samba en/of FTP. deze komt niet boven de 30MB/s terwijl dit voorheen dik 90MB/s was.

Hierbij bedoel ik dat zodra ik een bestand via samba en/of FTP van/naar een locatie op de 'raidz' naspool kopieer ik niet boven de 30 MB/s kom, dit terwijl ik voorheen (Qnap OS met Raid5 config) met gemak de 90MB/s haalde. Ik heb dus eigenlijk twee problemen, een trage 'flash geheugen kaartje' en een trage kopieersnelheid over FTP/samba naar een share die zich bevindt op de zpool; de snelheden lijken overigens overeen te komen.

@Ultraman
idd een raidz configuratie!
root@nas:/mnt/data/Storage1/Upload# rsync --progress N7100XXUEMK9_N7100PHNEMK2_PHN.zip /dev/shm

N7100XXUEMK9_N7100PHNEMK2_PHN.zip
  1216479938 100%  117.29MB/s    0:00:09 (xfer#1, to-check=0/1)

sent 1216628533 bytes  received 31 bytes  115869387.05 bytes/sec
total size is 1216479938  speedup is 1.00

Dat lijkt dus in order of is dat enkel omdat het bestand kleiner is dan 4GB?

[Ultraman]

Die vuistregel van minstens 2x (of 4x) de hoeveelheid RAM en liever nog groter is om te voorkomen dat je mogelijk data uit de ARC cache haalt en juist alles van disk.
Als je deze file voor het uitvoeren van die rsync al lange tijd niet hebt aangeraakt en wel andere data heen en weer hebt lopen schuiven is met 4GB RAM de kans vrij klein dat hij nog ergens in de ARC cache zat. Voor de zekerheid zou je kunnen rebooten en het daarna nog eens kunnen proberen, maar 117MB/s vanaf die 3TB disken in raidz is best plausibel en ook binnen de lijntjes.
Ik verdenk daarom nu niet langer een probleem met de pool, al zou je meer tests moeten doen om dat echt uit te sluiten.

En omdat je ook maar 4GB RAM hebt staat ook je prefetch als het goed is ook niet aan, dus dat heeft ook niet meegespeeld. Ik meen trouwens dat prefetch aardig kan helpen met Samba read speeds, maar dan wil je 8GB RAM of meer hebben, het wordt immers niet voor niets <8GB default uitgeschakeld.
Samba vereist vaker wat tuning om goede snelheden te halen.

FTP zou ik wel vlotter verwachten, of je nou leest of schrijft van/naar de pool.
Zeker weten dat het niet aan het netwerk ligt? Een kabel of aansluiting die kuren is gaan vertonen? Kan aan beide kanten en het pad zelf liggen. Systematisch testen en meten zou ik zeggen door het netwerk eens te benchen.
Een goede tool om mee te beginnen is "iperf" als je dat wilt gaan doen.

[Simkin]

Als ik iperf goed gebruik lijkt er inderdaad iets goed mis te zijn op netwerk gebied:
:/bin/iperf.exe -c 192.168.1.148 -P 1 -i 1 -p 5001 -f M -t 10

------------------------------------------------------------
Client connecting to 192.168.1.148, TCP port 5001
TCP window size: 0.06 MByte (default)
------------------------------------------------------------
[196] local 127.0.0.1 port 61197 connected with 192.168.1.148 port 5001
[ ID] Interval       Transfer     Bandwidth
[196]  0.0- 1.0 sec  12.0 MBytes  12.0 MBytes/sec
[196]  1.0- 2.0 sec  11.3 MBytes  11.3 MBytes/sec
[196]  2.0- 3.0 sec  11.3 MBytes  11.3 MBytes/sec
[196]  3.0- 4.0 sec  11.3 MBytes  11.3 MBytes/sec
[196]  4.0- 5.0 sec  11.3 MBytes  11.3 MBytes/sec
[196]  5.0- 6.0 sec  11.3 MBytes  11.3 MBytes/sec
[196]  6.0- 7.0 sec  11.3 MBytes  11.3 MBytes/sec
[196]  7.0- 8.0 sec  11.3 MBytes  11.3 MBytes/sec
[196]  8.0- 9.0 sec  11.3 MBytes  11.3 MBytes/sec
[196]  9.0-10.0 sec  11.3 MBytes  11.3 MBytes/sec
[196]  0.0-10.1 sec   114 MBytes  11.3 MBytes/sec
Done.

Dit is ook de snelheid die ik nu haal via FTP en Samba..

eth1

code:

Settings for eth1:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
        Link detected: yes

Ik ga alle schakels er tussenuit halen (NAS rechtstreeks verbinden met mijn pc). Zal de resultaten binnenkort posten.

[Ultraman]

Er lijkt ergens een link te zijn teruggevallen op 100Mbit. Check zeker de tussenliggende kabels, want voor Gigabit moeten alle acht aders werken. Als er maar eentje stuk is ergens in een kabel dan val je terug naar 100Mbit. En als er eentje matig is dan krijg je soms wel link speeds van 1Gbit maar door de vele re-transmits stort het alsnog in elkaar.
Jij lijkt echt zo constant 11.3MB/s te halen dat ik terugval naar 100Mbit verwacht ergens in de keten.