+-Serie SCEMD verursacht regelmäßig hohe Speicherauslastung

[Denny546]

Hallo Forum,

ich habe seit einiger Zeit das Problem, dass die DS 212+ zwar grundsätzlich insgesamt funktioniert, aber die Performance in den Keller geht.

Ich habe schon mehrfach festgestellt, dass der SCEMD Dienst massig Speicher frist (obwohl im Schlafzustand).
Habe aber keinen Dunst woher diese Auslastung kommt.

Die Folge:
- Lange Zugriffszeiten über SMB
- Browserlogin und Oberflächenanzeige dauern sehr lange und bekommen teils ein Timeout.

Anbei mal ein Screenshot.

DSM 4.1 - 2636

Wäre schön wenn jemand da ne Idee zu hat.

Gruß
Denny

 

[Frogman]

Für die Version 4.1-2636 gab's mal ein Update (fix2BaySleep-4.1.2636.pat), welches eben jene scemd-Binary aktualisiert hat. Keine Ahnung, ob hier prinzipiell mit der Version noch Probleme existieren.
An sich empfiehlt sich, ab und an auf neuere DSM-Versionen zu aktualisieren. Die 2647 lief beispielsweise sehr stabil bei mir, und aktuell auch die 2661 macht keinerlei Probleme (mit Ausnahme der Geräteübersicht im Medienserver, aber das hängt wohl am Paket und nicht am DSM). Das Verhalten, welches Du dort siehst, ist mir damit jedenfalls bisher nicht begegnet.

 

[Denny546]

Für die Version 4.1-2636 gab's mal ein Update (fix2BaySleep-4.1.2636.pat), welches eben jene scemd-Binary aktualisiert hat. Keine Ahnung, ob hier prinzipiell mit der Version noch Probleme existieren.
An sich empfiehlt sich, ab und an auf neuere DSM-Versionen zu aktualisieren. Die 2647 lief beispielsweise sehr stabil bei mir, und aktuell auch die 2661 macht keinerlei Probleme (mit Ausnahme der Geräteübersicht im Medienserver, aber das hängt wohl am Paket und nicht am DSM). Das Verhalten, welches Du dort siehst, ist mir damit jedenfalls bisher nicht begegnet.

Hi Frogman,

Danke für Dein reply. Ich habe genau jenen Fix2BaySleep drauf. Vielleicht verursacht dieser das Problem.
Ich werde mal auf die 2647 updaten und noch ein wenig warten was die Ergebnisse der 2661 liefern. Es sollte schon nix schiefgehen, da die NAS Produktiv als Netzshare im Einsatz ist. Daher warte ich immer mit den Updates

Viele Grüße
Denny

 

[ascella]

Hallo Denny,
ich habe dieses Verhalten mit den letzten beiden Versionen auch. Momentan mit der 2661 hab ich auch ständig sehr hohe Speichergrößen für den scemd. Ich habe eine DS212 mit 256 MB und der scemd-Prozess geht innerhalb weniger Stunden auf 180 oder 190 MB. Außerdem hatte ich schon Tage, in denen die DS ordentlich schlafen geht, jetzt grad läuft sie seit 2 Tagen ohne einmal einzuschlafen. Schade eigentlich. Nach dem Kauf und der Version 4.0 lief sie richtig gut.

Gruß
ascella

 

[Holgi08]

Hallo ! Bei mir auch das gleiche Problem - seit dem Update auf die aktuelle Firmware der DS212+ ..... im Moment jenseits von 300MB RAM Nutzung. Davor war eigentlich alles OK.

 

[ascella]

Hallo ! Bei mir auch das gleiche Problem - seit dem Update auf die aktuelle Firmware der DS212+ ..... im Moment jenseits von 300MB RAM Nutzung. Davor war eigentlich alles OK.

Hallo Holgi,
schläft deine 212+ denn auch nicht ordentlich durch?

Gruß

 

[Holgi08]

Hi ! Ne, scheint Sie nicht. So alle ca. alle 2 Stunden wacht die Station wohl auf, und im Log finde ich diese wiederkehrenden Einträge :

