Waarom veroorzaakt Immich ’s nachts herhaalde schijfactiviteit?

Immich kan 's nachts herhaaldelijk schijfactiviteit veroorzaken doordat gepland onderhoud, databasewerk, wachtrijtaken voor media of nieuwe pogingen doorgaan nadat mensen de bibliotheek niet meer gebruiken.

Een stil huishouden betekent niet dat een server niets doet. De nuttige vraag is of hetzelfde proces en dezelfde taak de lees- of schrijfbewerkingen op hetzelfde tijdstip verklaren. Breng de activiteit eerst met elkaar in verband en bepaal daarna of het om verwacht werk, het inhalen van een achterstand of een lus gaat die moet worden gestopt.

Koppel de schijfpiek aan het tijdstip voordat je iets wijzigt

Begin met tijdstempels van drie nachten in plaats van één rumoerige waarneming. Noteer wanneer de blok-I/O toeneemt, welk apparaat druk is, of lezen of schrijven overheerst en of het patroon vrijwel op hetzelfde tijdstip begint. Een herhaalbaar begintijdstip wijst op een planner; een onregelmatig patroon wijst sterker op binnenkomende taken, nieuwe pogingen of een andere container.

Immich-implementaties kunnen databaseback-ups en integriteitsgericht werk tijdens uren met weinig gebruik plannen, waardoor een piek in de vroege ochtend opzettelijk kan zijn. Schakel een taak niet uit alleen omdat die de schijven activeert. Controleer eerst of er na het activiteitsvenster een bijbehorende back-up, onderhoudsresultaat of voltooide wachtrijtaak verschijnt.

De aangrenzende ZimaSpace-diagnose van achtergrondwerk van Immich tijdens uren van inactiviteit gebruikt dezelfde regel voor tijdstempels: koppel het zichtbare symptoom aan het proces en de taak voordat je ‘inactief’ als een fouttoestand beschouwt.

Scheid PostgreSQL-schrijfbewerkingen van media-lezingen

Wijzigingen in de applicatiestatus van Immich kunnen PostgreSQL actief houden, zelfs wanneer er geen nieuwe foto wordt geopend. Databasecontrolepunten, write-ahead logging, vacuum-gerelateerd werk en normale applicatie-updates hebben een ander I/O-profiel dan het scannen van duizenden mediabestanden. Bepaal eerst welk pad of apparaat het verkeer ontvangt voordat je de fotobibliotheek de schuld geeft.

De bespreking van PostgreSQL-observability in de analyse van pg_stat_io legt uit waarom leesbewerkingen, schrijfbewerkingen, backendactiviteit, het gedrag van controlepunten en achtergrondschrijfbewerkingen van elkaar moeten worden gescheiden. Gebruik dat onderscheid om te bepalen of het databaseapparaat druk is omdat nuttige transacties worden opgeslagen of omdat iets voortdurend opnieuw activiteit veroorzaakt.

Als databaseschrijfbewerkingen klein en periodiek zijn terwijl de mediaschijven inactief blijven, kan het gedrag normale databasehuishouding zijn. Als hetzelfde databasebestand voortdurend zwaar wordt beschreven terwijl geen enkele taak voortgang boekt, bewaar dan de logboeken en onderzoek de verantwoordelijke query's of herstartlus in plaats van de hele bibliotheek naar snellere opslag te verplaatsen.

Controleer of achtergrondwachtrijen daadwerkelijk vooruitgaan

Open de taakweergave en vergelijk wachtende, actieve, mislukte en voltooide taken voor en na het nachtelijke venster. Het genereren van miniaturen, videobewerking, extractie van metadata, machinelearningtaken of werk aan een geïmporteerde bibliotheek kan de opslag na een grote wijziging legitiem actief houden. Een afnemende achterstand is bewijs van nuttig inhaalwerk.

Een recent communityrapport over aanhoudende onverklaarde leesactiviteit laat de tegenovergestelde diagnostische grens zien: zeer hoge, continue leesactiviteit zonder verwacht werk verdient onderzoek en moet niet worden afgedaan als ‘wat Immich nu eenmaal doet’. Beschouw de gemelde snelheid als een casus, niet als een benchmark.

Als dezelfde paar taken mislukken en opnieuw in de wachtrij komen, kan de schijfactiviteit zich herhalen zonder vooruitgang te boeken. Leg de eerste fout en één getroffen item vast en isoleer vervolgens dat taaktype. Wis niet alle wachtrijen en genereer de hele bibliotheek niet opnieuw voordat je hebt vastgesteld of de lus wordt veroorzaakt door één bestand, machtigingen, opslaglatentie of een serviceafhankelijkheid.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Wijs I/O toe aan een proces in plaats van te gokken op basis van schijfgeluid

Gebruik tijdens de volgende herhaling monitoring van de I/O op hostniveau om vast te stellen welk proces het apparaat leest of beschrijft. Koppel dat proces vervolgens aan de Immich-server, PostgreSQL, machine learning, een back-uptool, antivirus, een bestandssysteemcontrole of een niet-gerelateerde container. Schijfleds en ventilatorgeluid kunnen die eigendomsinformatie niet leveren.

Een praktische iotop-werkwijze laat de procesgerichte methode zien. Leg meerdere metingen vast, omdat een korte piek tussen waarnemingen kan verdwijnen; het doel is het proces te onderscheppen tijdens hetzelfde venster als het symptoom.

Als Immich niet de grootste I/O-verbruiker is, stop dan met het wijzigen van Immich-instellingen en volg het werkelijke proces. Als PostgreSQL, Immich of een gerelateerde worker verantwoordelijk is, vergelijk dan de logboeken en taakvoortgang met de I/O-meting. Zo wordt ‘de server maakt elke nacht lawaai’ een specifieke component met een specifieke aanleiding.

Bepaal de grens tussen normaal nachtelijk werk en een storing

Beschouw de activiteit als normaal wanneer deze rond een bekend schema of een recente bibliotheekwijziging begint, nuttig werk voltooit, geen oplopend aantal fouten achterlaat en de opslaglatentie en wachtrijdiepte terugkeren naar het basisniveau. Noteer de normale duur, zodat een toekomstige toename een vergelijkingspunt heeft.

Een historische Immich-discussie over frequente databaseschrijfbewerkingen laat zien waarom er databaseactiviteit kan bestaan zonder zichtbare gebruikersactie. Omdat versies en implementaties veranderen, mag je die casus alleen gebruiken om afzonderlijke metingen van de database te onderbouwen, niet om elke aanhoudende schrijfbewerking als normaal te bestempelen.

Schaal op wanneer de I/O doorgaat nadat de wachtrijen zijn gestopt, dezelfde fouten terugkeren, opslaglatentie het gebruik overdag beïnvloedt, de vrije ruimte onverwacht afneemt of het patroon nacht na nacht toeneemt. Bewaar tijdstempels, proces-I/O, aantallen taken, relevante logboeken, vrije ruimte op het bestandssysteem en één reproduceerbare aanleiding voordat je ingrijpende wijzigingen uitvoert.