RAID of netwerk wordt traag tijdens verwijderen

[codemann]

Mijn fileserver heeft een Asus M3N78 PRO moederbord met 6 harde schijven aangesloten op het moederbord, allemaal SATA 3GB/s poorten. De fileserver draait op Linux (Fedora) met hierop apache, mysql, proftpd en samba geinstalleerd, en de schijven zijn in een software RAID5/LVM configuratie geconfigureerd.

Nu heb ik al een heel tijdje dat wanneer ik via de samba share een bestand aan het verplaatsen ben, en terwijl bijv. muziek aan het spelen ben via dezelfde share, dat tijdens het verwijderen op de server de muziek volledig hangt. Ik merkte dit eerst bij een film die aan het afspelen was, maar later merkte ik dat het zelfs bij muziek was.

Ik heb er nu eindelijk eens tijd voor gemaakt om dit verder te bekijken en te kijken of alles wel optimaal op deze server werkt.

Ik ben begonnen met de snelheid van de RAID5 te testen :

[root@fileserver ~]# for i in 1 2 3 4 5; do hdparm -tT /dev/md0; done

/dev/md0:
Timing cached reads: 1000 MB in 2.00 seconds = 500.09 MB/sec
Timing buffered disk reads: 342 MB in 3.07 seconds = 111.43 MB/sec

/dev/md0:
Timing cached reads: 1194 MB in 2.00 seconds = 597.00 MB/sec
Timing buffered disk reads: 316 MB in 3.00 seconds = 105.18 MB/sec

/dev/md0:
Timing cached reads: 1280 MB in 2.00 seconds = 640.26 MB/sec
Timing buffered disk reads: 344 MB in 3.01 seconds = 114.36 MB/sec

/dev/md0:
Timing cached reads: 1134 MB in 2.00 seconds = 567.19 MB/sec
Timing buffered disk reads: 342 MB in 3.01 seconds = 113.57 MB/sec

/dev/md0:
Timing cached reads: 1006 MB in 2.00 seconds = 503.17 MB/sec
Timing buffered disk reads: 348 MB in 3.00 seconds = 115.87 MB/sec

Deze reads lijken mij heel erg laag, niet?

Nochtans als ik controleer of ze echt als SATA schijven gevonden worden dan krijg ik het juiste terug lijkt me :

[root@fileserver ~]# hdparm -I /dev/sdb | grep SATA
Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5
* SATA-I signaling speed (1.5Gb/s)
* SATA-II signaling speed (3.0Gb/s)

Ik heb nog wat zitten Googlen, maar ik vind niks over een langzame verbinding bij het verwijderen van bestanden, of over trage verbindingen met Samba.

Heeft iemand misschien hints in welke richting ik kan zoeken?

[BCC]

Ligt dit niet meer aan Samba / je netwerk snelheid dan aan je disksnelheid? Die ziet er namelijk erg goed uit. Wat gebeurd er als je de bestanden verwijdert via bijvoorbeeld FTP of ssh terwijl je film of muziek luistert?

[ Voor 17% gewijzigd door BCC op 24-11-2009 22:40 ]

[blaataaps]

Is het ext3 of bijvoorbeeld XFS?

[Nvidiot]

Lijkt niet zo heel erg snel nee, vergeleken met mijn 4-disk raid5 (software raid 5, geen LVM)

/dev/md0:
Timing cached reads: 2340 MB in 2.00 seconds = 1170.93 MB/sec
Timing buffered disk reads: 714 MB in 3.01 seconds = 237.41 MB/sec

/dev/md0:
Timing cached reads: 2388 MB in 2.00 seconds = 1194.04 MB/sec
Timing buffered disk reads: 748 MB in 3.01 seconds = 248.58 MB/sec

/dev/md0:
Timing cached reads: 2370 MB in 2.00 seconds = 1185.78 MB/sec
Timing buffered disk reads: 742 MB in 3.01 seconds = 246.75 MB/sec