Dec 1 07:45:23 kernel: [64947.000000] ata1: wake up from deepsleep, reset link now
Dec 1 07:45:23 kernel: [64947.080000] ata1: device plugged sstatus 0x123
Dec 1 07:45:23 kernel: [64950.010000] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
Dec 1 07:45:23 kernel: [64950.020000] ata1: edma_err_cause=00000010 pp_flags=00000000, dev connect
Dec 1 07:45:23 kernel: [64950.020000] ata1: SError: { PHYRdyChg DevExch }
Dec 1 07:45:30 kernel: [64954.030000] ata2: wake up from deepsleep, reset link now
Dec 1 07:45:30 kernel: [64954.110000] ata2: device plugged sstatus 0x123
Dec 1 07:45:30 kernel: [64957.040000] ata2: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
Dec 1 07:45:30 kernel: [64957.050000] ata2: edma_err_cause=00000010 pp_flags=00000000, dev connect
Dec 1 07:45:30 kernel: [64957.050000] ata2: SError: { PHYRdyChg DevExch }
Dec 1 07:45:33 kernel: [64960.060000] ata1: SRST failed (errno=-16)
Dec 1 07:45:33 kernel: [64960.060000] ata1: SRST fail, set srst fail flag
Dec 1 07:45:34 kernel: [64961.040000] ata1: link reset sucessfully clear error flags
Dec 1 07:45:34 kernel: [64961.150000] ata1.00: Disable disk write cache in EH
Dec 1 07:45:40 kernel: [64963.060000] ata2: link is slow to respond, please be patient (ready=0)
Dec 1 07:45:40 kernel: [64967.000000] ata2.00: Disable disk write cache in EH

 

[MartinFrab]

Hallo!
Bei mir auch gleiches Problem.
Und wenn die Ram-Auslastung gegen 90% geht beginnt sich auch der Swap-Speicher zu füllen.



Gruß Martin

 

[ascella]

Also bei der 4.0 war alles ok. Dann ab der ersten 4.1 gab es diese Probleme mit dem regelmäßigen unerwünschten Aufwachen und dem Speicherhunger des scemd. Das muss doch rauszufinden sein, wieso sich die DS plötzlich so verhält. Alle Pakete gestoppt, seinerzeit den Patch eingespielt usw. usw. Hat alles nix genutzt. Ist die Version (also 4.0 oder 4.1) nur auf der HD oder gibt es auch Firmware auf der DS. Bin schon am überlegen eine neue HD mit 4.0 zu installieren damit wieder alles so funzt wie zuvor.


Gruß

 

[MartinFrab]

Nach der deinstallation von ein paar nicht benötigten Paketen (Cloud Station,Mail Server,Time Backup) und einem neustart des Systems ist das Problem mit der Ram-Auslastung jetzt wieder weg!
Keine Ahnung was genau jetzt schuld war.
Gruß Martin

 

[ascella]

Ich hab ebenfalls alle Pakete bis auf Medienserver deinstalliert und ftp abgeschaltet. Jetzt schläft sie wieder ordentlich ein, wacht nicht ungewollt auf und der scemd Prozess bleibt auch nach 2 Tagen bei 2,7 MB. Keine Ahnung was da los war.

Gruß
ascella

 

[MartinFrab]

Nehme mal an das eines der Pakete eine Macke hat.

 

[Peter-GSA]

Hallo Leute,

Zufälligerweise bin ich auf dieses Forum gekommen. Ich suche immer auf Englisch (Ich komme aus den Niederlanden) und dieses Thema stand auf der Ersten Seite van Google. Also...

Ich habe das gleiche Problem mit den Scemd wie Ihr. Bei mir war er auch mal gewachsen bis 186MB.

Ich habe zwei DS212+. Auf die DS2, die Not/Backup-DS, lauft alles wie es soll. Der Scemd is ungefähr 2,5MB: immer. Auf die DS1, die arbeits-DS, benutzt der Scemd sehr viel speicher. Das Problem hat angefangen, wie bei euch mit DSM 4.1!

Meine Idee war das auf der DS1 etwas falsch gegangen wäre mit die Upgrade nach DSM 4.1. Deshalb habe ich die DS1 aufs neue aufgebaut; ich habe ja von alles auf des DS1 eine Kopie auf der DS2.
Nach dem Aufbau der DS1 habe ich nur die "Shared Folder Sync" zu der DS2 und der VPN Server wieder hergestellt. Alle andere "Packages" wie "Joomla", "Timebackup" hab ich bewusst nicht installiert. Die DS1 lief einwandfrei.
Letzte Woche habe ich "Timebackup" installiert und konfiguriert zum täglichen (lokalen) Backup. Heute habe ich festgestellt das der Scemd wieder verrücktspielt.
Ich vermute das im "Timebackup Package" etwas nicht stimmt.

Deshalb werde Ich "Timebackup" de-installieren, und regelmäßig kontrollieren ob der Scemd sich wieder normal verhält. Ich hoffe nur das die de-installation auch volständig ist. Oft bleiben ja Resten einer Installation irgendwo zurück. Ich melde mich dan Später wieder mit den Ergebnissen.

