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.
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.
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.
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:
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.
AEM 6.5 introducerar två nya lägen för komprimering fas av rensningsprocessen för onlinerevision:
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:
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:
Tänk på följande när du använder de nya komprimeringslägena:
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.TarMK GC: running tail compaction
TarMK GC: no base state available, running full compaction instead
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.
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. |
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:
|
|
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. |
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:
|
|
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? |
|
|
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:
|
|
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:
|
|
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? |
|
|
Vad behöver övervakas under rensning av onlineversioner? |
|
|
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 " Motsvarande meddelande visas |
|
Var hittar vi statistik över de senaste versionerna av Online Revision Cleanup? | Status, förlopp och statistik visas via JMX ( Förloppet kan spåras via Du kan hämta en referens för MBean med 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? |
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:
|
|
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 Du kan hämta en referens för MBean med 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? |
|
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:
|
|
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
|
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. |
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.
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
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.
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>
Förutom metoderna ovan kan du även aktivera funktionen för revisionsrensning med hjälp av JMX-konsolen på följande sätt:
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? |
|
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. |