Revision Cleanup revision-cleanup

Last update: Mon Jul 15 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

Ämnen:
Administrering

Skapat för:

Administratör

Introduktion introduction

Varje uppdatering av databasen skapar en innehållsändring. 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 Adobe Experience Manager (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.

Obs!: I videonfinns en introduktion och information om hur du använder rensning av onlineversioner.

Revideringsrensningsprocessen består av tre faser: uppskattning, komprimering och rensning. 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. Rensa upp-fasen tar sedan bort de gamla segmenten, inklusive eventuellt skräp som de innehåller. Offlineläget kan vanligtvis frigöra mer utrymme eftersom onlineläget måste ta hänsyn till AEM arbetsuppsättning som inte samlar in fler segment.

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

Du kan även läsa den officiella Oak-dokumentationen.

När ska onlinerevision rensas i stället för Offline Revision Cleanup? when-to-use-online-revision-cleanup-as-opposed-to-offline-revision-cleanup

Rensning av onlineändringar rekommenderas för att utföra rensning av revisioner.Rensning av offlineredigering bör endast användas i undantagsfall, till exempel 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 how-to-run-online-revision-cleanup

Rensa onlineändringar är konfigurerat som standard så att det automatiskt körs en gång om dagen på både AEM författare 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 på följande sätt:

Gå till Verktyg - Åtgärder - Kontrollpanel - Underhåll i huvudfönstret AEM eller peka din webbläsare till: https://serveraddress:serverport/libs/granite/operations/content/maintenance.html
Håll muspekaren över fönstret Dagligt underhåll och klicka på ikonen Inställningar .
Ange önskade värden (upprepning, starttid, sluttid) och klicka på Spara.

Om du vill köra revideringsrensningen manuellt kan du:

Gå till Verktyg - Åtgärder - Kontrollpanel - Underhåll eller bläddra direkt till https://serveraddress:serverport/libs/granite/operations/content/maintenance.html
Klicka på Daglig underhållsplan.
Håll muspekaren över ikonen Revision Cleanup .
Klicka på Kör.

Online Revision Cleanup After Offline Revision Cleanup running-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å sorteringstyperna av revisioner: när du rensar en version offline behålls en generation medan rensning av onlineversioner behåller två generationer. Så när du kör rensning av onlinerevision efter rensas offlinerevisionen händer följande:

När den första rensningen av onlineversionen har gjorts dubbleras databasstorleken. 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 full-and-tail-compaction-modes

AEM 6.5 introducerar två nya lägen för compaction -fasen i rensningsprocessen för onlineändringar:

Läget Fullständig komprimering skriver om alla segment och målfiler i hela databasen. 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.
Läget slutkomprimering skriver bara om de senaste segmenten och tjärfilerna i databasen. 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 how-to-configure-full-and-tail-compaction

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

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

Tänk också på följande:

Slutlig komprimering är mindre effektivt och har mindre inverkan på normala systemåtgärder. Den är således avsedd att köras under vardagar.
Fullständig komprimering är mer effektivt men har också större effekt på normala systemåtgärder. 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 troubleshooting

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 som väntar på IO, spara köstorlek. Detta hjälper till att avgöra om systemet håller på att bli I/O-bundet och kräver en uppgradering.
RevisionCleanupTaskHealthCheck anger 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, visar motsvarande loggmeddelanden komprimeringsläget. I vissa hörnfall återställs systemet till fullständig komprimering när det var schemalagt att köra en slutkomprimering och loggmeddelandena indikerar den här ändringen. 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 known-limitations

Ibland 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 dubbleras i storlek). Det extra utrymmet återtas i den efterföljande svansen när databasen hamnar under den förfyllda komprimeringsstorleken. Parallella körningar av underhållsuppgifter bör också undvikas.

Du bör ändra storlek på disken minst två eller tre gånger så stor som den ursprungligen uppskattade databasstorleken.

Vanliga frågor och svar om rensning av onlineversioner online-revision-cleanup-frequently-asked-questions

AEM 6.5 Upgrade Considerations aem-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 genomgår en rullande migrering som är transparent 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 migrating-to-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 Oak-segmentet (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 tar 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 omvänt) misslyckas starten 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 offlineändringar 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 running-online-revision-cleanup

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 avsnittet Så här kör du onlineändringsrensning.

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 konfigurationen.

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 det finns en ny databas kommer rensning av onlineändringar inte att frigöra utrymme första gången efter rensning 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 Publish normalt 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 Farm) 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-taggen.

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, onlineredigering kan hantera samtidiga skrivningar. Online Revision Cleanup fungerar dock snabbare och effektivare utan samtidiga write-transaktioner. Adobe rekommenderar att underhållsaktiviteten för onlinerättning schemaläggs till en relativt lugn tid utan någon större 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 skulle sjunka under ett kritiskt värde avbryts processen. Det kritiska värdet är 25 % av databasens aktuella diskutrymme och kan inte konfigureras.

