iSCSI 100% bij intensief verkeer met PC

[Pippin]

SMART test is geen SMART info..... (integriteitsinfo)
Maar kopiëren levert geen problemen op zie ik nu.

[Hankman]

Ik zie het MMD, SDM Opslagbeheer Integriteitsinfo vertelt mij dat mijn drie schrijven "Gezond" zijn. Het hier tonen van gedetailleerde SMART info heeft dan weinig zin neem ik aan.

[Pippin]

Het zal zeker niet de eerste keer zijn dat een SMART test OK zegt en een schijf alsnog het loodje legt.
Een blik op de RAW waardes kan soms beter inzicht geven.
Maar het kopiëren gaat goed dus hoogstwaarschijnlijk zal het lees/schrijf gedrag dan in orde zijn.

[Hankman]

Ja, het probleem doet zich ook al een jaar of zo voor, zo lang duurt het toch niet voordat een schijf definitief het loodje legt?

De Raw Read Error Rate is overigens bij alle schijven gelijk aan 0.

[Hankman]

Sorry, ik kan deze onbedoelde reactie niet verwijderen...(?)

Ik wilde deze post over iSCSI configuratie nog aan een oude reactie toevoegen.

Ik zeg het nog maar een keer, de NAS heeft goed gewerkt. Om nu allerlei nieuwe dingen (vergroten geheugen, inrichten iSCSI) te proberen om de NAS weer als vanouds te laten functioneren voelt niet echt goed.

[Ben(V)]

Als je dat niet zelf opgezet hebt gebruik je echt geen isci.
Het plaatje waar jij naar kijkt zegt volume/isci.

Wat betekent volume en/of isci en normaal gesproken is dat dus volume.

Verder denk ik dat het swapping verhaal het meest waarschijnlijke is, het kan best zo zijn dat met een oude versie van DSM er net iets minder geheugen gebruikt werd en alles net goed ging.
Misschien moet je eens proberen die batch kleiner te maken net zolang tot het wel werkt.
Dus eerst een van 8 naar 7 bestanden en dan naar 6 tot het wel blijft werken.

[Hankman]

Onnodige citaten zijn verwijderd, lees deze even door.
Birdy.

Ben, welkom terug en dank voor je reactie,

Wat is overigens het onderscheid tussen de getoonde volume en diskactiviteit? Ze gaan min of meer wel gelijk op maar zijn niet identiek.

ik heb vastgesteld zie dat het probleem zich ook bij 46% geheugengebruik voordoet. Zie het plaatje in één van mijn vorige reacties. 540 MB vrij RAM geheugen is voldoende voor schijfopslag lijkt mij.

Met de gelijktijdige conversie van 4 bestanden loopt het proces ook al bijna vast, met 2 bestanden gebeurt het niet maar loopt de snelheid terug tot 60x. De "Volume" activiteit piekt in beide gevallen weer naar 100%.

Nu lijkt het alsof het probleem wordt veroorzaakt door dBpoweramp conversie in multicore modus, maar dat verklaart niet waarom ook het toevoegen van album art met MP3Tag performance problemen geeft. Dat is volgens mij geen multicore operatie.

[Pippin]

Je kunt tijdens het converteren eens kijken wat het swap gebruik is.
Geef daarvoor in PuTTy het commando "free" in zonder aanhalingstekens.

http://www.synology-forum.nl/algemeen/nas-benaderen-met-ssh-winscp-putty/msg134190/#msg134190
Onder het kopje: Wil je alleen PuTTY (Linux kennis vereist):

[Pippin]

Wat ik ook niet naar voren zie komen is hoe je naar de NAS verbind.
SMB, NFS.....?

[Ben(V)]

En hoe is je diskindeling in je NAS?
SHR of meerdere volumes?

Als je meerdere volumes hebt zou je de source en de target van je converter process op twee verschillende disken kunnen zetten.

Ook kun je overwegen eerst de source naar je PC te kopieren en de target naar je NAS disk.

Er vanuitgaande dat dbpoweramp dat onderscheid kan maken.

[peeweesyn]

Ik heb eens een aantal uitspraken van Hankman op een rij gezet, ze illustreren heel goed mijn ervaring met de performance van mijn DS412+ in relatie tot DSM upgrades. Ik kocht mijn DS412+ met DSM 4.1 of 4.2. Nu zit ik op DSm 5.1 er meen ik zo'n 25% performanceverlies te bespeuren, óók als ik alle (3rd party) packages uitschakel.

