Revisie opschonen revision-cleanup

Het persistentieformaat van TarMK zal met AEM 6.4 veranderen. Deze wijzigingen vereisen geen proactieve migratiestap. Bestaande opslagruimten zullen door een het rollen migratie gaan, die voor de gebruiker transparant is. Het migratieproces wordt gestart de eerste keer dat AEM 6.4 (of verwante tools) toegang krijgt tot de opslagplaats.

Zodra de migratie naar de AEM 6.4 persistentievorm is geïnitieerd, kan de gegevensopslagruimte niet terugkeren naar de vorige AEM 6.3 persistentieformaat.

In AEM 6.3 waren wijzigingen in de opslagindeling nodig, vooral om de prestaties en effectiviteit van Online Revision Cleanup te verbeteren. Deze wijzigingen zijn niet compatibel met oudere versies en opslagruimten die zijn gemaakt met het oude eiken segment (AEM 6.2 en lager) moeten worden gemigreerd.

Extra voordelen van het wijzigen van de opslagindeling:

• Betere schaalbaarheid (geoptimaliseerde segmentgrootte).
• Sneller Opruimverzameling gegevensopslag.
• Grondwerkzaamheden voor toekomstige verbeteringen.

Met Offline revisie Cleanup wordt alles geherclaimd, behalve de nieuwste generatie in vergelijking met de nieuwste twee generaties voor online revisie Cleanup. In het geval van een nieuwe opslagplaats zal Online Revision Cleanup geen ruimte terugwinnen wanneer deze voor de eerste keer wordt uitgevoerd na de Offline Revision Cleanup omdat er geen generatie oud genoeg is om te worden teruggewonnen.

Lees ook de sectie "Online revisie-opschoning uitvoeren na offlinerevisie-opruiming" van dit hoofdstuk.

De factoren zijn:

• Grootte opslagplaats
• Laden op het systeem (aanvragen per minuut, schrijven specifiek bewerkingen)
• Activiteitspatroon (lezen versus schrijven)
• Hardwarespecificaties (CPU-prestaties, geheugen, IOPS)

De schijfruimte wordt voortdurend gecontroleerd tijdens het online opschonen van revisies. Als de beschikbare schijfruimte onder een kritieke waarde daalt, wordt het proces geannuleerd. De kritieke waarde is 25% van de huidige schijfvoetafdruk van de opslagplaats en kan niet worden geconfigureerd.

Het wordt aanbevolen de schijf minstens twee of drie keer groter te maken dan de aanvankelijk geschatte grootte van de opslagplaats.

De vrije heapruimte wordt voortdurend gecontroleerd tijdens het schoonmaakproces. Als de vrije heapruimte onder een kritieke waarde daalt, wordt het proces geannuleerd. De kritieke waarde wordt gevormd door org.apache.jackrabbit.segment.SegmentNodeStoreService#MEMORY_THRESHOLD. De standaardwaarde is 15%.

Recommendations for minimum compaction heap sizing are not separated from the AEM memory sizing recommendations. In de regel: Als een AEM instantie groot genoeg is om de gebruiksgevallen en de verwachte lading daarop aan te kunnen, zal het schoonmaakproces genoeg geheugen verkrijgen.

• Zorg ervoor dat het dagelijks wordt uitgevoerd.
• Zorg ervoor dat het tijdens minimale opslagruimteactiviteiten wordt uitgevoerd door de onderhoudsvensters in het Dashboard van Verrichtingen dienovereenkomstig te configureren.
• Schaal de systeembronnen (CPU, geheugen, I/O) op.

Herzieningsopschoning is gebaseerd op een schattingsfase om te bepalen of er voldoende afval is om te worden schoongemaakt. De schatter vergelijkt de huidige grootte met de grootte van de bewaarplaats nadat het laatst werd vergeleken. Als de grootte de gevormde delta overschrijdt, zal de schoonmaakbeurt lopen. De delta van de grootte wordt geplaatst op 1 GB. Dit betekent in feite dat als de grootte van de opslagplaats sinds de laatste schoonmaakbeurt niet met 1 GB is toegenomen, de nieuwe herhaling van de revisie wordt overgeslagen.

Hieronder staan de relevante logitems voor de ramingsfase:

• Revision GC wordt uitgevoerd: De delta van de grootte is N% of N/N (N/N bytes), zo lopende compensatie
• Herziening GC niet uitvoeren: De delta van de grootte is N% of N/N (N/N bytes), zodat slaat nu compressie over

Als er schrijfgelijktijdig op het systeem is, zou de online revisie schoonmaakbeurt exclusieve schrijftoegang kunnen vereisen om de veranderingen aan het eind van een samenstellingscyclus te kunnen begaan. Het systeem zal forceCompact, modus, zoals nader toegelicht in de eiken, documentatie. Tijdens forceren compact, wordt een exclusieve schrijfslot verworven om de veranderingen definitief te begaan zonder enige gelijktijdige schrijffout. Om het effect op responstijden te beperken, kan een time-outwaarde worden gedefinieerd. Deze waarde wordt standaard ingesteld op 1 minuut, wat betekent dat als het compacte effect niet binnen 1 minuut wordt voltooid, het verrekeningsproces wordt afgebroken ten gunste van gelijktijdige vastleggingen.

De duur van het forceren is afhankelijk van de volgende factoren:

• hardware: specifiek IOPS. De duur neemt af met meer IOPS.
• grootte segmentwinkel: de duur neemt toe met de grootte van de segmentopslag.

In een koude stand-by opstelling, slechts moet de primaire instantie worden gevormd om Online Correctie van de Revisie in werking te stellen. Voor de stand-by instantie hoeft de Online Revision Cleanup niet specifiek te worden gepland.

De bijbehorende bewerking op een stand-byinstantie is de automatische opschoning. Dit komt overeen met de opschoningsfase van de Online revisie-opschoning. De automatische opschoning wordt uitgevoerd op de reservekopie na de uitvoering van de Online revisie-opschoning op de primaire instantie.

Schatings- en samenstellingsfasen worden niet uitgevoerd op een stand-byinstantie.

Met Offline revisie-opruiming kunt u oude revisies direct verwijderen, terwijl bij Online revisie-opruiming rekening moet worden gehouden met oude revisies waarnaar nog steeds wordt verwezen door de toepassingsstapel. Het eerste kan zo afval agressiever verwijderen dan het laatste waar het effect wordt geamortiseerd tijdens een paar afvalophalingscycli.

Lees ook de sectie "Online revisie-opschoning uitvoeren na offlinerevisie-opruiming" van dit hoofdstuk.

• Windows-omgevingen Regelmatige bestandstoegang wordt altijd afgedwongen, zodat geheugentoegang niet wordt gebruikt. Als algemeen advies, zou al beschikbaar RAM aan de heap moeten worden toegewezen en de segmentcachegrootte zou moeten worden verhoogd. U verhoogt segmentCache door de segmentCache.size optie aan org.apache.jackrabbit.segment.SegmentNodeStoreService.config (bijvoorbeeld, segmentCache.size=20480) toe te voegen. Vergeet niet wat RAM-geheugen over te houden voor het besturingssysteem en andere processen.
• In niet-Windows-omgevingen, vergroot het fysieke geheugen om de geheugentoewijzing van de opslagplaats te verbeteren.

• De schijfruimte moet worden bewaakt wanneer Online revisie-opschoning is ingeschakeld. De opschoonbewerking wordt niet uitgevoerd of wordt voortijdig beëindigd wanneer er onvoldoende schijfruimte is.
• Controleer de logboeken op de voltooiingstijd van Online Revision Cleanup. Het mag niet langer dan 2 uur duren.
• Aantal controlepunten. Als er meer dan 3 controlepunten zijn wanneer de samenstellingslooppas het wordt geadviseerd om de controlepunten schoon te maken.

U kunt controleren of de Online revisie-opruiming is voltooid door de logbestanden te controleren.

Bijvoorbeeld "TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles" betekent de met succes voltooide samenvattingsstap, tenzij deze wordt voorafgegaan door het bericht "TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles", wat betekent dat er te veel gelijktijdige lading was.

Er is dus een bericht "TarMK GC #{}: cleanup completed in {} ({} ms" voor de succesvolle voltooiing van de opschoonstap.

Status, voortgang en statistieken worden via JMX bekendgemaakt (SegmentRevisionGarbageCollection MBean). Voor meer informatie over de SegmentRevisionGarbageCollection MBean, lees de volgende alinea.

