Revision Cleanup

Introduktion

Varje uppdatering av databasen skapar en ny innehållsrevision. Det innebär att databasstorleken ökar för varje uppdatering. Gamla revideringar måste rensas för att frigöra diskutrymme - det är viktigt för att undvika okontrollerad databastillväxt. Den här underhållsfunktionen kallas Revision Cleanup. Det har funnits som en offlinerutrutin sedan AEM 6.0.

Med AEM 6.3 och senare introducerades en onlineversion av den här funktionen som kallas Online Revision Cleanup. Jämfört med funktionen för rensning av offlineredigering, där AEM ska stängas av, kan rensning av onlinerevision köras när den AEM instansen är online. Rensa onlineändringar är aktiverat som standard och det är det rekommenderade sättet att rensa en revision.

Anteckning: Se videon om du vill ha en introduktion och hur du använder funktionen för rensning av onlineversioner.

Rensningsprocessen består av tre faser: uppskattning, komprimering och rensa. Beräkningen avgör om nästa fas (komprimering) ska köras eller inte baserat på hur mycket skräp som kan samlas in. Under komprimeringsfasen skrivs segment och tjärfiler om, utan att något innehåll som inte används tas bort. Rengöringsfasen tar sedan bort de gamla segmenten inklusive eventuellt skräp. Offlineläget kan vanligtvis frigöra mer utrymme eftersom onlineläget måste ta hänsyn till AEM som inte samlar in fler segment.

Mer information om Revision Cleanup finns på följande länkar:

Dessutom kan du läsa officiell ekdokumentation.

När ska onlinerevision rensas i stället för Offline Revision Cleanup?

Rensning av onlineändringar är det rekommenderade sättet att rensa revideringar. Rensning av offlineredigering bör endast användas i undantagsfall, t.ex. innan du migrerar till det nya lagringsformatet eller om du har ombetts att göra det av Adobe kundtjänst.

Så här kör du rensning av onlineändringar

Rensning av onlineändringar är konfigurerat som standard att automatiskt köras en gång om dagen på både AEM Author- och Publish-instanser. Allt du behöver göra är att definiera underhållsfönstret under en period med minsta användaraktivitet. Du kan konfigurera rensningsaktiviteten för onlineändringar enligt följande:

I AEM går du till Verktyg - Drift - Kontrollpanel - Underhåll eller hänvisa webbläsaren till https://serveraddress:serverport/libs/granite/operations/content/maintenance.html
Hovra över Daglig underhållsperiod och klicka på Inställningar ikon.
Ange önskade värden (upprepning, starttid, sluttid) och klicka på Spara.

Om du vill köra revideringsrensningen manuellt kan du:

Gå till Verktyg - Drift - Kontrollpanel - Underhåll eller gå direkt till https://serveraddress:serverport/libs/granite/operations/content/maintenance.html
Klicka på Daglig underhållsperiod.
Hovra över Revision Cleanup ikon.
Klicka Kör.

Online Revision Cleanup After Offline Revision Cleanup

Rensningsprocessen för revision återtar gamla versioner av generationer. Det innebär att varje gång du kör en revideringsrensning skapas en ny generation som sparas på disken. Det finns dock en skillnad mellan de två typerna av revisionsrensning: rensning av offlineändringar sparar en generation medan rensning av onlineändringar sparar två generationer. Så när du rensar onlineändringar efter när en offlineredigering rensas händer följande:

När den första rensningen av onlineversionen har gjorts kommer databasen att ha dubbel storlek. Det beror på att det nu finns två generationer som finns på disken.
Under efterföljande körningar kommer databasen att växa tillfälligt medan den nya generationen skapas och sedan stabiliseras tillbaka till den storlek som den hade efter den första körningen, när rensningsprocessen för onlineändringar återtar den tidigare generationen.

Tänk också på att beroende på typ och antal implementeringar kan varje generation variera i storlek jämfört med den föregående, vilket innebär att den slutliga storleken kan variera mellan olika körningar.

På grund av detta bör du göra skivans storlek minst två eller tre gånger större än den ursprungligen beräknade databasstorleken.

Komprimeringslägen i full- och slutläge

AEM 6.5 introducerar två nya lägen för komprimering fas av rensningsprocessen för onlinerevision:

The full komprimering I läget skrivs alla segment och tjärfiler i hela databasen om. Den efterföljande rensningsfasen kan på så sätt ta bort den maximala mängden skräp i databasen. Eftersom fullständig komprimering påverkar hela databasen krävs det mycket systemresurser och tid för att slutföra. Fullständig komprimering motsvarar komprimeringsfasen i AEM 6.3.
The svanskomprimering I läget skrivs endast de senaste segmenten och tjärfilerna i databasen om. De senaste segmenten och tjärfilerna är de som har lagts till sedan den senaste gången komprimeringen kördes, antingen helt eller slut. Den efterföljande rensningsfasen kan därför bara ta bort det skräp som finns i den senaste delen av databasen. Eftersom slutkomprimering bara påverkar en del av databasen krävs betydligt mindre systemresurser och tid för att slutföra kompaktionen än fullständig komprimering.

