Varför orsakar Immich upprepad diskaktivitet under natten?

Immich kan generera återkommande diskaktivitet över natten eftersom schemalagt underhåll, databasarbeten, köade mediejobb eller omförsök fortsätter efter att användare slutat använda biblioteket.

Ett tyst hushåll betyder inte att servern är inaktiv. Den viktiga frågan är om samma process och samma jobb förklarar läsningarna eller skrivningarna vid samma klockslag. Korrelera aktiviteten först och avgör sedan om det handlar om förväntat arbete, inhämtning av en eftersläpning eller en loop som bör stoppas.

Matcha diskökningen mot klockan innan du ändrar något

Börja med tidsstämplar från tre nätter i stället för en enda brusig observation. Notera när block-I/O ökar, vilken enhet som är upptagen, om läsningar eller skrivningar dominerar och om mönstret börjar nästan samma tid. En återkommande starttid pekar mot en schemaläggare; ett oregelbundet mönster pekar starkare mot inkommande data, omförsök eller en annan container.

Immich-distributioner kan schemalägga databassäkerhetskopieringar och integritetsinriktat arbete under timmar med låg användning, så en ökning tidigt på morgonen kan vara avsiktlig. Inaktivera inte ett jobb enbart för att det väcker diskarna. Kontrollera först om en motsvarande säkerhetskopiering, underhållsrapport eller köslutförande visas efter aktivitetsperioden.

Den närliggande ZimaSpace-diagnosen av Immichs bakgrundsarbete under inaktiva timmar använder samma tidsstämpelregel: koppla det synliga symtomet till processen och jobbet innan du betraktar ”inaktiv” som ett feltillstånd.

Separera PostgreSQL-skrivningar från medieläsningar

Ändringar i Immichs applikationstillstånd kan hålla PostgreSQL aktivt även när ingen ny bild öppnas. Databaskontrollpunkter, WAL-loggning, vakuumrelaterat arbete och vanliga programuppdateringar har en annan I/O-signatur än skanning av tusentals mediefiler. Identifiera sökvägen eller enheten som tar emot trafiken innan du skyller på bildbiblioteket.

Observabilitetsdiskussionen om PostgreSQL i analysen av pg_stat_io förklarar varför läsningar, skrivningar, backendaktivitet, kontrollpunktbeteende och bakgrundsskrivningar behöver separeras. Använd den åtskillnaden för att avgöra om databasenheten är upptagen eftersom användbara transaktioner sparas eller för att något upprepade gånger skapar onödig aktivitet.

Om databasskrivningarna är små och periodiska medan mediediskarna förblir vilande kan beteendet vara normalt databasunderhåll. Om samma databasfil utsätts för ihållande tunga skrivningar utan att något jobb går framåt bör du spara loggar och granska ansvariga frågor eller en omstartsloop i stället för att flytta hela biblioteket till snabbare lagring.

Kontrollera om bakgrundsköerna faktiskt går framåt

Öppna jobbvyn och jämför väntande, aktiva, misslyckade och slutförda jobb före och efter nattperioden. Generering av miniatyrbilder, videobearbetning, metadataextrahering, maskininlärningsuppgifter eller arbete med importerade bibliotek kan legitimt hålla lagringen aktiv efter en stor förändring. En minskande eftersläpning är ett tecken på nyttigt ikapparbete.

En aktuell rapport från communityn om ihållande oförklarade läsningar visar den motsatta diagnostiska gränsen: mycket höga kontinuerliga läsningar utan förväntat arbete bör undersökas i stället för att avfärdas som ”så Immich fungerar”. Betrakta den rapporterade hastigheten som ett enskilt fall, inte som ett riktvärde.

Om samma få jobb misslyckas och åter läggs i kön kan diskaktiviteten upprepas utan att något går framåt. Fånga det första felet och en berörd tillgång och isolera sedan den jobbtypen. Rensa inte alla köer och återskapa inte hela biblioteket innan du har fastställt om loopen orsakas av en fil, behörigheter, lagringslatens eller ett tjänsteberoende.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Tillskriv I/O till en process i stället för att gissa utifrån diskbrus

Använd I/O-övervakning på värden under nästa återkomst för att identifiera processen som läser från eller skriver till enheten. Koppla sedan processen till Immich-servern, PostgreSQL, maskininlärning, ett säkerhetskopieringsverktyg, antivirus, filsystemskontroll eller en orelaterad container. Disklampor och fläktljud kan inte ge den informationen om ägarskap.

Ett praktiskt iotop-arbetsflöde visar metoden att börja med processen. Samla flera mätvärden eftersom en kort topp kan försvinna mellan observationerna; målet är att fånga processen under samma tidsfönster som symtomet.

Om Immich inte är den största I/O-användaren ska du sluta ändra Immich-inställningar och följa den faktiska processen. Om PostgreSQL, Immich eller en relaterad arbetare är ansvarig ska du korrelera dess loggar och jobbframsteg med I/O-mätningen. Då förvandlas ”servern låter varje natt” till en specifik komponent och utlösare.

Fastställ gränsen mellan normalt nattarbete och ett fel

Acceptera aktiviteten som normal när den börjar enligt ett känt schema eller efter en nylig biblioteksändring, slutför nyttigt arbete, inte lämnar efter sig ett växande antal fel och återställer lagringslatens och ködjup till baslinjen. Notera den normala varaktigheten så att framtida ökningar har en jämförelsepunkt.

En äldre Immich-diskussion om frekventa databasskrivningar illustrerar varför viss databasaktivitet kan förekomma utan någon synlig användaråtgärd. Eftersom versioner och distributioner förändras bör du endast använda fallet som stöd för att mäta databasen separat, inte för att förklara alla ihållande skrivningar som normala.

Eskalerar när I/O fortsätter efter att köerna stannat, samma fel återkommer, lagringslatensen påverkar användningen dagtid, ledigt utrymme minskar oväntat eller mönstret ökar natt efter natt. Spara tidsstämplar, process-I/O, jobbantal, relevanta loggar, ledigt utrymme i filsystemet och en reproducerbar utlösare innan du gör ingripande ändringar.