De voortgang kan worden bijgehouden via de EstimatedRevisionGCCompletion kenmerk van de SegmentRevisionGarbageCollection MBean.

U kunt een verwijzing van MBean verkrijgen gebruikend ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection”.

Merk op dat de statistieken slechts beschikbaar zijn sinds het laatste systeembegin. De functie voor externe controle kan worden gebruikt om de gegevens langer AEM uptime te houden. Zie de AEM documentatie voor het koppelen van gezondheidscontroles aan Nagios als voorbeeld voor een extern monitoringinstrument.

• Onlinerevisie-opschoning is gestart/gestopt
  • De online Overzichtsopruiming bestaat uit drie fasen: schatting, verdichting en schoonmaak. Schatting kan compaction en schoonmaakbeurt dwingen om over te slaan als de bewaarplaats niet genoeg huisvuil bevat. In de meest recente versie van AEM wordt het bericht "TarMK GC #{}: estimation started" het begin van de raming markeert, "TarMK GC #{}: compaction started, strategy={}" markeert het begin van de compactie en "TarMK GC #{}: cleanup started. Current repository size is {} ({} bytes" markeert het begin van de opschoonbewerking.
• Schijfruimte die wordt opgeschoond door de revisie
  • De ruimte wordt slechts teruggewonnen wanneer de schoonmaakfase voltooit. De voltooiing van de opschoningsfase wordt duidelijk door het logboekbericht "TarMK GC #{}: cleanup completed in {} ({} ms". De grootte van de opschoonbewerking na de opschoonbewerking is {} ({} bytes) en de ruimte die is teruggezet {} ({} bytes). Dikte/diepte van compactiemap is {}/{} ({} bytes/{}).".
• Er is een probleem opgetreden tijdens het opschonen van de revisie
  • Er zijn vele mislukkingsvoorwaarden, worden elk duidelijk door WARN of FOUT logboekberichten die met "TarMK GC"beginnen.

Zie ook de Problemen oplossen op basis van foutberichten hieronder.

Er is geen integriteitscontrole voor de repository nodig nadat de Online Revision Cleanup is uitgevoerd.

U kunt echter de volgende handelingen uitvoeren om de status van de opslagplaats te controleren na het opschonen:

• Een opslagplaats traversale controle
• Gebruik het gereedschap voor het uitvoeren van de eik nadat het opschoonproces is voltooid om te controleren op inconsistenties. Voor meer informatie over hoe te om dit te doen, controleer Apache-documentatie. U hoeft AEM niet uit te schakelen om het gereedschap uit te voeren.

De Revision Clean Health Check maakt deel uit van de Operations-dashboard.

De status GROEN als de laatste uitvoering van de onderhoudstaak Onlinerevisie is voltooid.

Het zal GEEL als de onderhoudstaak Onlinerevisie opschonen eenmaal is geannuleerd.

Het zal ROOD als de onderhoudstaak Onlinerevisie opschonen driemaal achter elkaar is geannuleerd. In dit geval is handmatige interactie vereist of Opschonen van online revisie zal waarschijnlijk opnieuw mislukken. Lees voor meer informatie de Problemen oplossen hieronder.

De status van de Health Check wordt opnieuw ingesteld nadat het systeem opnieuw is opgestart. Dus een nieuw opgestarte instantie zal een groene status tonen op de Revision Cleanup Health Check. De functie voor externe controle kan worden gebruikt om de gegevens langer AEM uptime te houden. Zie de AEM documentatie voor het koppelen van gezondheidscontroles aan Nagios als voorbeeld voor een extern monitoringinstrument.

De status, de vooruitgang en de statistieken worden via JMX blootgesteld door het gebruiken van SegmentRevisionGarbageCollection MBean. Zie ook het volgende Oak-documentatie.

U kunt een verwijzing van MBean verkrijgen door te gebruiken ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection”.

Merk op dat de statistieken beschikbaar slechts sinds het laatste systeembegin zijn. De externe controletools kunnen worden gebruikt om de gegevens na de AEM uptime te houden. Zie ook de AEM documentatie voor het koppelen van gezondheidscontroles aan Nagios als voorbeeld voor een extern monitoringinstrument.

