Jump to content
We're Hiring! Full Stack Developer ×

kein HDD Spindown, VM extrem langsam


telly
Go to solution Solved by jj1987,

Recommended Posts

Hallo,

 

meine Festplatten schalten sich nicht in den Standby und ich finde die Ursache nicht.

Auf dem Array liegen eigentlich nur Dateien, Docker und VMs liegen auf der Cache SSD.

 

Wenn ich die primäre Festplatte in den spindown schicke, läuft sie sofort wieder an, das Gleiche bei der Paritydisk.

Ich hatte schon das Plugin Dynamix Active Streams getestet, das zeigt keine geöffneten Dateien an.

 

Ein zweites Problem ist, dass meine Win 11 VM extrem träge reagiert, wenn ich mich per RDP verbinde. Es fühlt sich an, als läuft die VM im Array oder mit hoher CPU Last, was aber beides nicht zutrifft. Vielleicht hängen beide Probleme irgendwo zusammen.

 

Was soll ich posten, damit ihr mir helfen könnt? Welche Screenshots oder Diagnosedaten?

 

Vielen Dank schonmal.

Link to comment
1 hour ago, telly said:

allerdings liegt dort auch das system share

Das wird auf jeden Fall verhindern dass die HDD in spindown geht. Inwiefern das auch Einfluss auf die Performance hat kann ich allerdings nicht beurteilen. Aber "system" sollte eigentlich auf den Cache.

Am besten einmal Docker Service(!) Und VM deaktivieren, system auf Cache prefer umstellen und den mover anschmeißen.

Ggfs hinterher noch einmal prüfen ob auch wirklich alles verschoben wurde und dann die Services wieder anmachen.

Die Docker musst du eventuell dann über Apps-> prevoiusly installed wieder hinzufügen. Aber Daten und Einstellungen bleiben erhalten

Link to comment
2 hours ago, telly said:

Die Treiber von folgender ISO sind installiert:

 

perfekt

 

2 hours ago, telly said:

Die libvirt.IMG ist ja keine ISO und enthält soweit ich weiß keine Treiber für VMs!?

Nein, das passt, mein Fehler ... virtio-win-0.1.2xx-1.iso war gemeint ... ich bin aktuell bei 229 und keinerlei issues.

Link to comment
  • 3 weeks later...

Ich stehe gerade vor dem gleichen Problem. Seit ein paar Tagen gehen meine HDD`s auch nicht mehr in Spin Down.

Hab eigentlich alles was oben steht geprüft bzw. ausprobiert. Aber sobald ich eine Platte in Spindown schicke läuft sie wieder los.

Gibt`s da noch irgendwelche Möglichkeiten das zu debuggen?

Link to comment
1 hour ago, Sancho said:

Gibt`s da noch irgendwelche Möglichkeiten das zu debuggen?

das file activity plugin, aber meist ist es falsch konfigurierte Shares, Dockers, ...

 

zeig mal den output von

 

ls -la /mnt/user0

 

da sieht man schön was für Shares auf dem Array liegen, sollte /system, domains, /appdata, /iso da sein, prüfen ob das wirklich so sein sollte und was darin liegt.

Link to comment

Also ich hatte schon den Docker Service versuchsweise gestoppt, hat nichts geholfen.

Die Shares wie system sind als Prefer cache angelegt.

 

Edit: was ich im Verdacht habe is der Symcon Docker mit dem Symcon Share, aber der Symcon Share ist als Cache eingestellt und wenn ich den Docker stoppe besteht das Problem weiterhin.

 

Bildschirmfoto 2023-11-02 um 22.26.14.png

Edited by Sancho
Info vergessen
Link to comment
7 hours ago, Sancho said:

Die Shares wie system sind als Prefer cache angelegt.

 

auf welcher Unraid Version bist du denn ? heißt ja mittlerweile anders

 

und da ist ja einiges ... vm's, isos, NC Data, Paperless, Timemashine, Homeassistant, ... eigentlich alles kann das Array wach halten ;)

 

als, File Activity Plugin mal schauen, ich schätze aber fast das wird dir einiges anzeigen ...

vorher lesen wie es funktioniert und dann überlegen wie du dich einrichtest zum Thema Shares und wie die laufen sollen.

Link to comment
11 minutes ago, Sancho said:

Laut File Activity ist eigentlich nur der Symcon Share aktiv.

 

und wie du siehst sind da Daten auf Disk1, und bei modify geht auch sicher die Parity mit an ...

 

was ist jetzt die Frage "ob das passt" ... ja, prefer heißt auch dass Daten auch auf dem Array landen können und da laufen, nur wenn die in dem Moment wo der mover läuft nicht in Nutzung sind werden die retour auf den cache geschoben ...

 

12 minutes ago, Sancho said:

Also ich bin auf der Version 6.11.5 unterwegs.

 

dann wäre es langsam Zeit ... es gibt Gründe für Updates ;)

Link to comment

Also Update hab ich jetzt mal gemacht auf 6.12.4...

 

Also mein Verständnis war bisher, dass auf dem Cache gearbeitet wird und dann durch den Mover auf das Array geschoben wird, je nach Einstellung, bei mir einmal täglich.

Hier nochmal ein paar Scrennshots nach dem Update

 

Also eigentlich kann es nur an dem Symcon, den Docker habe ich vor einigen Tagen in Betrieb genommen. Aber alle Mountpoint gehen auf den Symcon Share, der ja Prefer : Cache ist. Und auch wenn ich den Container stoppe kann ich Disk 1 nicht in Spindown schicken, bzw fährt sie gleich wieder hoch.

 

Bildschirmfoto 2023-11-03 um 22.46.19.png

Bildschirmfoto 2023-11-03 um 22.46.07.png

Bildschirmfoto 2023-11-03 um 22.52.26.png

Link to comment
3 hours ago, Sancho said:

Also mein Verständnis war bisher, dass auf dem Cache gearbeitet wird und dann durch den Mover auf das Array geschoben wird, je nach Einstellung, bei mir einmal täglich.

Hier nochmal ein paar Scrennshots nach dem Update

 

Also eigentlich kann es nur an dem Symcon, den Docker habe ich vor einigen Tagen in Betrieb genommen. Aber alle Mountpoint gehen auf den Symcon Share, der ja Prefer : Cache ist. Und auch wenn ich den Container stoppe kann ich Disk 1 nicht in Spindown schicken, bzw fährt sie gleich wieder hoch.

 

Ja, auf dem Cache wird gearbeitet und wenn man die Daten nicht mehr im stänidgen Zugriff braucht, verschiebt man/Mover die ins Array.

Wenn man diese Daten dann im Array hat und diese wieder gebraucht werden, läuft natürlich das Array wieder (an).

Deshalb sollte man genau prüfen, ob man die Ordner der Dockercontainer wirklich ins Array mit Festplatten verschieben möchte, sollte der Docker diese Daten dann sehr kurzfristig wieder anfordern oder gar manipuliert/ergänzen.

 

Wenn Du also beispielsweise einen Text verfasst ist der Editor ein Programm, selbst wenn er ein Extramodul für Thesaurus oder so zusätzlich hat.

Das Programm verwendet man ja öfters, das sollte also vielleicht mit all seinen Zusatzdateien im cache bleiben.

Wenn Du den Text fertig verfasst, korrigiert, gedruckt und weitergeleitet hast, kannst und nicht mehr im Zugriff brauchst, dann kann der ins Array um ihn zu archivieren und vielleicht in 1 Jahr mal wieder zu lesen oder so.

 

Du hast aber anscheinend die "modules" und "db" von Symcon verschieben lassen. Ich kenne die Software nicht (aber wenn mich eine Suchmaschine nicht in die Irre führt ist es ein Programmpaket zu Heimautomatisierung),

aber wenn das Programm diese Modules/db wieder braucht, kann das Array nicht schlafen, weil das Programm da ja wieder drauf zugreift. Und wenn Symcon diese Dateien nicht nur lesend, sondern auch schreibend verwendet, läuft die Parity auch mit an.

Sollte es wirklich etwas zur Heimautomatisierung sein, werden die *.csv Dateien vermutlich zu immer wieder beschriebenen Auswertungen/Statistikreihen und so gehören. Klar, daß die auf dem Array das Array nicht schlafen lassen.

 

Nebenbei hast Du die Größe 0 kb für das Share eingestellt. Vielleicht überdenkst Du die Konfiguration nochmal, bevor Dir der Share voll läuft.

 

 

Zu Deiner Annahme, daß Du mit Prefer alles richtig gemacht hast: dass der Mover da Sachen ins Array verschiebt, deutet darauf hin, daß es da wohl doch nicht passt. Stelle die Shares mal auf Cache only, stoppe Docker und lass den Mover laufen. Damit sollte alles zugehörende im Cahe landen, das Array davon befreit werden. Wenn Du dann den Docker wieder aktivierst sollte es auch ohne Array laufen.

 

Wenn das Array dann immer noch nicht schlafen kann, schau weiter mit Fileactivity oder so nach, was da noch auf dem Array rumwerkelt und passe es an.

Denn soweit ich es sehe hast Du auch system auf prefer...

Eigentlich macht es (in meinen Augen) Sinn die unraid-typischen Standardshares alle auf dem Cache zu lassen. Vielleicht das iso Verzeichnis ins Array, da man davon ja nicht dauernd etwas installiert, aber ansonsten... ab in den Cache und dort belassen.

Und wenn der Cache mit seinen rund 250GB zu klein ist: aktuell sind SSD Preise noch recht niedrig. Vielleicht sollte man mal 'nen Fuffi für eine größere SSD durchdenken? Größere SSD haben oft auch mehr TBW.... was sich gerade bei Anwendungen die ständig modifizieren/schreiben vielleicht auf die Lebenszeit positiv auswirkt?

Edited by DataCollector
Typos
  • Thanks 1
Link to comment
7 hours ago, Sancho said:

Also mein Verständnis war bisher, dass auf dem Cache gearbeitet wird und dann durch den Mover auf das Array geschoben wird, je nach Einstellung, bei mir einmal täglich.

 

kurz, das war falsch bei "Cache prefer", heute "Array > cache"

 

diese Einstellung versucht die Daten auf dem cache zu halten, wenn es aber mangels Platz eng wird wird der mover jetzt anfangen Daten zu verschieben (auch die wo auf cache prefer stehen) damit der cache nicht voll läuft ... jetzt sind die erstmal im array.

 

wenn jetzt wieder Platz ist beim nächsten mover run (1x täglich) wird der mover versuchen diese wieder retour zu schieben ... geht abr NUR wenn die Daten in dem Moment nicht in Nutzung sind ... sprich, wenn der Docker immer läuft (was ja meist der Fall ist) dann bleiben die im Array und du hast deine permanente HDD activity ...

 

Du kannst jetzt folgendes versuchen, Docker Dienst stoppen, mover starten, jetzt sollten alle Daten die von Dockers sind der Share auf prefer steht retour gespielt werden da die ja frei sind ... dann Docker Dienst wieder starten und es sollte alles (erstmal) auf dem cache bleiben (solange Platz da ist).

 

3 hours ago, DataCollector said:

Stelle die Shares mal auf Cache only, stoppe Docker und lass den Mover laufen. Damit sollte alles zugehörende im Cahe landen, das Array davon befreit werden. Wenn Du dann den Docker wieder aktivierst sollte es auch ohne Array laufen.

ACHTUNG, wenn man erst auf cache only stellt dann moved der nichts retour weil das Array dem mover hier dann egal ist ... da ja cache only ;)

ERST moven, dann ggf. auf cache only umstellen ... um sicher zu gehen dass die /appdata auch immer im cache bleiben (heute kein secondary storage aktivieren)

  • Thanks 1
Link to comment

@DataCollector@alturismo, ihr habt jetzt echt mal Licht ins Dunkle gebracht. Ich erkenne meinen Denkfehler, hatte da ein Brett vorm Kopf. Hab das Array vom Prinzip als Backup betrachtet, ist natürlich falsch...

 

Also brauch ich den Share als Cache Only. Um das zu fixen würde ich jetzt folgendermaßen vorgehen wenn ich eure Posts richtig verstanden hab:


1. Docker stoppen

2. Share auf Array -> Cache umstellen
3. Mover laufen lassen

4. Secondary storage auf none

5. Docker wieder starten

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...