Dessa komprimeringslägen utgör en kompromiss mellan effektivitet och resursförbrukning: Även om slutkomprimeringen är mindre effektiv har den mindre inverkan på den normala systemdriften. Fullständig komprimering är däremot mer effektivt men har större inverkan på den normala systemdriften.

I AEM 6.5 introduceras också en effektivare funktion för borttagning av dubbletter vid komprimering, vilket ytterligare minskar databasens diskutrymme.

De två diagrammen nedan visar resultat från interna laboratorietester som visar minskningen av den genomsnittliga exekveringstiden och den genomsnittliga diskåtgången i AEM 6.5 jämfört med AEM 6.3:

onrc-duration-6_4vs63 segmentstore-6_4vs63

Så här konfigurerar du kompaktion med hel- och slutdata

Standardkonfigurationen kör slutkomprimering på veckodagar och fullständig komprimering på söndagar. Standardkonfigurationen kan ändras med det nya konfigurationsvärdet full.gc.days i RevisionCleanupTask underhållsaktivitet.

När du konfigurerar full.gc.days är du medveten om att fullständig komprimering kommer att köras under de dagar som definieras i värdet och svansen kommer att köras under de dagar som inte definieras i värdet. Om du till exempel konfigurerar fullständig komprimering för att köras på söndag, körs slutkomprimeringen på måndag till lördag. Om du till exempel konfigurerar fullständig komprimering så att den körs varje veckodag kommer slutkomprimeringen inte att köras alls.

Tänk också på följande:

Tail-komprimering är mindre effektivt och har mindre inverkan på den normala systemdriften. Den är således avsedd att köras under vardagar.
Fullständig komprimering är effektivare men har också större inverkan på den normala systemdriften. Den är således avsedd att användas utanför kontorstid.
Både svanskomprimering och fullständig komprimering bör schemaläggas att köras under lågbelastningstimmar.

Felsökning

Tänk på följande när du använder de nya komprimeringslägena:

Du kan övervaka in-/utdataaktiviteten (I/O), till exempel: I/O-åtgärder, CPU väntar på IO, bekräftar köstorlek. Detta hjälper till att avgöra om systemet håller på att bli I/O-bundet och kräver en uppgradering.
The RevisionCleanupTaskHealthCheck visar den övergripande hälsostatusen för onlinerevideringsrensningen. Det fungerar på samma sätt som i AEM 6.3 och skiljer inte mellan full- och svanskomprimering.
Loggmeddelandena innehåller relevant information om komprimeringslägena. När t.ex. onlineredigering av revision startas visas komprimeringsläget i motsvarande loggmeddelanden. I vissa hörnfall återställs systemet dessutom till fullständig komprimering när det var schemalagt att köra en slutkomprimering och loggmeddelandena visar på denna ändring. Loggexemplen nedan visar komprimeringsläget och ändringen från svans till full komprimering:

TarMK GC: running tail compaction
TarMK GC: no base state available, running full compaction instead

Kända begränsningar

I vissa fall kan rensningsprocessen fördröjas om du växlar mellan svansen och det fullständiga komprimeringsläget. Mer exakt kommer databasen att växa efter en fullständig komprimering (den kommer att dubbleras i storlek). Det extra utrymmet kommer att återvinnas i den efterföljande svansen, när databasen kommer att hamna under den förfyllda komprimeringsstorleken. Parallella körningar av underhållsuppgifter bör också undvikas.

Du bör göra disken minst två eller tre gånger större än den ursprungligen beräknade databasstorleken.

Vanliga frågor och svar om rensning av onlineversioner

AEM 6.5 Upgrade Considerations

Frågor

Svar

Vad bör jag veta när jag uppgraderar till AEM 6.5?

Det beständiga formatet för tarMK ändras med AEM 6.5. Dessa ändringar kräver inget proaktivt migreringssteg. Befintliga databaser kommer att genomgå en rullande migrering som är genomskinlig för användaren. Migreringsprocessen initieras första gången AEM 6.5 (eller relaterade verktyg) får åtkomst till databasen.

När migreringen till det beständiga AEM 6.5-formatet har initierats kan databasen inte återställas till det tidigare beständiga AEM 6.3-formatet.

Migrera till Oak Segment tar