Daarnaast heeft het feilloos gewerkt (snelheid ongeveer 250x),  voor mijn gevoel totdat ik een upgrade draaide van DSM. Datzelfde geldt voor het opslaan van plaatjes in bestanden, ook dit heeft zonder problemen gewerkt.

Mijn punt is dat de NAS tot een klein jaar geleden zonder problemen heeft gewerkt met multicore dBpoweramp bulk file conversie (250+ conversiesnelheid) en MP3tag, maar dat beide applicaties nu performance problemen geven op de NAS (dBpoweramp is zelfs onbruikbaar voor bulk conversie).
Wat mij bezig houdt is dat de 412+ prima heeft gewerkt (250+ conversiesnelheid) bij converteren, totdat........

Verder zie ik bij de draadjes over uitbreiding van het geheugen veel twijfel over het nut ervan en nauwelijks uitspraken over een significante verbetering van de performance. Je gaat ook voorbij aan het bovenstaande plaatje dat laat zien dat het probleem zich ook voordoet bij 46% geheugenbeslag. Het converteren van 400 MB aan data is toch geen megaklus die de NAS minutenlang in beslag moet nemen.
Normaal kopiëren PC/NAS, NAS/PC en NAS/NAS levert geen probleem op (60 Mbps throughput tussen PC en NAS)

Ja, het probleem doet zich ook al een jaar of zo voor, zo lang duurt het toch niet voordat een schijf definitief het loodje legt?

De Raw Read Error Rate is overigens bij alle schijven gelijk aan 0.
Ik zeg het nog maar een keer, de NAS heeft goed gewerkt. Om nu allerlei nieuwe dingen (vergroten geheugen, inrichten iSCSI) te proberen om de NAS weer als vanouds te laten functioneren voelt niet echt goed.

ik heb vastgesteld zie dat het probleem zich ook bij 46% geheugengebruik voordoet. Zie het plaatje in één van mijn vorige reacties. 540 MB vrij RAM geheugen is voldoende voor schijfopslag lijkt mij.

Alle goed bedoelde suggesties m.b.t. Smart tests, SMB vs NFS etc ten spijt, kan ik mij niet aan de indruk onttrekken dat de oorzaak ligt in het bestandsysteem en/of de 'drivers' die Synology daarvoor gebruikt. Het ligt niet op low level diskniveau want smart tests e.d. slagen met vlag en wimpel. Het lijkt ook niet op applicatieniveau te liggen, want het probleem lijkt niet specifiek verbonden aan een applicatie. Maar zodra er veelvuldig korte acties op kleine bestanden nodig zijn lijkt de performance in te zakken. Kijk ook maar naar het grote verschil in snelheid tussen het kopiëren van 1 groot bestand vs. 1000 kleine bestanden. Ik heb in de diverse fora over Synology nog geen echt diepgaand onderzoek naar dit fenomeen gezien (bijv. door linux experts), terwijl ik verwacht dat daar ergens de oorzaak ligt en razend nieuwsgierig ben naar een dergelijk onderzoek. Downgraden naar DSM 4.3 herstelt meestal de performance, zo is de ervaring, dus het moet toch ergen sin DSM zitten.....

[Pippin]

Daar ben ik het wel mee eens echter zullen eerst andere oorzaken uitgesloten moeten worden.

[Ben(V)]

Ok even wat testen gedaan met atto diskbencchmark.
Hier te downloaden:
http://www.techpowerup.com/downloads/1749/atto-disk-benchmark-v2-46/
Je moet wel even een diskletter koppelen voor je Atto opstart want hij kan niet met UNC overweg.

Atto test met oplopende transfersize's zodat je goed kunt zien dat bij grotere transfersize de performance flink oploopt.
Ik heb dit getest op m'n NAS (DS414), m'n hardisk in m'n PC en m'n SSD in m'n PC.
Hieronder de resultaten.
NAS


Harddisk


SSD


Je ziet dat alle systemen last hebben van kleine "bestandjes", dat is begrijpelijk want bij grote bestanden gaat het gebruik van caching natuurlijk voordeel opleveren.
Het is wel interresant om te zien of andere NAS modellen ongeveer hetzelfde beeld laten zien.
Misschien kan TS dit ook eens proberen en de uitkomst hier plaatsen.
Testen van andere NAS modellen zou ook leuk zijn.

[Pippin]

Bij deze:

De eerste vanaf de laptop naar de DS414 (SMB)
De tweede de SSD in de laptop

[Ben(V)]

De resultaten zijn overeenkomstig.
Ook de harddisk en de ssd worden trager bij kleine bestandjes maar houden het wel beter vol.
Zou wel intteressant zijn als iemand die nog DSM 4.3 heeft draaien hier resultaten zou posten.