iSCSI 100% bij intensief verkeer met PC

[Hankman]

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!

[Ben(V)]

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?

[Hankman]

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?

[Ben(V)]

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).

[Babylonia]

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?

[Hankman]

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.

[Hankman]

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).

[Babylonia]

Onlangs elders op het forum vanaf < HIER > 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).

[Hankman]

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.

[Babylonia]

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 >
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 >
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 > 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 >

[Hankman]

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.

[Babylonia]

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.

[Pippin]

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)?

[Hankman]

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)

[Hankman]

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 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.....