Adobe rekommenderar att du ändrar storlek på disken minst två eller tre gånger så stor som den ursprungligen uppskattade 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. Vanligtvis: Om en AEM är tillräckligt stor för att kunna hantera användningsfallen och den förväntade nyttolasten på den, 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 köra enligt de senaste prestandatesterna för Adobe som utförts internt.

Vad ska du göra om rensning av onlineversioner tar längre tid?

Kontrollera 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. Underhållsåtgärder kö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 den senaste komprimeringen. Om storleken överskrider den konfigurerade deltavärdet körs rensning. Storleksdeltavärdet är inställt på 1 GB. Detta innebär att om databasstorleken inte har ökat med 1 GB sedan den senaste rensningen, hoppas den nya versionen över.

Nedan anges de relevanta loggposterna för uppskattningsfasen:

Granska GC körs: Storleksskillnad är N% eller N/N (N/N byte), så komprimering körs
GC för revision kör inte: 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 på ett säkert sätt om prestandan är för hög?

Ja. Sedan AEM 6.3 kan den stoppas på ett säkert sätt via underhållsuppgiftsfö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 rensas bort 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 finns för mycket störningar från samtidiga skrivningar 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 försätts i forceCompact-läge, vilket beskrivs mer ingående i Oak-dokumentationen. Under force compact hämtas ett exklusivt skrivlås för att slutligen genomföra ändringarna utan att några samtidiga skrivningar stör. För att begränsa effekten på svarstiderna kan ett timeout-värde definieras. Detta värde är inställt på en minut som standard, vilket innebär att om force compact inte slutförs inom en minut avbryts komprimeringsprocessen till förmån för samtidiga implementeringar.

Kraftkomprimeringens varaktighet beror på följande faktorer:

maskinvara: IOPS. Varaktigheten minskar med fler IOPS.
segmentbutikens storlek: längden ökar med segmentbutikens storlek.

Hur körs onlinerevision Cleanup på en standby-instans?

I ett kallt vänteläge måste endast 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 rensning av onlineändringar 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 tvingas regelbunden filåtkomst alltid till, 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 kan du öka storleken på det fysiska minnet för att förbättra minnesmappningen för databasen.

Övervaka rensning av onlineändringar monitoring-online-revision-cleanup

Vad måste övervakas under rensning av onlineversioner?

Diskutrymmet bör övervakas när rensning av onlinerevision är aktiverat. Rensningen körs inte eller avslutas i förväg 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.

TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles innebär till exempel att komprimeringssteget har slutförts utan fel om det inte föregås av meddelandet TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles, vilket innebär att det fanns för mycket samtidig inläsning.

Motsvarande meddelande TarMK GC #{}: cleanup completed in {} ({} ms om att rensningssteget har slutförts.

Var hittar vi statistik över de senaste rensningarna av onlineversioner?

Status, förlopp och statistik visas via JMX (SegmentRevisionGarbageCollection MBean). Mer information om SegmentRevisionGarbageCollection MBean finns i följande stycke.

Förloppet kan spåras via attributet EstimatedRevisionGCCompletion i 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".

Statistiken är endast tillgänglig sedan den senaste systemstarten. Externa övervakningsverktyg kan användas för att hålla data utanför AEM drifttid.

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 markerar meddelandet TarMK GC #{}: estimation started början av uppskattningen, TarMK GC #{}: compaction started, strategy={} markerar början på komprimeringen och TarMK GC #{}: cleanup started. Current repository size is {} ({} bytes markerar början på rensningen.
Det diskutrymme som frigjorts vid rensning av revision
- Utrymmet återvinns endast när rensningsfasen är slutförd. Slutförandet av rensningsfasen markeras av loggmeddelandet "TarMK GC #{}: cleanup completed in {} ({} ms". Rensningsstorleken för Post är {} ({} byte) och utrymmet återanvänds {} ({} byte). Vikt/djup för komprimeringsmappning är {}/{} ({} byte/{})."
Ett fel 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 avsnittet 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 traversal-kontroll för databasen
Använd ekkörningsverktyget när rensningsprocessen har slutförts för att kontrollera om det finns några inkonsekvenser. Mer information om hur du gör detta finns i Apache-dokumentationen. 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 avsnittet 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 för rensning av revision ingår i instrumentpanelen för åtgärder.

Statusen är GREEN om den senaste körningen av underhållsaktiviteten för rensning av onlinerevision har slutförts.