/dev/md0:
Timing cached reads: 2374 MB in 2.00 seconds = 1187.32 MB/sec
Timing buffered disk reads: 746 MB in 3.00 seconds = 248.41 MB/sec

/dev/md0:
Timing cached reads: 2376 MB in 2.00 seconds = 1188.70 MB/sec
Timing buffered disk reads: 746 MB in 3.01 seconds = 248.12 MB/sec

[codemann]

Wow, jullie zijn snel, alvast bedankt voor de vele reacties.
Het is ext3, dat was ik inderdaad vergeten te vermelden. Kan het zijn omdat ik de schijven gewoon onboard heb aangesloten dat het snelheidsverschil heeft?

Ik heb nog even wat zitten testen :
1. Ik zet een MP3tje op
2. Ik kopieer op de linuxbak met MC een groot bestand (7GB) binnen de LVM RAID, dit gaat maar tegen 22MB/s, het geluid stottert niet
3. Ik verwijder het bestand op de linuxbak in MC, het geluid stottert niet
4. Ik kopieer op een WinXP machine met TC hetzelfde groot bestand naar dezelfde locatie, dit gaat maar tegen 10-15MB/s, het geluid stottert nog steeds niet
5. Ik verwijder het bestand op een WinXP machine met TC, mijn muziek blijft hangen nog geen 2sec nadat ik het start tot het bestand verwijderd is.

Conclusie van mij: Samba doet inderdaad raar, maar mijn kopieersnelheden zijn ook niet echt wat het moet zijn. Ik ben dus nog steeds heel verward.

Samba is een eigen compile van samba 3.4.3, niet echt iets speciaals gekozen tijdens de compile

./configure --prefix=/opt/samba-3.4.3 --sysconfdir=/etc/samba --enable-shared-libs=no --without-winbind --with-configdir=/etc/samba

smb.conf :

[global]
workgroup = LAN
server string = FILESERVER
security = share
hosts allow = 192.168.1.101 192.168.1.102 192.168.1.103 192.168.1.104 192.168.1.105
log file = /var/log/samba/log.%m
max log size = 50
dns proxy = no
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

[private]
comment = private share
path = /home/fileserver/private
force user = codemann
force group = codemann
read only = no
guest ok = yes
map hidden = yes
create mask = 704

[public]
comment = public share
path = /home/fileserver/public
force user = codemann
force group = codemann
read only = no
guest ok = yes
map hidden = yes
create mask = 704

[web]
comment = web server
path = /home/webserver
force user = codemann
force group = codemann
read only = no
guest ok = yes
map hidden = yes
create mask = 704

[BCC]

En als je deze ook nog even toevoegd aan je config (de standaard samba performance hack) ?

read size = 65536
read prediction = true

Dit gaat waarschijnlijk niet een magische oplossing zijn, dus: meten is weten! Installeer Munin en kijk wat er gebeurt met je CPU, Disk en Netwerk verkeer als je gaat kopieren.

[ Voor 52% gewijzigd door BCC op 24-11-2009 23:43 ]

[codemann]

Regel toegevoegd in [global], service restart.

Test 1 : Bestand verwijderen en filmpje kijken dat toevallig opstond >> geen problemen (lichte euforie)
Test 2 : Bestand verwijderen en filmpje kijken + muziek afspelen (zwaardere test) >> muziek blijft onmiddellijk hangen en het filmpje speelt door. Heel op het einde hangt het filmpje heel even.

Muziek was met WinAMP, video met Windows Media Player. WinAMP heeft een 2sec buffer, WMP een automatische. Dus de buffer gaat vermoed ik WMP gered hebben.

Ik lees je tip van Munin nu pas, is dit een soort Cacti? Ik ga het in ieder geval morgen eens bekijken.

[BCC]

Eeh ja, maar dan voor eigenlijk bijna al je system resources.

[Addow]