Ich bin gespannt ob ihr auch allemal "Timebackup" benutzt habt, in Zusammenhang mit dem Scemd Problem.
Weis einer von euch wie man herausfinden kann was das "Timebackup Package", oder ein anderes "Package", genau ändert an der DS während einer Installation?

Freundlichen Gruß,
Peter

 

[Holgi08]

Hi Peter-GSA !
Ich habe mittlerweile auch im Ausschlussverfahren TimeBackup als Verursacher des Problems ermittelt. Ich habe nach und nach sämtliche Packages mal probeweise deinstalliert, und erst als TimeBackup weg war lief die DS212+ wieder normal. Scemd hatte unter 5 MB Speicher. Dann habe ich nach und nach alle Packages wieder installiert, zuletzt Timebackup, und ein Backup gestartet - und siehe da - gleiches Verhalten wie zuvor : Scemd schnappt sich im Laufe eines Tages fast den ganzen RAM.

Interessanterweise verhielt der scemd bei der ersten Deinstallation von Timebackup erst nach zwei drei Neustarts der DS212+ wieder normal.

 

[Peter-GSA]

Hallo Holgi08,
Nach dem de-instalieren des Timebackup's ist der speicherverbrauch des SCEMD auf meine DS212+auch weider in ordnung.
Bleibt nur die frage, wan das von Synology repariert wird.
Gruss an allen,
Peter

 

[Puppetmaster]

Mich würde jetzt einmal interessieren, was für ein Dateivolumen (Anzahl und Gesamtgröße) ihr da mit TimeBackup sichert. Bei mir hat TimeBackup noch nie Speicherprobleme verursacht, aber das zu sichernde Volumen ist auch eher gering.
Kann mir sehr gut vorstellen, dass gerade TimeBackup bei einer großen Anzahl Files massig Speicher benötigt.

 

[Peter-GSA]

Hallo Puppetmaster,
Ich mache einen backup met Timebackup von fast 300GB an Data auf eine 212+. Das ist nach meiner meinung nicht viel.
Bei mir, und anderen, war es ja so das unter DSM4.0 alles in ordnung war. Erst nach der installation (upgrade und neu installierung) van DSM4.1 war das problem mit dem Scemd da. Dabei siehe ich dem verband nicht zwischen dem Scemd und timebackup. Timebackup startet ein eigenes proces: timebkpd. Wenn arbeitsspeicher fur timebackup nötig wäre würde ich erwarten das der speichergebrauch von timebkpd wachsen würde, und nur dan wenn ein backup läuft.

 

[MartinFrab]

Ich hatte Timebackup nie in verwendung,es war nicht mal eingeschalten.Alleine die Installation des Paketes verursachte bei mir schon den Speicherhunger.
Ich hatte mich deswegen auch schon mit Synology in Verbindung gesetzt. Sie hätten zugang zu meiner DS gebraucht,ging aber wegen meines Buisness Routers nicht.

 

[Peter-GSA]

Hallo MartinFrab,

Genau das habe ich auch gesehen, es war bei mir auch nicht relevant ob Timebackup lief. In meiner suche habe ich erst Timebackup abgeschaltet. Das hatte keinen Einfluss auf den Speicherhunger des Scemd. Nur die de-installation van Timebackup löste das Problem.

Peter

 

[oodoloo]

Hallo zusammen!

Ich hatte genau dasselbe Problem bei meiner DS212+ mit DSM 4.1-2668. Der Prozess "scemd" hat sich einfach innerhalb eines Tages 90% vom Ram geschnappt und nach einem Neustart des Servers ging es wieder von vorne los.
Bei mir lag es natürlich auch am Timebackup und jetzt im Nachhinein weiss ich das auch, doch vorher dachte ich auch, dass es nicht daran liegen kann, da ich Timebackup installiert, kurzzeitig aktiviert und dann wieder deaktiviert hatte. Doch wie in diesem Beitrag schon erläutert wurde, reicht rein die Installation von Timebackup aus um diesen Effekt hervorzurufen. Ich habe es gestern direkt nachdem ich diesen Beitrag gefunden hatte wieder deinstalliert und bis heute beobachtet - und siehe da: der Speicher des Prozesses "scemd" war heute immer noch bei 2,6 MB. Ich finde das einfach nur Wahnsinn, dass die reine Installation zu so einer gravierenden Sache führt und hoffe, dass dieser Bug in der nächsten DSM-Version behoben ist, da ich Timebackup an sich eigentlich für eine Top-Anwendung halte und sie gerne benutzen würde, doch so würde man sich damit eher selbst ein Bein stellen.

Danke für diesen Beitrag, hat mir wirklich sehr viel weitergeholfen - bin schon fast verzweifelt, als mein Ram immer wieder vollgelaufen ist.

Gruß,
oodoloo