Frågor	Svar
Varför måste jag migrera databasen?	I AEM 6.3 behövdes ändringar av lagringsformatet, särskilt för att förbättra prestanda och effekt vid rensning av onlineändringar. Dessa ändringar är inte bakåtkompatibla och databaser som skapats med det gamla eksegmentet (AEM 6.2 och tidigare) måste migreras. Ytterligare fördelar med att ändra lagringsformatet: Bättre skalbarhet (optimerad segmentstorlek). Snabbare Skräpinsamling för datalager. Markarbeten för framtida förbättringar.
Stöds det tidigare tjärformatet fortfarande?	Endast den nya Oak Segment-taggen stöds med AEM 6.3 eller senare.
Är innehållsmigreringen alltid obligatorisk?	Ja. Om du inte börjar med en ny instans måste du alltid migrera innehållet.
Kan jag uppgradera till 6.3 eller senare och göra migreringen senare (till exempel genom att använda ett annat underhållsfönster)?	Nej, som förklaras ovan är innehållsmigrering obligatorisk.
Kan driftstopp undvikas vid migrering?	Nej. Detta är en engångsåtgärd som inte kan utföras på en instans som körs.
Vad händer om jag av misstag kör mot fel databasformat?	Om du försöker köra eksegmentmodulen mot en eksegment-tjärdatabas (eller vice versa) misslyckas start med ett IllegalStateException med meddelandet"Ogiltigt segmentformat". Inga data skadas.
Måste sökindexen indexeras om?	Nej. När du migrerar från eksegment till eksegment-tar ändras behållarformatet. De data som finns påverkas inte och kommer inte att ändras.
Hur beräknas det förväntade diskutrymmet under och efter migreringen på bästa sätt?	Migreringen motsvarar att återskapa segmentbutiken i det nya formatet. Detta kan användas för att uppskatta det ytterligare diskutrymme som behövs under migreringen. Efter migreringen kan det gamla segmentlagret tas bort för att frigöra utrymme.
Hur uppskattar jag migreringens varaktighet på bästa sätt?	Migreringsprestanda kan förbättras avsevärt om rensning av offlinerevision körs före migreringen. Alla kunder uppmanas att göra detta som en förutsättning för uppgraderingsprocessen. Migreringens varaktighet bör i allmänhet vara densamma som tiden för rensningsaktiviteten för offlineändringar, förutsatt att rensningsaktiviteten för offlineändringar har körts före migreringen.

Online Revision Cleanup körs