Codemann,
Ik weet ook niet of het helpt, maar ik heb mits volgende tweaks een zeer stabiele & snelle samba kunnen verkrijgen. Ik heb quasi dezelfde opstelling met een software Raid5 zonder LVM.

Tijdens het kopiëren en verwijderen moet je je htop eens in de gaten houden. Het blijft wel een vreemd fenomeen.

Samba tweaks in [global] in smb.conf:

#### Performance Hacks ####
# Set read size and prediction
read size = 65536
read prediction = true

# Set send and receive delay and buffer size
socket options = TCP_NODELAY SO_SNDBUF=8192 SO_RCVBUF=8192

# Disable logging (default level is 1) may improve some more
debug level = 0

Hier stats van het kopiëren van mijn nLite versie van WinXP naar in xp gemounte raid5 disk:


Dit zijn de metingen op m'n file server:

Monitoring eth0...    (press CTRL-C to stop)

   rx:   11269.61 kB/s  7641 p/s            tx:     231.28 kB/s  3788 p/s^C


 eth0  /  traffic statistics

                             rx       |       tx
--------------------------------------+----------------------------------------
  bytes                    784.04 MB  |      16.12 MB
--------------------------------------+----------------------------------------
          max             11.24 MB/s  |   237.36 kB/s
      average             10.60 MB/s  |   223.02 kB/s
          min             10.36 MB/s  |   217.73 kB/s
--------------------------------------+----------------------------------------
  packets                     544330  |        270337
--------------------------------------+----------------------------------------
          max               7804 p/s  |      3888 p/s
      average               7355 p/s  |      3653 p/s
          min               7197 p/s  |      3565 p/s
--------------------------------------+----------------------------------------
  time                  1.23 minutes

Ik heb een 100Mbit lijn liggen, dus haal zowat de theoretische netwerksnelheden.

Dit zijn de raid5 snelheden die behoorlijk in de buurt van nvidiot liggen:

/dev/md0:
Timing cached reads: 2696 MB in 2.00 seconds = 1348.23 MB/sec
Timing buffered disk reads: 760 MB in 3.00 seconds = 252.98 MB/sec

/dev/md0:
Timing cached reads: 2726 MB in 2.00 seconds = 1362.52 MB/sec
Timing buffered disk reads: 630 MB in 3.00 seconds = 209.67 MB/sec

/dev/md0:
Timing cached reads: 2768 MB in 2.00 seconds = 1384.41 MB/sec
Timing buffered disk reads: 652 MB in 3.01 seconds = 216.96 MB/sec

/dev/md0:
Timing cached reads: 2748 MB in 2.00 seconds = 1373.75 MB/sec
Timing buffered disk reads: 764 MB in 3.01 seconds = 253.90 MB/sec

/dev/md0:
Timing cached reads: 2680 MB in 2.00 seconds = 1339.84 MB/sec
Timing buffered disk reads: 648 MB in 3.01 seconds = 215.52 MB/sec

[codemann]

Ik heb dit weekend weer even tijd gehad om verder te testen en heb even het hele samba/netwerk verhaal vergeten, ik focus me vooral op het feit waarom mijn hdparm resultaten zo laag zijn.

Na wat zoekwerk zag ik opeens in /proc/mdstat dat er achter 1 van de schijven (F) stond (Faulty). Schijf is nog binnen garantie, dus ik kan hem nog omwisselen, hopelijk is dat de reden ook. Maar ergens betwijfel ik het... Linux detecteert het als faulty dus ik vermoed niet dat het invloed gaat hebben op prestaties. Maar ik moet hem sowieso vervangen dus dat doen we maar alvast.

Ook ben ik SNMP en Cacti aan het installeren, dat moest toch nog gebeuren. En ook die Munin zal ik dan even er bij zetten.

Ik ben er dus nog steeds mee bezig, maar ik kan er niet altijd gemakkelijk aan verder werken gezien ik het nogal druk heb