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.
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. 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 som inte samlar in fler segment.
Mer information om Revision Cleanup finns på följande länkar:
Du kan även läsa officiell dokumentation.
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.
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 publiceringsinstanser. 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:
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
Hovring 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å 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 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
värdet, full komprimering körs under de dagar som definieras i värdet och svansen-komprimeringen körs 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 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:
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
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 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 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. |
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 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 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 konfigurationen som standard. |
|
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 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 publiceringsinstanser (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, 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 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? |
|
|
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:
|
|
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 forceCompact-läge, vilket förklaras mer ingående i Oak-dokumentation. 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:
|
|
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? |
|
|
Vad måste ö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 rensningarna av onlineversioner? | Status, förlopp och statistik visas via JMX ( Förloppet kan spåras via Du kan hämta en referens för MBean med Statistiken är endast tillgänglig sedan den senaste systemstarten. Externa övervakningsverktyg kan användas för att hålla data utanför 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 är GRÖNT om den senaste körningen av underhållsaktiviteten för rensning av onlinerevision har slutförts. Det är GULA om underhållsaktiviteten Rensa onlineändringar har avbrutits en gång. Det är 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. 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. 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 Statistiken är endast 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 måste ö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 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 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 söka efter och åtgärda problemet i flera steg:
|
|
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 orsakar SegmentNotFoundException instanser som ska loggas i error.log och hur kan jag återhämta mig? |
A
|
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 har avbrutits: ${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 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önstren. |
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 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 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 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 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
parametern uppgraderar 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>
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 antalet revisioner som måste 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 . The -Dtar.PersistCompactionMap parametern har tagits bort i Oak version 1.6. |