Synology-Forum.nl
Firmware => Synology DSM 5.1 en eerder => Topic gestart door: Hankman op 09 maart 2015, 09:44:51
-
Hallo,
Ik heb sinds de overgang van DSM 4.3 last van "verstopping" als ik met mijn i7-desktop parallel (dwz 8 audiobestanden tegelijk met behulp van 8 CPU kernen) audiobestanden wil converteren.
De conversie start op 250+ snelheid (m.a.w.: ongeveer 5 CD's per minuut, bijna 100% CPU usage op de desktop), maar binnen 1 minuut kachelt de snelheid in elkaar om vrijwel tot stilstand te komen.
Tegelijk zie ik de diskactiviteit op de Synology snel oplopen naar 45-66% en de iSCSI activiteit naar 100% (met zo nu een dan een kleine omgekeerde "spike" naar 95%+). De CPU's (van desktop en NAS) tonen slechts enkele procenten belasting.
Na het pauzeren van de conversie houdt de diskactiviteit minutenlang aan, om daarna tot rust te komen. Na hervatting van de conversie op de desktop is het zeer snel weer mis.
Een ander probleem is het toevoegen van Album art aan bestaande audiobestanden op de NAS met MP3Tag. Als de bestandsgrootte hierdoor significant (meer dan 10KB) toeneemt verloopt dit proces uiterst traag (vergt voor één CD enkele tientallen seconden, weer met 100% iSCSI activiteit). Andere wijzigingen aan audiobestanden (die geen toename van bestandsgrootte opleveren) gaan met MP3Tag razendsnel. Dit probleem is irritant, maar staat de bruikbaarheid van de NAS niet in de weg.
Indexering staat uit, snelle SMART testen van de schrijven laten geen bijzonderheden zien. Het kopiëren van grote hoeveelheden data van of naar de NAS levert geen probleem op (ruim 60 Mbps datatransfersnelheid).
In mijn beleving is het probleem bij de overgang van DSM 4.3 naar 5.0. Ik hoopte eigenlijk dat deze "bug" snel door Synology verholpen zou worden, maar tot op heden geen geluk.
Iemand enig idee?
Bij voorbaat dank voor je reactie!
-
Met welke software converteer jij?
Heb je al eens gekeken wat er gebeurd als je de audiobestanden op je lokale haddisk hebt staan en zo'n achtvoudige conversie start, kan je PC harddisk het wel aan.
Wat betreft je tweede probleem. Dat toenemen van die bestanden zal dan wel komen door toevoeging van album art neem ik aan.
Zitten die bestanden in Audiostation?
-
Hoi Ben,
Dank voor je reactie. Ik gebruik dBpoweramp voor de (bulk-)conversie. Op mijn lokale SSD schijf bereik ik conversiesnelheden van 350 en meer. De conversie van een complete CD vergt dan 5 seconden of zo. Conversie van bestanden in bulk van en naar de NAS ging zonder problemen totdat ik de upgrade naar 5.0 heb uitgevoerd (denk ik).
Bij het editen van de taginfo van audiobestanden staan inderdaad alle bestanden op de NAS. Ik heb het idee dat bestanden strak tegen elkaar aan staan op de NAS, en dat ze door de toegenomen omvang allemaal in zijn geheel opnieuw moeten worden weggeschreven.
Ik heb het idee dat beide problemen ontstaan doordat er tegelijkertijd veel wordt gelezen én geschreven van/naar de NAS, kan je daar iets mee?
-
Vergelijken met een ssd heeft uiteraard geen zin.
Het schijnt toch iets met dbpoweramp van doen te hebben, waarschijnlijk de manier waarop het werkt met heel veel lees/schrijf acties.
Daar heeft een netwerkshare veel meer last van dan een lokale drive.
Ze hebben er zelf een oplossing voor gemaakt al is die nog in beta versie.
Daarmee wordt de encoding lokaal gedaan en vervolgens als bestand naar de NAS geschreven.
zie:
https://forum.dbpoweramp.com/showthread.php?14731-Encode-Local-Utility-Codec
Wat betreft je uitbreiding van audio bestanden met mp3tag heeft een het uiteraard niets met strak op elkaar geschreven bestanden te maken, zo werk een disk helemaal niet.
Het zijn gewoon blokken met data op willekeurige plaatsen die aan elkaar gelinkt zijn.
Als je echter die bestanden in audiostation hebt staan (dus ergens onder de share music) dan gebeurd er ineens heel veel als je een album art toevoegt. Hij gaat dan thumbnails in verschillende formaten aanmaken om te gebruiken bij verschillende devices (telfoon, tablet, pc etc). Dat alles kost tijd en je hebt een niet heel krachtige cpu in je NAS zitten (niet vergelijkbaar met een PC).
-
Ik heb het idee dat beide problemen ontstaan doordat er tegelijkertijd veel wordt gelezen én geschreven van/naar de NAS, kan je daar iets mee?
Ik heb geen ervaring met de problematiek hier genoemd, maar voor wat betreft lezen en schrijven van en naar bijv. dezelfde harddisk, wel de ervaring dat zoiets een stuk trager werkt als lezen van de ene harddisk, en schrijven naar een andere.
In hoeverre dat lezen/schrijven zich verhoudt met 4 schijven in een NAS (in RAID ??) ook geen ervaring, maar lijkt me een meer "genivelleerd" resultaat opleveren.
En wat levert het op een workflow, lezen van de NAS, converteren en wegschrijven lokaal (naar SSD), en op het einde van alle conversies, het resultaat weer wegschrijven naar NAS?
-
En wat levert het op een workflow, lezen van de NAS, converteren en wegschrijven lokaal (naar SSD), en op het einde van alle conversies, het resultaat weer wegschrijven naar NAS?
Dank voor je reactie Babylonia,
De workflow (downloaden van NAS, lokaal converteren en uploaden van het resultaat naar NAS) is een optie, maar met een 100 GB SSD en ruim 2 TB aan lossless bestanden (90.000 stuks en groeiend) vergt dat het nodige plakken en knippen. Met Bulk conversie van dBpoweramp kun je ook nog eens incrementeel converteren. Ik converteer mijn lossless verzameling naar 160 kpbs voor op mijn Galaxy met 128 GB Micro SD kaart (capaciteit 32.000 nummers).
In jouw voorstel moet ik telkens mijn hele verzameling opknippen en opnieuw in zijn geheel converteren. Het kan, maar is zeer bewerkelijk.
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.
-
Vergelijken met een ssd heeft uiteraard geen zin.
Het schijnt toch iets met dbpoweramp van doen te hebben, waarschijnlijk de manier waarop het werkt met heel veel lees/schrijf acties.
Daar heeft een netwerkshare veel meer last van dan een lokale drive.
Ze hebben er zelf een oplossing voor gemaakt al is die nog in beta versie.
Daarmee wordt de encoding lokaal gedaan en vervolgens als bestand naar de NAS geschreven.
zie:
https://forum.dbpoweramp.com/showthread.php?14731-Encode-Local-Utility-Codec
Wat betreft je uitbreiding van audio bestanden met mp3tag heeft een het uiteraard niets met strak op elkaar geschreven bestanden te maken, zo werk een disk helemaal niet.
Het zijn gewoon blokken met data op willekeurige plaatsen die aan elkaar gelinkt zijn.
Als je echter die bestanden in audiostation hebt staan (dus ergens onder de share music) dan gebeurd er ineens heel veel als je een album art toevoegt. Hij gaat dan thumbnails in verschillende formaten aanmaken om te gebruiken bij verschillende devices (telfoon, tablet, pc etc). Dat alles kost tijd en je hebt een niet heel krachtige cpu in je NAS zitten (niet vergelijkbaar met een PC).
Hoi Ben, dank voor het meedenken.
Ik heb de bestanden in een aparte share staan. De CPU activiteit op NAS is ook bij het toevoegen van (grotere) plaatjes vrijwel nihil.
Het aangereikte dBpoweramp draadje start in 2007. In 2014 is de status nog steeds Beta en is het onduidelijk of multicore conversie wordt ondersteund.
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).
-
Onlangs elders op het forum vanaf < HIER > (http://www.synology-forum.nl/mac-os-x/ds110j-zeer-traag-met-mac-os-x/msg150173/#msg150173) en verder, had ook iemand problemen van een update naar een latere versie DSM, waarbij werd beoordeeld dat het nieuwere DSM omvangrijker is dan het oude en meer geheugen slikt, wat voor de oudere NAS'sen die in dat draadje werden gebruikt eigenlijk net teveel van het goede was en langzamer ging lopen omdat er veel werd geswapt.
Misschien speelt hier een vergelijkbaar iets ??
Je hebt in je eerste post aangegeven wat het CPU-gebruik is en de activiteit van de disks die enorm oplopen.
Kun je ook eens kijken hoeveel RAM-geheugen er wordt gebruikt en of er nu veel wordt geswapt?
(Boven 80% RAM-gebruik zou meer swapping impliceren).
-
Babylonia,
De door mij beschreven symptomen lijken inderdaad op swappen vanwege geheugengebrek. Heel veel schijfactiviteit en heel weinig meters maken. Is er een manier om dit vast te stellen?
Het geheugengebruik ligt net onder 80% en neemt niet spectaculair toe of af tijdens conversie. Mijn 412+ heeft een 2,13 GHz dual core processor met 1 GB geheugen. 200 MB vrij geheugen zou toch voldoende moeten zijn om file server functies uit te voeren lijkt mij.
In onderstaand plaatje zie je dat ik eerst geheugen vrijmaak door Squeezebox Server (Logitech Media Server) af te sluiten. Het geheugen gebruik daalt van 80-% naar 30+%. Vervolgens start ik de conversie van één CD (9 tracks) en stijgt het geheugen gebruik naar 46%.
De conversie van de ene CD vergt vervolgens minuten lang en ik zie de conversiesnelheid van dBpoweramp terug lopen van 250x naar 4x. Ook na het afronden van de taak blijft de iSCSI activiteit minutenlang op 98% staan om vervolgens naar vrijwel nihil te gaan. Het opstarten van Logitech Media Server laat het geheugengebruik vervolgens weer toenemen naar (slechts) 55%, maar dat zal van korte duur zijn.
Mijn conclusie van dit experiment is dat de symptonen lijken op die van swappen, echter zonder dat een gebrek aan geheugen daarvoor de oorzaak is.
Ik heb ook nog even een conversie gedaan van dezelfde CD met de (single core AMD Sempron 1,61 GHz) voorganger van mijn huidige i7 desktop. Deze komt slechts tot 17x conversiesnelheid en brengt daarmee de NAS niet in problemen. 400 MB lezen en schrijven in 2,5 minuut lukt natuurlijk wel. Een complete conversie van mijn muziekverzameling (die nu 2 x zo groot is) kostte dit beestje overigens 12 dagen van 24 uur, waar mijn i7 (met een goed werkende NAS) dit de laatste keer binnen 12 uur deed.
-
Misschien dat een geheugenuitbreiding van je NAS toch te overwegen is?
Baat het niet, schaadt het niet.
Ik vind een ouder draadje over uitbreiding van geheugen van een NAS type DS412+ < HIER > (http://www.synology-forum.nl/hardware-vragen/ds412-geheugenuitbreiding-howto/)
Er wordt beschreven dat een uitbreiding van 2 GB beter functioneert dan 4 GB i.v.m. adresseringsproblemen bij 4 GB.
Lees ook < de laatste reactie in die draad > (http://www.synology-forum.nl/hardware-vragen/ds412-geheugenuitbreiding-howto/msg75338/#msg75338)
In het kort lijkt dat een vergelijkbare ervaring met wat jij ondervindt, waarbij het uitbreiden van het geheugen uitkomst bracht.
Zie ook aanvullende reactie in < DEZE draad > (http://www.synology-forum.nl/synology-dsm-4-2/iowait-en-cpu-load-erg-hoog/msg74127/#msg74127) als reactie van het terugbrengen van 4 GB naar een 2 GB module.
En nog een filmpje met instructies hoe het geheugen uit te breiden (vervangen door 2GB module) < HIER > (https://www.youtube.com/watch?v=iWc-awYKmf0&feature=youtu.be)
-
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.
Bij de weg: het wegschrijven (kopiëren) van een CD van mijn desktop naar de NAS is (over een gigabit netwerk) secondenwerk, dus daar ligt het probleem ook niet.
-
Het probleem ligt typisch bij gebruik van iSCSI. Zijn daar nog aanvullende instellingen mogelijk in het configuratiescherm?
Verder gaat het mij zelf wat boven de pet. Misschien dat Ben(V) betere aanvullende suggesties heeft. Die is technisch goed onderlegd.
-
Zou toch even de SMART info hier posten voor de zekerheid.
Hoe zien de snelheden van normaal kopiëren eruit van PC ->NAS en intern op de NAS (met filestation)?
-
Dank voor het meedenken MMD
In mijn eerste post geef ik aan dat de snelle SMART testen van mijn drie schrijven drie keer "Normal" als resultaat opleveren. Ook daar ligt het probleem volgens mij dus niet. Die snelle test volstaat neem ik aan, aanzien ik consequent een zwakke performance heb?
Normaal kopiëren PC/NAS, NAS/PC en NAS/NAS levert geen probleem op (60 Mbps throughput tussen PC en NAS)
-
Het probleem ligt typisch bij gebruik van iSCSI. Zijn daar nog aanvullende instellingen mogelijk in het configuratiescherm?
Verder gaat het mij zelf wat boven de pet. Misschien dat Ben(V) betere aanvullende suggesties heeft. Die is technisch goed onderlegd.
Ik heb geen idee Babylonia,
Ik ga hier (http://forum.synology.com/wiki/index.php/How_to_use_the_iSCSI_Target_Service_on_the_Synology_DiskStation) maar eens induiken vanavond..... (zucht)
Dank voor het meedenken in ieder geval!
Edit: even snel gekeken in opslagbeheer, maar op mijn NAS is nog geen iISCSI LUN of Target geïnstalleerd. Geen idee wat dit wil zeggen.....
-
SMART test is geen SMART info..... (integriteitsinfo) ;)
Maar kopiëren levert geen problemen op zie ik nu.
-
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.
-
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.
-
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.
-
Sorry, ik kan deze onbedoelde reactie niet verwijderen...(?)
Ik wilde deze (http://arstechnica.com/gadgets/2012/09/synology-ds-412-is-fast-fun-and-flexible/5/) 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.
-
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.
-
Onnodige citaten zijn verwijderd, lees deze even door. (http://www.synology-forum.nl/vragen-en-opmerkingen-over-het-forum/gebruik-de-citaatknop-met-mate-17838/)
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.
-
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):
-
Wat ik ook niet naar voren zie komen is hoe je naar de NAS verbind.
SMB, NFS.....?
-
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.
-
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.....
-
Daar ben ik het wel mee eens echter zullen eerst andere oorzaken uitgesloten moeten worden.
-
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
[attach=3]
Harddisk
[attach=1]
SSD
[attach=2]
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.
-
Bij deze:
De eerste vanaf de laptop naar de DS414 (SMB)
De tweede de SSD in de laptop
-
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.
-
Omdat mijn resultaten in het verleden beter waren dan hierboven, herinnerde ik mij dat ik een tijdje geleden een update had gedaan voor de netwerk kaart in de laptop.
Na een duik in de geavanceerde instellingen van de kaart heb ik de volgende zaken op disabled gezet:
ARP Offload
Flow Control
Interrupt Moderation
IPv4 Checksum Offload
Large Send Offload (3x)
NS Offload
Recieve Side Scaling
Deze "features" op Disabled geven zoals je ziet een betere performance.
-
Klopt helemaal.
Dat zijn settings om de cpu te ontlasten en een aantal zaken door de netwerk kaart te laten afhandelen.
Echter de morderne cpu's zijn zoveel sneller geworden dat die dat beter doen dan de netwerkkaarten.
Nog een ding dat je in de settings van je netwerkkaart beter uit kunt zetten is flow control.
Ook zo'n overblijfsel uit het verleden, dat tegenwoordig helemaal door tcp/ip is overgenomen en dus dubbel werkt en dus ook kan vertragen.
PS En ook geen jumbo frames gebruiken.
Heb net nog een test gedaan met jumbo frame's van 9000 en van 4000 en beiden zijn trager dan zonder jumbo frames.
-
Leuk tooltje om te testen.
Alleen mijn PC kunnen testen (NAS staat 35km verder).
Tussen langzaamste en snelste opslagmedia zit er bij mij nogal verschil. Zelfs iets van een factor 10x verschil.
1 = langzaamste Een reeds verscheidene jaren oude Samsung HD - 1.5 TB 5400 rpm - alleen gebruik voor back-up
2 = gemiddeld Standaard data-drive - Western Digital black HD - 1 TB (2 jaar oud)
3 = snelste Samsung SSD 840 PRO met OS en programma's 128 GB (2 jaar oud)
-
Flow Control was ik vergeten te vermelden, aangepast.
Wat betreft de MTU (Jumbo Frames) deze heb ik aangepast voor alle apparaten in het LAN naar 1492, behalve de mobieltjes.
-
Leuk tooltje om te testen.
Alleen mijn PC kunnen testen (NAS staat 35km verder).
Tussen langzaamste en snelste opslagmedia zit er bij mij nogal verschil. Zelfs iets van een factor 10x verschil.
1 = langzaamste Een reeds verscheidene jaren oude Samsung HD - 1.5 TB gebruikt voor back-up
2 = gemiddeld Standaard data-drive - Western Digital black HD - 1 TB (2 jaar oud)
3 = snelste Samsung SSD met OS en programma's 128 GB (2 jaar oud)
Ik neem aan dat die eerste een usb disk is want zelfs voor een oude harddisk zou dat wel erg traag zijn.
De harddisk die ik getest heb is een 6 jaar oude hardisk van 650 GB
-
Nee, geen USB-disk. Die HD hangt via een deurtje en geleiding direct aan een SATA aansluiting in mijn PC.
Heb voor de gelegenheid die harddisk even uit het laadje gehaald
en er een pakweg 4 maanden "nieuwe" Western Digital HD black - 1TB ingeschoven. (Ook back-up)
Je kunt aan de resultaten wel zien dat die een stuk nieuwer is, want die komt voor een harddisk aan een stuk betere waarden.
Op die wijze weet ik nu ook, dat die eerdere slechte waarden niet aan de PC ligt, maar aan de drive zelf.
Misschien is er met die Samsung schijf wel iets anders aan de hand?
Dacht dat ik die indertijd met zoiets als Acronis True Image heb ingedeeld. Misschien niet goed gebeurd?
Andere Samsung schijf ongeveer even oud 1TB komt rond de 100 MB/sec.
-
En dan nu op de PC:
De eerste is naar de NAS
De tweede is op de SSD in PC, Samsung 840 Pro
De derde is op de RAID0 in PC, 3x 500GB (2x Samsung, 1x Seagate)
-
Ik denk dat Hankman nu wel even vooruit kan... :lol:
Bij voorbaat excuus voor de vervuiling ;)
-
Dank voor de benchmarks heren, ik ga het vanavond ook eens even checken. Fijn dat er nu objectief vergelijkingsmateriaal is.
-
Zou wel intteressant zijn als iemand die nog DSM 4.3 heeft draaien hier resultaten zou posten.
Nou, heb ik dan even gedaan PC>NAS, maar dan met 4.2 ;) :
DS411+II
4 x HDS724040ALE640
SHR
DSM 4.2-3211
[attachimg=1]
-
Zelfde trend. Die lees snelheden zien er goed uit bij die Hitachi`s
-
Je kunt tijdens het converteren eens kijken wat het swap gebruik is.
Hoi MMD,
Ik heb je aanwijzingen opgevolgd met het volgende resultaat:
total used free shared buffers
Mem: 1.013.488 901.340 112.148 0 33.320
Swap: 2.705.332 212.424 2.492.908
Total: 3.718.820 1.113.764 2.605.056
Kan jij de resultaten duiden? Hoe moet ik de Swap regel interpreteren?
-
Zou wel intteressant zijn als iemand die nog DSM 4.3 heeft draaien hier resultaten zou posten.
Nou, heb ik dan even gedaan PC>NAS, maar dan met 4.2 ;) :
DS411+II
4 x HDS724040ALE640
SHR
DSM 4.2-3211
Ben wel benieuwd hoe dit kan volgens mij is de theoretische maximale snelheid van een Gb netwerk 125 MB/s
-
Je kunt tijdens het converteren eens kijken wat het swap gebruik is.
Hoi MMD,
Ik heb je aanwijzingen opgevolgd met het volgende resultaat:
total used free shared buffers
Mem: 1.013.488 901.340 112.148 0 33.320
Swap: 2.705.332 212.424 2.492.908
Total: 3.718.820 1.113.764 2.605.056
Kan jij de resultaten duiden? Hoe moet ik de Swap regel interpreteren?
Nee die is volgens mij niet aan het swappen.
Je zou nog even het top commando kunnen geven tijdens zo'n conversie.
-
Denk inderdaad ook niet dat er geswapt word, slechts zo`n 210MB met zo`n 110MB geheugen vrij.
Weet echter niet waar het "kantelpunt" ligt, wanneer er geswapt gaat worden.
Maar zoals Ben schreef, doe ook eens top.
-
Heb nog even een test gedaan van m'n PC naar een share op een andere PC die op een SSD staat.
Daarbij zie je duidelijk dat hij vastloopt op de maximale netwerksnelheid van 125 MB/sec.
Iets lager uiteraard vanwege de overhead.
[attach=1]
-
Misschien heeft Birdy er stiekem een Cache SSD inzitten :D
Had het niet eens in de gaten. Misschien wordt er ergens iets gecached.
-
Wat ik ook niet naar voren zie komen is hoe je naar de NAS verbind.
SMB, NFS.....?
Niets bijzonders ingesteld op Windows of DSM, dus Samba?
-
Ben wel benieuwd hoe dit kan volgens mij is de theoretische maximale snelheid van een Gb netwerk 125 MB/s
Klopt, max 125 MB/s echter, dan geeft ATTO dus niet de juiste info ?
Nog een keer dan, met ATTO, Broncontrole en Task Manager:
[attach=2]
En met NAS performance tester (ook niet geheel de juiste info):
[attach=1]
Zoek de verschillen en de waarheid, zeg het maar ;)
-
Schiet mij maar lek. ::) :?:
Ik vertouw niet al die benchmark testers, maar atto was bij mijn volkomen in lijn met NAStester, wat DSM laat zien en de therorie.
-
En hoe is je diskindeling in je NAS?
SHR of meerdere volumes?
RAID5, dus SHR?
-
Misschien heeft Birdy er stiekem een Cache SSD inzitten :D
Had het niet eens in de gaten. Misschien wordt er ergens iets gecached.
Denk dat birdy stiekem een 10 Gb netwerk heeft en er niet over op wil scheppen. ;D
-
En hoe is je diskindeling in je NAS?
SHR of meerdere volumes?
RAID5, dus SHR?
Hoe kan het dan dat in jouw plaatje van de performance monitor de disk utilization op de helft van de volume utilization uitkomt?
Als al je disken in een volume zitten zou dat toch gelijk moeten zijn?
-
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. Downgraden naar DSM 4.3 herstelt meestal de performance, zo is de ervaring, dus het moet toch ergens in DSM zitten.....
Dit is precies het punt wat ik wilde maken. Eerlijk gezegd zat/zit ik in limbo tussen wachten op een fix van Synology of downgraden naar 4.3, met alle risico's vandien.....
-
Heb jij al eens een atto test gedaan?
-
Niets bijzonders ingesteld op Windows of DSM, dus Samba?
Tussen de vervuiling door :)
Op de NAS in de Widget, dat kleine halve klokje rechtsboven, kun je zien wat er verbonden is.
Daar zal 1x http staan. En als je gaat converteren komt daar een verbinding bij.
-
Hoe kan het dan dat in jouw plaatje van de performance monitor de disk utilization op de helft van de volume utilization uitkomt?
Als al je disken in een volume zitten zou dat toch gelijk moeten zijn?
Ik heb geen flauw idee Ben, ik heb in een eerdere reactie al gevraagd wat volume utilization precies inhoud. Ik ben in DSM een opschoonknoop tegengekomen en kon niet nalaten daar op te drukken. Nu ziet de monitor er zo uit:
-
Misschien heeft Birdy er stiekem een Cache SSD inzitten :D
Had het niet eens in de gaten. Misschien wordt er ergens iets gecached.
Denk dat birdy stiekem een 10 Gb netwerk heeft en er niet over op wil scheppen. ;D
Klopt natuurlijk 8) niet :lol:
Heb alleen maar op verzoek getest en de uitkomsten gedeeld, meer niet ;D
-
Op de NAS in de Widget, dat kleine halve klokje rechtsboven, kun je zien wat er verbonden is.
Daar zal 1x http staan. En als je gaat converteren komt daar een verbinding bij.
ik zie 1 x http, 1 x SSH (zal WinSCP/Putty zijn) en CIFS?
-
Hoe kan het dan dat in jouw plaatje van de performance monitor de disk utilization op de helft van de volume utilization uitkomt?
Als al je disken in een volume zitten zou dat toch gelijk moeten zijn?
Hmm... Als ik daar over nadenk...hoeft dat denk ik niet zo te zijn.
In dit voorbeeld 4 disks is de gemiddelde disk utilization per disk lager dan de volume utilization, die over alle disks ligt.
Nu heeft hij op de scrubbing knop gedrukt en dan zie je in zijn plaatje een hoge disk utilization en lage volume utilization.
Of....?
-
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.
-
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?
-
Heb jij al eens een atto test gedaan?
Hoe moet ik dit nu weer interpreteren (lijkt mij niet goed):
-
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?
-
MMV, Babylonia, Peeweesyn, Ben en Birdman: dank voor het meedenken!
-
Nou Hankman en anderen, ik heb ook eens een Atto test gedraaid en schrok van de beroerde resultaten:
(https://www.synology-forum.nl/proxy.php?request=http%3A%2F%2Fi.imgur.com%2FVFTFZA5.png&hash=3eb58cf0d72a2922056753057228afd469bbc9ce)
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:
(https://www.synology-forum.nl/proxy.php?request=http%3A%2F%2Fi.imgur.com%2Fwx3Mvcq.png&hash=1756f706c3ec02cd3078ee13c91bfb55f3821138)
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?
-
@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, 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.....
-
@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.
-
Als ik naar het plaatje van Hankman in zijn reactie hier (http://www.synology-forum.nl/synology-dsm-5-0/iscsi-100-bij-intensief-verkeer-met-pc/msg150647/#msg150647) 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.
-
Volgens mij had hij daar net scrubbing aangezet.
Maar kijken of het volume bijna vol is kan nooit kwaad.