Frågor	Svar
Hur ofta ska onlinerevision rensas?	En gång om dagen. Det här är standardkonfigurationen på kontrollpanelen för åtgärder.
Hur konfigurerar jag starttiden för underhållsaktiviteten för onlinerensning av revision?	Se Så här kör du rensning av onlinerevision -avsnitt.
Finns det en maxfrekvens som inte får överskridas för onlinerensning av revision?	Vi rekommenderar att du kör rensning av onlineändringar en gång om dagen enligt standardinställningarna.
Vilka är nyckelindikatorerna för hur ofta onlinerevision ska rensas?	Det finns ingen anledning att avgöra hur ofta onlinerättning av revision har konfigurerats som en underhållsuppgift och den körs automatiskt varje dag.
Varför tar onlineredigering inte bort utrymme när programmet körs för första gången?	Online Revision Cleanup återkallar gamla versioner efter generationer. En ny generation genereras varje gång som en revision rensas. Endast det innehåll som är minst två generationer gammalt kommer att återvinnas, vilket betyder att det inte finns något att återkräva i en första omgång.
Varför tar inte den första rensningen av onlinerevision bort något utrymme när den körs efter rensningen av offlinerevision?	Offline Revision Cleanup återtar allt utom den senaste generationen jämfört med de senaste två generationerna för Online Revision Cleanup. Om en ny databas används kommer rensning av onlineändringar inte att frigöra utrymme första gången efter rensningen av offlineredigering, eftersom det inte finns någon generation som räcker för att återvinnas. Läs även avsnittet"Running Online Revision Cleanup after Offline Revision Cleanup" i det här kapitlet.
Skulle författare och publicering vanligtvis ha olika fönster för rensning av onlineversioner?	Detta beror på kontorstid och kundens trafikmönster online. Underhållsfönstren bör konfigureras utanför de huvudsakliga produktionstiderna för att ge bästa möjliga rensningseffekt. För flera AEM Publish-instanser (tarMK-servergrupp) bör underhållsfönstren för onlinerevision Cleanup mellanlagras.
Finns det några krav innan onlineversionen rensas?	Rensa onlineversioner är endast tillgängligt med AEM 6.3 och senare versioner. Om du använder en äldre version av AEM måste du migrera till den nya Oak Segment-tjära.
Vilka faktorer avgör hur länge onlineversionen ska rensas?	Faktorer är: Databasstorlek Läs in på systemet (begäranden per minut, specifikt skrivåtgärder) Aktivitetsmönster (läses eller skrivs) Maskinvaruspecifikationer (processorprestanda, minne, IOPS)
Kan skribenter fortfarande arbeta medan onlineversionen rensas?	Ja, onlinerevision Cleanup kan hantera samtidiga skrivningar. Online Revision Cleanup fungerar dock snabbare och effektivare utan samtidiga write-transaktioner. Vi rekommenderar att du schemalägger underhållsuppgiften Online Revision Cleanup till en relativt lugn tid utan att behöva så mycket trafik.
Vilka är minimikraven för diskutrymme och heap-minne när du kör Online Revision Cleanup?	Diskutrymmet övervakas kontinuerligt under rensning av onlineändringar. Om det tillgängliga diskutrymmet sjunker under ett kritiskt värde avbryts processen. Det kritiska värdet är 25 % av databasens aktuella diskutrymme och kan inte konfigureras. Du bör göra disken minst två eller tre gånger större än den ursprungligen beräknade databasstorleken. Ledigt stackutrymme övervakas kontinuerligt under rensningsprocessen. Om det lediga stackutrymmet skulle sjunka under ett kritiskt värde avbryts processen. Det kritiska värdet konfigureras via org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLD. Standardvärdet är 15%. Recommendations för minsta storlek för komprimeringsstacken separeras inte från rekommendationerna för AEM minnesstorlek. Som allmän regel: Om en AEM är tillräckligt stor för att kunna hantera användningsfallen och den förväntade nyttolasten där, får rensningsprocessen tillräckligt med minne.
Vilken är den förväntade prestandapåverkan när onlinerevision rensas?	Rensa onlineändringar är en bakgrundsprocess som läser från och skriver till databasen samtidigt som vanliga systemåtgärder. Det kan i synnerhet behöva få exklusiv åtkomst till databasen under en kort tidsperiod, vilket förhindrar att andra trådar skriver till databasen.
Hur länge förväntas onlinerevision Cleanup köras?	Det bör inte ta längre tid än två timmar att utföra enligt de senaste prestandatesterna vi utförde internt.
Vad ska du göra om rensning av onlineversioner tar längre tid?	Se till att den körs dagligen. Se till att den körs under minimala databasaktiviteter genom att konfigurera underhållsfönstren i Operations Dashboard därefter. Skala upp systemresurser (processor, minne, I/O).
Vad händer om onlineredigering av versioner överskrider konfigurerade underhålls-Windows?	Se till att andra underhållsåtgärder inte försenar körningen. Detta kan vara fallet om fler underhållsåtgärder än när onlinerevision rensas utförs inom samma underhållsfönster. Observera att underhållsåtgärder utförs sekventiellt utan någon konfigurerbar order.
Varför ignoreras skräpinsamlingen för revideringar?	Revision Cleanup förlitar sig på en uppskattningsfas för att avgöra om det finns tillräckligt med skräp att rengöra. Uppskattaren jämför den aktuella storleken med storleken på databasen efter att den senast kompilerades. Om storleken överskrider den konfigurerade deltavärdet kommer rensning att köras. Storleksdeltavärdet är inställt på 1 GB. Detta innebär att om databasstorleken inte har ökat med 1 GB sedan den senaste rensningen, kommer den nya rensningsprocessen att hoppas över. Nedan anges de relevanta loggposterna för uppskattningsfasen: Revision GC kommer att köras: Storleksförändringen är N% eller N/N (N/N byte), så komprimering körs GC kommer att granska not run: Storleksförändringen är N% eller N/N (N/N byte), så hoppa över komprimering för tillfället
Går det att avbryta den automatiska komprimeringen om prestandan är för hög?	Ja. Sedan AEM 6.3 kan det stoppas på ett säkert sätt via underhållsaktivitetsfönstret på kontrollpanelen för drift eller via JMX.
Om AEM stängs av under en schemalagd rensningsåtgärd avbryts processen säkert eller blockeras avstängningen tills komprimeringen är klar?	Revision Cleanup avbryts och databasen stängs av på ett säkert sätt.
Vad händer när systemet kraschar vid rensning av onlinerevision?	Det finns ingen risk för att data skadas i sådana fall. Skräprester kommer att rensas upp i en efterföljande körning.
Vad blir det för effekt om onlineversionen inte rensas?	Prestandaförsämring över tid.
Vilka revisioner samlas in?	Som standard samlar rensningen av onlineändringar bara in revideringar som är minst 24 timmar gamla.
Vad händer om det uppstår för mycket störningar från samtidig skrivning till databasen?	Om det finns samtidiga skrivningar i systemet kan rensning av onlineversioner kräva exklusiv skrivåtkomst för att ändringarna ska kunna verkställas i slutet av en kompaktionscykel. Systemet kommer att forceCompact-läge, vilket förklaras mer ingående i läcker dokumentation. Under force compact förvärvas ett exklusivt skrivlås för att ändringarna ska kunna verkställas utan att några samtidiga skrivningar stör. Du kan definiera ett tidsgränsvärde om du vill begränsa effekten på svarstiderna. Detta värde ställs in på 1 minut som standard, vilket innebär att om force compact inte slutförs inom 1 minut avbryts komprimeringsprocessen till förmån för samtidiga implementeringar. Kraftkomprimeringens varaktighet beror på följande faktorer: maskinvara: specifikt IOPS. Varaktigheten minskar med fler IOPS. segmentbutiksstorlek: längden ökar med segmentbutikens storlek.
Hur körs onlinerevision Cleanup på en standby-instans?	I ett kallt vänteläge behöver bara den primära instansen konfigureras för att köra onlinerevisionsrensning. I väntelägesinstansen behöver rensning av onlineändringar inte schemaläggas specifikt. Motsvarande åtgärd i en standby-instans är den automatiska rensningen - det motsvarar rensningsfasen i onlineändringsrensningen. Den automatiska rensningen körs i väntelägesinstansen efter att Online Revision Cleanup på den primära instansen har körts. Uppskattnings- och komprimeringsfaserna körs inte på en standby-instans.
Kan Revision Cleanup frigöra mer diskutrymme än Online Revision Cleanup?	Revision Cleanup offline kan omedelbart ta bort gamla versioner medan Online Revision Cleanup måste ta hänsyn till gamla versioner som fortfarande refereras av programstacken. Den första kan på så sätt ta bort skräp mer aggressivt än den senare, där effekten skrivs av under ett par sopinsamlingscykler. Läs även avsnittet"Running Online Revision Cleanup after Offline Revision Cleanup" i det här kapitlet.
Har du något att tänka på när det gäller minnesmappade filåtgärder?	I Windows-miljöer, används alltid vanlig filåtkomst så minnesmappad åtkomst används inte. Som en allmän rekommendation bör allt tillgängligt RAM-minne allokeras till heap-objektet och segmentets cachestorlek ökas. Du ökar segmentCache genom att lägga till alternativet segmentCache.size i org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config (till exempel segmentCache.size=20480). Kom ihåg att utelämna lite RAM-minne för operativsystemet och andra processer. I icke-Windows-miljöer, ökar storleken på det fysiska minnet för att förbättra minnesmappningen för databasen.

