iSCSI 100% bij intensief verkeer met PC

[Pippin]

Ok, dan verbind je met CIFS, ook wel SMB.
Dan denk ik dat ik nu zo ongeveer zou concluderen dat de combinatie NAS/DSM de culprit is want ik heb geen ideeën meer.

[Hankman]

Je zou nog even het top commando kunnen geven tijdens zo'n conversie.

Top levert onder meer deze regel op: Mem: 920824K used, 92664K free, 0K shrd, 103272K buff, 259160K cached

Wat moet ik met de waarden voor Shared, Buffered en Cached?

[Hankman]

Heb jij al eens een atto test gedaan?

Hoe moet ik dit nu weer interpreteren (lijkt mij niet goed):

[Hankman]

Dan denk ik dat ik nu zo ongeveer zou concluderen dat de combinatie NAS/DSM de culprit is want ik heb geen ideeën meer.

Dus hopen op een fix van Synology, downgraden naar 4.3 of (weer) een QNAP kopen?

[Hankman]

MMV, Babylonia, Peeweesyn, Ben en Birdman: dank voor het meedenken!

[peeweesyn]

Nou Hankman en anderen, ik heb ook eens een Atto test gedraaid en schrok van de beroerde resultaten:



Toen heb ik de packages Crashplan en Craftbukkit gestopt (beide Java pakketten) waardoor de memory usage van 79 naar ca. 45% ging, en zie daar:




Dus, het lijkt vooral Java of Java packages die de performance drastisch reduceren. Ik wist dat Java memory hungry is, maar dat het ook zo'n negatieve invloed op het fileserver gedeelte zou hebben had ik niet gedacht.

Hankman, draai je toevallig een Java package?

[Pippin]

@Hankman
Het zwalkt wel wat ja.
Het is ook belangrijk dat tijdens de test zowel PC als NAS zo min mogelijk met andere dingen bezig zijn.

De waarde aan de linkerkant van de grafiek geeft de grootte van  het bestand weer, van een 0,5 KB tot 8 MB.
Elk bestand wordt naar de NAS geschreven en weer gelezen tot er 256MB per bestand bereikt is. Althans zo begrijp ik dat laatste.
Door meting van de tijd die het duurt wordt dan bepaalt wat de snelheid per bestands grootte is.
Dat wordt dus weergegeven door de rode en groene kolommen.

[Hankman]

Hankman, draai je toevallig een Java package?

Niet dat ik weet PeeWeeSyn.

Ik heb SABnzbd draaien en Logiteh Media Server, en moet daarvoor ook Perl en Python draaien. Verder een paar standaard Synology pakketten.....

[Ben(V)]

@Hankman Als je scrubbing hebt gestart zijn voorlopig al je metingen zinloos, want dat belast je disken.
Verder zou ik (als scrubbing gereed is) eens een test doen met al je pakketten gestopt en met name even kijken of je toevallig media server en indexing aan hebt staan.

@MMD Het verschil tussen volume en disk is volgens mij nu te verklaren doordat hij scrubbing (low level disk access) heeft aangezet. Normale diskaccess zou volume en disk gelijk moeten zijn.

[Plerry]

Als ik naar het plaatje van Hankman in zijn reactie hier kijk, zie ik dat het disk-gebruik daar ligt op 95%.
Is het probleem niet simpelweg dat Hankmans systeem traag wordt doordat de disk(s) zo goed als vol zijn,
en de disk-koppen telkens naar een andere vrij plekje moeten bewegen?
Dat is mogelijk ook een verklaring voor de opmerkelijke atto-test resultaten.

[Ben(V)]

Volgens mij had hij daar net scrubbing aangezet.

Maar kijken of het volume bijna vol is kan nooit kwaad.