De logboekdossiers kunnen ook worden gebruikt om de status, de vooruitgang en de statistieken van Automatische Opschoning te controleren.

• De schijfruimte moet worden bewaakt wanneer de automatische opschoning wordt uitgevoerd.
• Voltooiingstijd (via de logboeken) om ervoor te zorgen dat 2 uur niet wordt overschreden.
• De grootte van de segmentstore nadat de Automatische Opschoning in werking is gesteld. De grootte van de segmentstore op de standby-instantie moet ongeveer gelijk zijn aan die op de primaire instantie.

U kunt verschillende stappen uitvoeren om het probleem te zoeken en op te lossen:

• Controleer eerst de logbestandvermeldingen

• Afhankelijk van de informatie in de logboeken, neem aangewezen actie:

  • Als de logboeken vijf gemiste compacte cycli en een onderbreking op tonen forceCompact programma, het onderhoudsvenster op een rustige tijd te plannen wanneer de hoeveelheid gegevens in de opslagplaats laag is. U kunt de gegevens van de opslagplaats controleren in het hulpprogramma voor de bewaking van statistische gegevens in de opslagplaats op https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html
  • Als de schoonmaakbeurt aan het eind van het onderhoudsvenster ophield, zorg ervoor de configuratie van het onderhoudsvenster in het gebruikersinterface van de Taken van het Onderhoud groot genoeg is
  • Als er onvoldoende heapgeheugen beschikbaar is, moet u ervoor zorgen dat de instantie voldoende geheugen heeft.
  • In het geval van een late reactie, zou de segmentstore te veel voor Online Correctie van de Revisie kunnen groeien om zelfs binnen een langer onderhoudsvenster te voltooien. Bijvoorbeeld, als er geen succesvolle Online Correctie van de Revisie voltooide in de laatste week was dan wordt het geadviseerd om een off-line onderhoud te plannen en Offline de Opruiming van de Revisie uit te voeren om segmenstore terug naar een handelbare grootte te brengen.

A SegmentNotFoundException wordt geregistreerd door TarMK wanneer het probeert om tot een opslageenheid (een segment) toegang te hebben die het niet kan vinden. Er zijn drie scenario's die deze kwestie kunnen veroorzaken:

1. Een toepassing die de aanbevolen toegangsmechanismen omzeilt (zoals Sling en de JCR API) en een API/SPI op een lager niveau gebruikt om toegang te krijgen tot de opslagplaats en vervolgens de retentietijd van een segment overschrijdt. Dat wil zeggen dat een verwijzing naar een entiteit langer wordt bewaard dan de retentietijd die is toegestaan door de Online revisie-opschoning (standaard 24 uur). Dit geval is van voorbijgaande aard en leidt niet tot gegevenscorruptie. Om te herstellen, zou het eiken-loophulpmiddel moeten worden gebruikt om de voorbijgaande aard van de uitzondering te bevestigen (de eiken-loopcontrole zou geen fouten moeten melden). Hiervoor moet de instantie offline worden genomen en daarna opnieuw worden gestart.
2. Een externe gebeurtenis veroorzaakte de corruptie van de gegevens op de schijf. Dit kan een schijffout, een gebrek aan schijfruimte of een toevallige wijziging van de vereiste gegevensdossiers zijn. In dit geval moet de instantie offline worden genomen en worden gerepareerd met behulp van de eikenrun-controle. Lees voor meer informatie over het uitvoeren van de controle tijdens het uitvoeren van de eik het volgende: Apache-documentatie.
3. Alle andere voorvallen moeten worden aangepakt via de Adobe Klantenservice.

• Oak-revisie: Met eikenhout ordent u alle inhoud in een grote boomstructuur die uit knooppunten en eigenschappen bestaat. Elke momentopname of revisie van deze inhoudsstructuur is onveranderlijk, en de veranderingen in de boom worden uitgedrukt als opeenvolging van nieuwe revisies. Doorgaans leidt elke inhoudwijziging tot een nieuwe revisie. Zie ook Koppeling volgen.
• Paginaversie: Met Versioning maakt u een "momentopname" van een pagina op een bepaald tijdstip. Gewoonlijk wordt een nieuwe versie gemaakt wanneer een pagina wordt geactiveerd. Zie voor meer informatie Werken met paginaversies.