Övervaka rensning av onlineändringar

Vad behöver övervakas under rensning av onlineversioner?	Diskutrymmet bör övervakas när rensning av onlinerevision är aktiverat. Rensningen kommer inte att köras eller avslutas när det inte finns tillräckligt med diskutrymme. Kontrollera loggarna för att se när onlineversionen har rensats. Det får inte ta längre tid än 2 timmar. Antal kontrollpunkter. Om det finns fler än tre kontrollpunkter när komprimeringen körs bör du rensa upp kontrollpunkterna.
Hur kontrollerar jag om rensningen av onlineversionen har slutförts utan problem?	Du kan kontrollera om rensningen av onlineändringar har slutförts genom att kontrollera loggarna. Till exempel "`TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles`" innebär att komprimeringssteget slutfördes utan att föregås av meddelandet "`TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles`", vilket betyder att det var för mycket samtidig belastning. Motsvarande meddelande visas`TarMK GC #{}: cleanup completed in {} ({} ms`" för att slutföra rensningssteget.
Var hittar vi statistik över de senaste versionerna av Online Revision Cleanup?	Status, förlopp och statistik visas via JMX (`SegmentRevisionGarbageCollection` MBean). Mer information om `SegmentRevisionGarbageCollection` MBean, läs efter stycke. Förloppet kan spåras via `EstimatedRevisionGCCompletion` attributet för `SegmentRevisionGarbageCollection MBean.` Du kan hämta en referens för MBean med `ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection"`. Observera att statistiken bara är tillgänglig sedan den senaste systemstarten. Externa övervakningsverktyg skulle kunna användas för att hålla data bortom AEM drifttid. Se AEM dokumentation för att bifoga hälsokontroller till Nagios som ett exempel på ett externt övervakningsverktyg.
Vad är relevanta loggposter?	Rensa onlineändringar har startats/stoppats Rensa onlineändringar består av tre faser: uppskattning, komprimering och rensning. Uppskattningen kan tvinga komprimering och rensning att hoppa över om databasen inte innehåller tillräckligt mycket skräp. I den senaste versionen av AEM visas meddelandet`TarMK GC #{}: estimation started`" är början på uppskattningen, "`TarMK GC #{}: compaction started, strategy={}`" markerar början av komprimeringen och "T`arMK GC #{}: cleanup started. Current repository size is {} ({} bytes`" är början på rensningen. Det diskutrymme som frigjorts vid rensning av revision Utrymmet återvinns endast när rensningsfasen är klar. Slutet av rensningsfasen markeras med loggmeddelandet "T`arMK GC #{}: cleanup completed in {} ({} ms`". Storleken efter rensning är {} ({} byte) och utrymmet återtogs {} ({} byte). Vikt/djup för komprimeringsmappning är {}/{} ({} bytes/{})." Ett problem uppstod under rensningen av revisionen Det finns många feltillstånd, som alla markeras med WARN- eller ERROR-loggmeddelanden som börjar med TjärMK GC. Se även Felsökning baserad på felmeddelanden nedan.
Hur mycket utrymme har tagits i anspråk efter att onlinerevision har rensats?	Det finns ett meddelande i loggen i slutet av rensningscykeln: "`TarMK GC #3: cleanup completed`" som innehåller storleken på databasen och mängden återvunnet skräp.
Hur kontrollerar jag databasens integritet efter att onlineversionen har rensats?	Det behövs ingen integritetskontroll för databasen efter rensning av onlinerevision. Du kan dock utföra följande åtgärder för att kontrollera databasens status efter rensning: En databas traversal check Använd ekkörningsverktyget när rensningsprocessen har slutförts för att kontrollera om det finns några inkonsekvenser. Mer information finns i Apache-dokumentation. Du behöver inte stänga av AEM för att köra verktyget.
Hur du identifierar om rensning av onlinerevision har misslyckats och vilka steg ska återställas?	Feltillstånd markeras med WARN- eller FELloggmeddelanden som börjar med TjärMK GC. Se även Felsökning baserad på felmeddelanden nedan.
Vilken information visas i hälsokontrollen för Revision Cleanup? Hur och när bidrar de till den färgkodade statusnivån?	Hälsokontrollen vid rensning av revideringar ingår i Instrumentpanel för åtgärder. Statusen blir GRÖNT om den senaste körningen av underhållsaktiviteten för rensning av onlinerevision har slutförts. Det blir GULA om underhållsaktiviteten Rensa onlineändringar har avbrutits en gång. Det blir RED om underhållsaktiviteten Rensa onlineändringar har avbrutits tre gånger i rad. I detta fall krävs manuell interaktion eller rensning av onlineversioner kommer troligtvis att misslyckas igen. Mer information finns i Felsökning nedan. Observera också att hälsokontrollsstatusen återställs när systemet har startats om. En instans som har startats om nyligen visar en grön status i hälsokontrollen för Revision Cleanup. Externa övervakningsverktyg skulle kunna användas för att hålla data bortom AEM drifttid. Se AEM dokumentation för att bifoga hälsokontroller till Nagios som ett exempel på ett externt övervakningsverktyg.
Hur övervakar jag automatisk rensning på en standby-instans?	Status, förlopp och statistik visas via JMX med `SegmentRevisionGarbageCollection` MBean. Se även följande Oak-dokumentation. Du kan hämta en referens för MBean med `ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection"`. Observera att statistiken endast är tillgänglig sedan den senaste systemstarten. Externa övervakningsverktyg kan användas för att hålla data utanför AEM drifttid. Se även AEM dokumentation för att bifoga hälsokontroller till Nagios som ett exempel på ett externt övervakningsverktyg. Loggfilerna kan också användas för att kontrollera status, förlopp och statistik för den automatiska rensningen.
Vad behöver övervakas under automatisk rensning på en standby-instans?	Diskutrymmet bör övervakas när den automatiska rensningen körs. Slutförandetid (via loggarna) för att säkerställa att 2 timmar inte överskrids. Storlek på segmentlager efter att automatisk rensning har körts. Storleken på segmentbutiken i standby-instansen bör vara ungefär densamma som storleken på den primära instansen.

