SABNZBD moeite met grote bestanden

[vries085]

Tweede poging tot een reply (na een verhaal ingetik te hebben klapte het forum eruit bij een save :-(  )

Alleen een extra usb-disk voor de cache directory is in ieder geval niet voldoende. Over een DVD van 4,5 Gb deed_ie maar liefst bijna 12 uur!!!

Als je alle diskakties van de DS op een rijtje zet begrijp je wel waarom.

1 - Het opslaan van de berichten uit usenet, voor een bestand van 50Mb zijn dat er al gauw 150 stuks.
2 - Het samenvoegen van al deze berichten tot 1 groot bestand.
3 - Het decoderen (yenc) van dit samengestelde bestand naar een (rar-)file in de 'download/incomplete' directory.

En in de tussentijd draaien er voor SABnzbd een enorme hoop python processen. Op dit moment zo'n 22 stuks. Die hebben allemaal flink wat geheugen nodig.
4 - De kernel is dan flink aan het swappen. Voor de DS106 met 32 megabyte memory wordt buiten die 32 Mb ook nog eens 100 megabyte gebruikt op de swap partitie.
     Het gebruik van de swap is te zien door een 'cat /proc/swaps' te doen.

Let wel, dit gebeurt allemaal op dezelfde fysieke harddisk. Als je de status van de queue (en/of andere SABnzbd zaken) ook nog eens via de webinterface gebruikt gaat het allemaal nog harder (het geheugengebruik en het swappen wel te verstaan)!!

Op dit moment heb ik de volgende configuratie draaien:
- Interne disk (/volume1): hier staat zoals altijd alle programmatuur en de download directory van SABnzbd op.
- Een externe USB disk voor audio opslag, wordt verder in dit verhaal niet gebruikt.
- Een 2e externe HD (60 Gb, ik had niets kleiners). De grootte wordt bepaald hoe groot de bestanden zijn die je download. In principe is zijn een paar Gb wel voldoende.
  Een usb-stick van een paar Gb zou wel eens heel goed kunnen voldoen.
- Aan de voorkant een usb-stick van 512 Mb. Deze gebruik ik nu als swap partitie. Deze is nu niet snel, maar hoe sneller hoe beter, hier gaat heel veel op gebeuren.
  Een probleempje. synlogy heeft de standaard swap partitie (/dev/hda2) hard-coded in de programmatuur staam, en de usb-stick wordt vrolijk als een shared disk
  gebruikt. Dit moet na elke reboot weer opnieuw goed gezet worden.

Na een reboot dus:
   de usb-stick weer 'uitwerpen' via de web-pagina.
   inloggen en de volgende commando's intypen:
       'umount /dev/sda'
       'swapon /dev/sda -p 1'
Wel eerst goed controleren of /dev/sda1 wel de usb-stick voor de swap is natuurlijk.
Als je de grootte van de stick weet en die is uniek dan kan het commando
'cat /proc/partitions' je helpen om te bepalen welk device het swap-device is.

Ik ben nu al weer een tijdje aan het typen, en heb de disk nog geen een keer horen
ratelen en heeft ondertussen 11 rar-files van bijna 50 Mb binnegehaald.

Bovenstaande methode lijkt dus wel zijn vruchten af te werpen. Alhoewel het afwachtebn
is hoe het na verloop van tijd gaat.

Ik hoop dat een ieder hier wat aan heeft. Anders `hoor` ik het wel.

Veel succes
Fred

extra info:
Achteraf bleek een DVD nu nog maar 5 uur te duren, dus 2 keer zo lang als op de PC. VInd ik persoonlijk een goed resultaat als je bedenkt dat het een 266 MHz cpu met 32 Mb is i.p.v. een x GHz cpu met enkele gigabytes aan memory.
Het mooiste resultaat vond ik nog bij het controleren met par en het unrarren. Die gingen in deze configuratie respectievelijk 2 (parren)en 3 (rarren) keer zo snel!

[Luit]

Fred,

Dit is een nuttig verhaal (waarvoor dank!), maar ik heb wel een vraagje.
Ik heb wel eens gelezen dat USB sticks slechts een beperkt aantal keren beschreven konden worden en dat dat bij "normaal" gebruik geen probleem is.
Nu denk ik dat je bij gebruik als swapdisk wel eens tegen deze grenzen aan kan gaan lopen.
Weet iemand hier toevallig meer van?

Luit

[vries085]

Hmm, daar had ik dus nog niet bij stilgestaan  

Op wikipedia kom ik inderdaad de volgende tekst tegen:

Een USB-stick van goede kwaliteit, die niet vaak wordt gebruikt, zal lang meegaan. Als een USB-stick zeer veel wordt gebruikt dan kan er een defect optreden omdat het Flash-geheugen bijvoorbeeld na 10.000 of 100.000 keer schrijven onbetrouwbaar wordt.

Wel een groot verschil trouwens (10K - 100K). Als ik van het maximum aantal keer uitga, en elke seconde wordt er een keer geschreven, dan zou ik na 28 uur al foutmeldingen moeten krijgen.
Dit gaat natuurlijk alleen op als er ook echt veel geschreven gaat worden.

Ik wacht af wat de stick gaat doen.

[Anonymous]

Tweede poging tot een reply (na een verhaal ingetik te hebben klapte het forum eruit bij een save :-(  )

Alleen een extra usb-disk voor de cache directory is in ieder geval niet voldoende. Over een DVD van 4,5 Gb deed_ie maar liefst bijna 12 uur!!!

Als je alle diskakties van de DS op een rijtje zet begrijp je wel waarom.

1 - Het opslaan van de berichten uit usenet, voor een bestand van 50Mb zijn dat er al gauw 150 stuks.
2 - Het samenvoegen van al deze berichten tot 1 groot bestand.
3 - Het decoderen (yenc) van dit samengestelde bestand naar een (rar-)file in de 'download/incomplete' directory.

En in de tussentijd draaien er voor SABnzbd een enorme hoop python processen. Op dit moment zo'n 22 stuks. Die hebben allemaal flink wat geheugen nodig.
4 - De kernel is dan flink aan het swappen. Voor de DS106 met 32 megabyte memory wordt buiten die 32 Mb ook nog eens 100 megabyte gebruikt op de swap partitie.
     Het gebruik van de swap is te zien door een 'cat /proc/swaps' te doen.

Let wel, dit gebeurt allemaal op dezelfde fysieke harddisk. Als je de status van de queue (en/of andere SABnzbd zaken) ook nog eens via de webinterface gebruikt gaat het allemaal nog harder (het geheugengebruik en het swappen wel te verstaan)!!

Op dit moment heb ik de volgende configuratie draaien:
- Interne disk (/volume1): hier staat zoals altijd alle programmatuur en de download directory van SABnzbd op.
- Een externe USB disk voor audio opslag, wordt verder in dit verhaal niet gebruikt.
- Een 2e externe HD (60 Gb, ik had niets kleiners). De grootte wordt bepaald hoe groot de bestanden zijn die je download. In principe is zijn een paar Gb wel voldoende.
  Een usb-stick van een paar Gb zou wel eens heel goed kunnen voldoen.
- Aan de voorkant een usb-stick van 512 Mb. Deze gebruik ik nu als swap partitie. Deze is nu niet snel, maar hoe sneller hoe beter, hier gaat heel veel op gebeuren.
  Een probleempje. synlogy heeft de standaard swap partitie (/dev/hda2) hard-coded in de programmatuur staam, en de usb-stick wordt vrolijk als een shared disk
  gebruikt. Dit moet na elke reboot weer opnieuw goed gezet worden.

Na een reboot dus:
   de usb-stick weer 'uitwerpen' via de web-pagina.
   inloggen en de volgende commando's intypen:
       'umount /dev/sda'
       'swapon /dev/sda -p 1'
Wel eerst goed controleren of /dev/sda1 wel de usb-stick voor de swap is natuurlijk.
Als je de grootte van de stick weet en die is uniek dan kan het commando
'cat /proc/partitions' je helpen om te bepalen welk device het swap-device is.

Ik ben nu al weer een tijdje aan het typen, en heb de disk nog geen een keer horen
ratelen en heeft ondertussen 11 rar-files van bijna 50 Mb binnegehaald.

Bovenstaande methode lijkt dus wel zijn vruchten af te werpen. Alhoewel het afwachtebn
is hoe het na verloop van tijd gaat.

Ik hoop dat een ieder hier wat aan heeft. Anders `hoor` ik het wel.

Veel succes
Fred

extra info:
Achteraf bleek een DVD nu nog maar 5 uur te duren, dus 2 keer zo lang als op de PC. VInd ik persoonlijk een goed resultaat als je bedenkt dat het een 266 MHz cpu met 32 Mb is i.p.v. een x GHz cpu met enkele gigabytes aan memory.
Het mooiste resultaat vond ik nog bij het controleren met par en het unrarren. Die gingen in deze configuratie respectievelijk 2 (parren)en 3 (rarren) keer zo snel!

Hallo Vries085

Ik heb het op jouw manier geprobeerd maar kreeg het niet voor elkaar.
Ik heb in mijn Synology nu 1 interne HD en aan de voorkant een USBstick ingeplugd van 512 mb. Nu voer ik jouw commando's in (in terminal (macosx) via ssh) maar ik krijg het niet werkend.

Misschien kan je mij verder helpen?

Dank je

Daniel

[vries085]

In eerste instantie heb ik nog wat vragen, omdat ik zo niet kan bepalen waar het fout gaat:
 - Heb je een reboot gedaan (niet dat het nodig is, maar wel handig om te weten, want dan is de usb-stick /dev/sda) ?
 - Brand bij jou nog het 'Copy' lampje ?
 - Ben je wel ingelogged als root ?
 - Welke foutmelding krijg je eventueel ?

Na mijn verhaal nog eens rustig doorgelezen te hebben zie ik dat ik ook nog iets vergeten ben -zal wel door het opnieuw intypen komen :-(     mijn excuses hiervoor
Voor de eerste keer gebruiken van de usb-stick als swap moet_ie dus niet gemount zijn: ontkoppelen controleren of ie ook echt ontkoppeld is.

Wat je kunt doen is het ' mount' commando geven nadat je de stick er in gestopt hebt. Dan krijg je een overzicht van de partities/disks die momenteel gekoppeld zijn. Bewaar de uitvoer even.
Ontkoppel je stick vervolgens via de web-interface
Geef nu nog een keer het mount commando. Zie je geen verschil met de uitvoer van het eerste het eerste commando, dan is_ie onderhands nog gekoppeld. In dat geval een umount commando geven.
Nu het missende stuk: Je moet de naam van het device onthouden wat je hebt ontkoppeld, dat moet tenslotte de usb-stick zijn (daar helpen beide mount commando's bij). Ik kon er zelf achter komen welk device het was door de inhoud die nog op de stick stond.
nu nog een 'mkswap /dev/sda1'  commando geven (dit hoeft maar eenmalig te gebeuren en je `zegt` tegen linux dat_ie dit device as swap mag gaan gebruiken)
vervolgens kun je het swapon commando geven.
Als alles goed is  zie mbv. het commando `cat /proc/swaps` nu regels. Dit zijn de 2 mogelijk swap devices. De partitie van je interne disk en de usb stick.
Door een swapof /dev/xxx  wordt inhoud van de swap overgeheveld naar de usb-stick en dat device van de lijst verwijderd. Dit is te controleren door nogmaals een cat /proc/swaps te geven

Ik hoop dat dit je wat verder helpt.  Denk er wel om, je moet wel inloggen als root

[kennethalderden]

Hoi, ik hetzelfde probleem, zeker nu ik HD materiaal download, maar zag het volgende in Putty - commando 'Top':
Het proces Python pakt weinig CPU (2%), geheugen 63% maar de status van het proces staat op S (Sleeping)
Is dat niet vreemd?

Groet Kenneth

[Anonymous]

Oplossing heeft bij mij niet gewerkt. De download start goed maar na verloop van tijd begint de Synology langzamer te worden en lijkt het of het downloaden stil aan vallen is.
Toch maar een DS109+...

Daniel

[vries085]

Klopt,
daar heb ik nu toch weer last van. Zelfs als ik de download pauzeer, blijven de web-pagina's zeer langzaam, terwijl SABnzb eigenlijk vrijwel niets meer hoeft te doen. De hoeveelheid swap (zonder download) is nu al opgelopen van 45 Mb tot bijna 100 Mb zonder dat het duidelijk is waar de DS mee bezig is.

Jammer, ik dacht zelf de oplossing gevonden te hebben (werkt nog wel goed tot bestanden van ca. 20 Mb), mar de 50 Mb bestanden blijven echt problemen geven.
Ik zag net zelf dat_ie 3 van die bestanden tegelijkertijd aan het downloaden is (= het aantal connections). Ik ga zo eens proberen wat de invloed is om maar 1 connectie te gebruiken (ben niet optimistisch hierover).  <Edit> Werkt dus inderdaad niet </Edit>
Er zit natuurlijk ook nog een bak administratie aan het hele process van downloaden gekoppeld. Mischien dat dat ook nog invloed heeft.
Anders moet ik toegeven dat ik er verder ook niet uitkom, dus inderdaad een andere NAS, maar of dat dan nog een Synology wordt weet ik niet. De beperkte commando's van de gebruikte 'busybox' zit mij wel dwars. Ook de opties beschikbare Linux commando's wijken af van de standaard en manual pagina's of opties als -h ok --help zijn niet aanwezig (mischien een ebook voor de downloads). Maar dat is een ander topic denk ik.

Als iemand anders nog goede ideen heeft om de boel wat efficienter aan de praat te krijgen, dan hoor ik het graag.

[Anonymous]

Hallo Vries085,

Inmiddels overgegaan naar een synology DS209+II en vanmorgen een dowload gestart van 50 gb. Zonder problemen binnengehaald. Downloaden heeft 3,5 uur geduurd en repareren en uitpakken nog eens 70 mins extra.
Ben wel blij nu:) Mijn DS109 gaat denk ik in de verkoop.

Bedankt voor je meedenken!

Daniel