Det är YELLOW om underhållsaktiviteten för rensning av onlinerevision avbröts en gång.

Det är RED om underhållsaktiviteten Rensa online-revision avbröts tre gånger i rad. I det här fallet krävs manuell interaktion eller så misslyckas rensningen av onlineändringar troligtvis igen. Mer information finns i avsnittet Felsökning nedan.

Dessutom återställs hälsokontrollsstatusen efter en omstart av systemet. En instans som har startats om nyligen visar en grön status i hälsokontrollen för Revision Cleanup. Externa övervakningsverktyg kan användas för att hålla data utanför AEM drifttid.

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 genom att använda ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection".

Statistiken är endast tillgänglig sedan den senaste systemstarten. Externa övervakningsverktyg kan användas för att hålla data utanför AEM drifttid.

Loggfilerna kan också användas för att kontrollera status, förlopp och statistik för den automatiska rensningen.

Vad måste ö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 troubleshooting-online-revision-cleanup

Vad är det värsta som kan hända om du inte kör Online Revision Cleanup?

AEM får slut på diskutrymme vilket orsakar produktionsavbrott.

Är det problem med hög användartrafik att köra rensning av onlinerevision på en publiceringsinstans?

Hög användartrafik påverkar om 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 i forceCompact-cykeln, schemalägger du underhållsperioden till en tyst tidpunkt när mängden databasskrivningar är låg. Du kan kontrollera databasskrivningar i databasmätningsverktyget på https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html
- Om rensningen stoppas i slutet av underhållsperioden kontrollerar du 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 det blir en sen reaktion kan segmentlagret växa för mycket för att onlineversionen ska kunna rensas ä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 offlineserv och kör en rensning av offlinerevision för att få segmentlagret att bli hanterbart igen.

Vad ska 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 har avbrutits och överbliven tas bort. Den startar igen nästa gång underhållsfönstret är schemalagt.

Vad gör att SegmentNotFoundException instanser loggas i error.log och hur kan jag återställa?

En 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 körkontrollen. Mer information om hur du utför körningskontrollen finns i följande Apache-dokumentation.
Åtgärda alla andra förekomster genom Adobe kundtjänst.

Felsökning baserad på felmeddelanden troubleshooting-based-on-error-messages

error.log är utförlig om det finns incidenter under rensningen av onlineversioner. 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äraMK GC #2: Uppskattningen hoppades över eftersom komprimeringen pausas.

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. Några 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äraMK GC #2: komprimering pausad.

Så länge komprimeringsfasen pausas av konfigurationen körs varken beräkningsfasen eller komprimeringsfasen.

Aktivera rensning av onlineversioner.

Ej tillämpligt

TjäraMK GC #2: komprimeringen avbröts: ${REASON}.

Komprimeringsfasen avslutades för tidigt. Några exempel på händelser som kan avbryta komprimeringsfasen: 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 i 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 några försök. Läs även det följande stycket.

Läs följande Oak-dokumentation och den senaste frågan i rensningsavsnittet för onlineändringar.

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önstren.

Så här kör du borttagning av offlinerevision how-to-run-offline-revision-cleanup

CAUTION

Använd en Oak-körningsversion som har ett versionsnummer (både större och mindre) som överensstämmer med Oak kärnversion 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-verktyget 1.2.x.

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

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

Verktyget är en körbar 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 offlineredigering.

NOTE

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:

code language-xml
`java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore`

(Valfritt) Ta sedan bort de orefererade kontrollpunkterna:

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

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

code language-xml
`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 increasing-the-performance-of-offline-revision-cleanup

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:

-map. Du kan ange det här 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 den här 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 senare. Mer information finns i fråga 3 i avsnittet Vanliga frågor och svarom offlineredigering. 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.

CAUTION

Om du använder parametern --force uppgraderas segmentbutiken till den senaste versionen, vilket inte är kompatibelt med äldre Oak-versioner. 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 du använder dem.

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 additional-methods-of-triggering-revision-cleanup

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 på Invoke för att starta jobbet Revision Skräpsamling.

Vanliga frågor och svar om rensning av offlinerevision offline-revision-cleanup-frequently-asked-questions

Vilka faktorer avgör varaktigheten för rensningen av offlineredigering?

Databasstorleken och antalet revisioner som måste 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: En ögonblicksbild av en sida skapas 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åddumparna visar att den huvudsakliga hotspot-positionen är InMemoryCompactionMap.findEntry använder du följande parameter med körningsverktyget version 1.4 eller senare: -Dtar.PersistCompactionMap=true. Parametern -Dtar.PersistCompactionMap har tagits bort i Oak version 1.6.

recommendation-more-help

19ffd973-7af2-44d0-84b5-d547b0dffee2