Felsökning av rensning av onlineversioner

Vad är det värsta som kan hända om du inte kör Online Revision Cleanup?	AEM kommer att få slut på diskutrymme vilket kan orsaka produktionsavbrott.
Är det problem med hög användartrafik att köra rensning av onlinerevision på en publiceringsinstans?	Hög användartrafik påverkar huruvida komprimeringsfasen kan slutföras eller inte.
Enligt hälsokontrollen och loggposterna har rensning av onlineändringar inte slutförts tre gånger i rad. Vad krävs för att onlineversionen ska kunna rensas korrekt?	Du kan utföra flera steg för att hitta och åtgärda problemet: Kontrollera först loggposterna Beroende på informationen i loggarna ska du vidta lämpliga åtgärder: Om loggarna visar fem missade kompakta cykler och en timeout på `forceCompact` schemalägg underhållsfönstret till en lugn tid när mängden databasskrivningar är låg. Du kan kontrollera databasskrivningar i verktyget för övervakning av databasmått som finns på https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html Om rensningen stoppas i slutet av underhållsperioden ska du kontrollera att konfigurationen för underhållsperioden i underhållsuppgifter-användargränssnittet är tillräckligt stor Om det inte finns tillräckligt med stackminne kontrollerar du att instansen har tillräckligt med minne. Om reaktionen är sen kan segmentlagret växa för mycket för att onlinerevision Cleanup ska kunna slutföras även i ett längre underhållsfönster. Om t.ex. ingen lyckad rensning av onlinerevision slutfördes under den senaste veckan rekommenderar vi att du planerar ett offlineunderhåll och kör en rensning av offlineredigering för att få segmentlagret att bli hanterbart igen.
Vad behöver göras när hälsokontrollen är aktiverad?	Se föregående punkt.
Vad händer om rensning av onlineversioner tar slut under det schemalagda underhållet?	Rensa onlineändringar avbryts och överbliven tas bort. Den startas igen nästa gång underhållsfönstret är schemalagt.
Vad orsakar `SegmentNotFoundException` instanser som ska loggas i `error.log` och hur kan jag återhämta mig?	A `SegmentNotFoundException` loggas av tarMK när den försöker komma åt en lagringsenhet (ett segment) som den inte kan hitta. Det finns tre scenarier som kan orsaka problemet: Ett program som kringgår de rekommenderade åtkomstmekanismerna (som Sling och JCR API) och använder ett API/SPI på lägre nivå för att komma åt databasen och sedan överskrider kvarhållningstiden för ett segment. Det innebär att den behåller en referens till en enhet som är längre än den kvarhållningstid som tillåts av onlinerevideringsrensningen (24 timmar som standard). Det här fallet är övergående och leder inte till att data skadas. För att återställa systemet bör ekkörningsverktyget användas för att bekräfta undantagets transienta karaktär (ekskörningskontrollen bör inte rapportera några fel). För att göra detta måste instansen tas offline och sedan startas om. En extern händelse orsakade att data på disken skadades. Det kan vara ett diskfel, slut på diskutrymme eller en oavsiktlig ändring av de datafiler som krävs. I det här fallet måste instansen tas offline och repareras med hjälp av körkontrollen. Mer information om hur du utför körningskontrollen finns i följande Apache-dokumentation. Alla andra händelser bör åtgärdas genom Adobe kundtjänst.

