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.

I AEM 6.3 behövdes ändringar av lagringsformatet, särskilt för att förbättra prestanda och effekt vid rensning av onlineändringar. Dessa ändringar är inte bakåtkompatibla och databaser som skapats med det gamla eksegmentet (AEM 6.2 och tidigare) måste migreras.

Ytterligare fördelar med att ändra lagringsformatet:

• Bättre skalbarhet (optimerad segmentstorlek).
• Snabbare Skräpinsamling för datalager.
  
• Markarbeten för framtida förbättringar.

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.

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.

• Databasstorlek
• Läs in på systemet (begäranden per minut, specifikt skrivåtgärder)
• Aktivitetsmönster (läses eller skrivs)
• Maskinvaruspecifikationer (processorprestanda, minne, IOPS)

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.

• Se till att den körs dagligen.
  
• Se till att den körs under minimala databasaktiviteter genom att konfigurera underhållsfönstren i Operations Dashboard därefter.
• Skala upp systemresurser (processor, minne, I/O).

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:

• Revision GC körs: Storleksförändringen är N% eller N/N (N/N byte), så komprimering körs
• Revision GC gör not run: Storleksförändringen är N% eller N/N (N/N byte), så hoppa över komprimering för tillfället

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:

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

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.

• I Windows-miljöer, används alltid vanlig filåtkomst så minnesmappad åtkomst används inte. Som en allmän rekommendation bör allt tillgängligt RAM-minne allokeras till heap-objektet och segmentets cachestorlek ökas. Du ökar segmentCache genom att lägga till alternativet segmentCache.size i org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config (till exempel segmentCache.size=20480). Kom ihåg att utelämna lite RAM-minne för operativsystemet och andra processer.
• I icke-Windows-miljöer, ökar storleken på det fysiska minnet för att förbättra minnesmappningen för databasen.

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

Du kan kontrollera om rensningen av onlineändringar har slutförts genom att kontrollera loggarna.

Till exempel "TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles" innebär att komprimeringssteget slutfördes utan att föregås av meddelandet "TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles", vilket betyder att det var för mycket samtidig belastning.

Motsvarande meddelande visasTarMK GC #{}: cleanup completed in {} ({} ms" för att rensningssteget ska slutföras.

Status, förlopp och statistik visas via JMX (SegmentRevisionGarbageCollection MB). Mer information om SegmentRevisionGarbageCollection MBean, se efter stycke.

Förloppet kan spåras via EstimatedRevisionGCCompletion attributet för SegmentRevisionGarbageCollection MBean.

Du kan hämta en referens för MBean med ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection".

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.

• 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 AEM meddelandetTarMK GC #{}: estimation started" är början på uppskattningen, "TarMK GC #{}: compaction started, strategy={}" markerar början av komprimeringen och "TarMK GC #{}: cleanup started. Current repository size is {} ({} bytes" är början på rensningen.
• Det diskutrymme som frigjorts vid rensning av revision
  • Utrymmet återvinns endast när rensningsfasen är slutförd. Slutet av rensningsfasen markeras med loggmeddelandet "TarMK GC #{}: cleanup completed in {} ({} ms". Storleken efter rensning är {} ({} bytes) och återvunnet utrymme {} ({} byte). Vikt/djup för komprimeringskarta ä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 Felsökning baserad på felmeddelanden nedan.

Det behövs ingen integritetskontroll för databasen efter rensning av onlinerevision.

Du kan dock utföra följande åtgärder för att kontrollera databasens status efter rensning:

• En databas genomgång
• 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-dokumentation. Du behöver inte stänga av AEM för att köra verktyget.

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 SegmentRevisionGarbageCollection MBean. Se även följande Oak-dokumentation.

Du kan hämta en referens för MBean med ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection".

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?

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

• Kontrollera först loggposterna
  
• Beroende på informationen i loggarna ska du vidta lämpliga åtgärder:
  • Om loggarna visar fem missade kompakta cykler och en timeout på forceCompact schemalägg underhållsfönstret till en lugn tid när mängden databasskrivningar är låg. Du kan kontrollera databasskrivningar i verktyget för övervakning av databasmått 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.

A SegmentNotFoundException loggas av tarMK när den försöker komma åt en lagringsenhet (ett segment) som den inte kan hitta. Det finns tre scenarier som kan orsaka problemet:

1. 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.
2. 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.
3. Åtgärda alla andra förekomster via Adobe kundtjänst.

Databasstorleken och antalet revisioner som måste rensas avgör hur lång rensningen ska vara.

• Oak-revision: Oak organiserar allt innehåll i en stor trädhierarki som består av noder och egenskaper. Varje ögonblicksbild eller revidering av det här innehållsträdet kan inte ändras och ändringar av trädet uttrycks som en sekvens av nya revideringar. Vanligtvis utlöser varje innehållsändring en ny revision. Se även Följ länk.
• Sidversion: Versionshantering skapar en ögonblicksbild av en sida vid en viss tidpunkt. Vanligtvis skapas en ny version när en sida aktiveras. Mer information finns i Arbeta med sidversioner.