Felsökning baserad på felmeddelanden

error.log blir mycket detaljerad om det uppstår incidenter under rensningen av onlineändringar. Följande matris syftar till att förklara de vanligaste budskapen och ge möjliga lösningar:

Fas	Loggmeddelanden	Förklaring	Nästa steg
Uppskattning	TjärMK GC #2: uppskattningen hoppades över eftersom komprimeringen har pausats.	Uppskattningsfasen hoppas över när komprimering är inaktiverat i systemet efter konfiguration.	Aktivera rensning av onlineversioner.
Ej tillämpligt	TjärMK GC #2: Uppskattningen avbröts: ${REASON}. Hoppar över komprimering.	Uppskattningsfasen avslutades i förtid. Exempel på händelser som kan avbryta beräkningsfasen: det finns inte tillräckligt med minne eller diskutrymme på värdsystemet.	Beroende på den angivna orsaken.
Komprimering	TjärMK GC #2: komprimering pausad.	Så länge komprimeringsfasen pausas av konfigurationen kommer varken beräkningsfasen eller komprimeringsfasen att utföras.	Aktivera rensning av onlineversioner.
Ej tillämpligt	TjärMK GC #2: komprimeringen avbröts: ${REASON}.	Komprimeringsfasen avslutades för tidigt. Exempel på händelser som kan avbryta kompaktionsfasen: det finns inte tillräckligt med minne eller diskutrymme på värdsystemet. Komprimeringen kan också avbrytas genom att systemet stängs av eller genom att det uttryckligen avbryts via administrativa gränssnitt som underhållspanelen i Operations Dashboard.	Beroende på den angivna orsaken.
Ej tillämpligt	TjärMK GC #2: komprimering misslyckades med 32,902 min (1974140 ms), efter 5 cykler.	Det här meddelandet betyder inte att det fanns ett oåterkalleligt fel, men bara den komprimeringen avslutades efter ett visst antal försök. Läs även efter stycke.	Läs följande Oak-dokumentationoch den sista frågan i avsnittet Running Online Revision Cleanup.
Rensa	TjärMK GC #2: rensningen avbröts.	Rensningen avbröts genom att databasen stängdes av. Ingen påverkan på konsekvensen förväntas. Dessutom kommer diskutrymmet troligtvis inte att återvinnas i full utsträckning. Den kommer att återvinnas under nästa revisionsrensningscykel.	Undersök varför databasen har stängts av och gå framåt för att undvika att stänga av databasen under underhållsfönster.

Så här kör du borttagning av offlinerevision

FÖRSIKTIGHET

Använd en Oak-run-version som har ett versionsnummer (både större och mindre) som matchar Oak Core-versionen av din AEM. Om din AEM till exempel har Oak Core version 1.2.x bör du använda den senaste versionen av Oak-run tool 1.2.x.

Adobe har ett verktyg som heter Oak-run för att rensa revisioner. Den kan laddas ned här:

https://repo1.maven.org/maven2/org/apache/jackrabbit/oak-run/

Verktyget är en burk som kan köras manuellt för att komprimera databasen. Processen kallas för rensning av offlineändringar eftersom databasen måste stängas av för att verktyget ska kunna köras korrekt. Se till att planera rensningen i enlighet med ditt underhållsfönster.

Tips om hur du kan förbättra rensningsprocessens prestanda finns i Förbättra prestanda för rensning av offlinerevision.

OBSERVERA

Du kan även rensa gamla kontrollpunkter innan underhållet utförs (steg 2 och 3 i proceduren nedan). Detta rekommenderas endast för instanser som har fler än 100 kontrollpunkter.

Se alltid till att du har en säkerhetskopia av AEM.

Stäng av AEM.

(Valfritt) Använd verktyget för att hitta gamla kontrollpunkter:

java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore

(Valfritt) Ta sedan bort de orefererade kontrollpunkterna:

java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore rm-unreferenced

Kör komprimeringen och vänta tills den är klar:

java -jar -Dsun.arch.data.model=32 oak-run.jar compact install-folder/crx-quickstart/repository/segmentstore

Förbättra prestanda för rensning av offlinerevision

Verktyget för ekakning innehåller flera funktioner som syftar till att öka prestandan för revisionsrensningen och minimera underhållsfönstret så mycket som möjligt.

Listan innehåller flera kommandoradsparametrar, enligt beskrivningen nedan:

-mmap. Du kan ange detta som sant eller falskt. Om värdet är true används minnesmappad åtkomst. Om värdet är false används filåtkomst. Om inget anges används minnesmappad åtkomst på 64-bitarssystem och filåtkomst används på 32-bitarssystem. I Windows används alltid vanlig filåtkomst och det här alternativet ignoreras. Den här parametern har ersatt parametern -Dtar.memoryMMapped.
-Dupdate.limit. Definierar tröskelvärdet för tömning av en temporär transaktion till disk. Standardvärdet är 10000.
-Dcompress-interval. Antal komprimeringsmappningsposter som ska behållas tills den aktuella kartan komprimeras. Standardvärdet är 100000. Om det finns tillräckligt med stackminne bör du öka det här värdet till ett ännu högre värde för snabbare dataflöde. Den här parametern har tagits bort i Oak version 1.6 och har ingen effekt.
-Dcompaction-progress-log. Antalet komprimerade noder som loggas. Standardvärdet är 150000, vilket innebär att de första 150000 komprimerade noderna loggas under åtgärden. Använd detta tillsammans med nästa parameter som beskrivs nedan.
-Dtar.PersistCompactionMap. Ställ in den här parametern på true om du vill använda diskutrymme i stället för heap-minne för att bevara komprimeringskartan. Kräver ekkörningsverktyget version 1.4 och högre. Mer information finns i fråga 3 i Vanliga frågor och svar om rensning av offlinerevision -avsnitt. Den här parametern har tagits bort i Oak version 1.6 och har ingen effekt.
—force. Tvinga komprimering och ignorera en version som inte matchar segmentlagret.

FÖRSIKTIGHET

Använda --force kommer att uppgradera segmentbutiken till den senaste versionen, vilket inte är kompatibelt med äldre versioner av Oak. Tänk också på att ingen nedgradering är möjlig. I allmänhet bör du använda dessa parametrar med försiktighet och endast om du har kunskap om hur de används.

Ett exempel på de parametrar som används:

java -Dupdate.limit=10000 -Dcompaction-progress-log=150000 -Dlogback.configurationFile=logback.xml -Xmx8g -jar oak-run-*.jar checkpoints <repository>

Ytterligare metoder för att utlösa rensning av revision

Förutom metoderna ovan kan du även aktivera funktionen för revisionsrensning med hjälp av JMX-konsolen på följande sätt:

Öppna JMX-konsolen genom att gå till http://localhost:4502/system/console/jmx
Klicka på RevisionGarbageCollection MBean.
I nästa fönster klickar du på startRevisionGC() och sedan Anropa för att starta jobbet Revision Skräpsamling.

Vanliga frågor och svar om rensning av offlinerevision

Vilka faktorer avgör varaktigheten för rensningen av offlineredigering?	Databasstorleken och mängden revideringar som behöver rensas avgör hur lång rensningen ska vara.
Vad är skillnaden mellan en revision och en sidversion?	Oak-revision: Oak organiserar allt innehåll i en stor trädhierarki som består av noder och egenskaper. Varje ögonblicksbild eller revidering av det här innehållsträdet kan inte ändras och ändringar av trädet uttrycks som en sekvens av nya revideringar. Vanligtvis utlöser varje innehållsändring en ny revision. Se även Följ länk. Sidversion: Versionshantering skapar en ögonblicksbild av en sida vid en viss tidpunkt. Vanligtvis skapas en ny version när en sida aktiveras. Mer information finns i Arbeta med sidversioner.
Hur kan vi snabba upp rensningen av offlinerevision om den inte slutförs inom 8 timmar?	Om revideringsaktiviteten inte slutförs inom 8 timmar och tråddumpar visa att den huvudsakliga hotspot-positionen är `InMemoryCompactionMap.findEntry`använder du följande parameter med ekkörningsverktyget version 1.4 eller högre: `-Dtar.PersistCompactionMap=true`. Var medveten om att `-Dtar.PersistCompactionMap` parametern har tagits bort i Oak version 1.6.

Resurser för Business.Adobe.com

Ecommerce Integrations Cms Cloud Customer Communications Embedded Charts Dynamic Media Content Management System