Revisie opschonen revision-cleanup

De persistentieformaat van TarMK verandert met AEM 6.5. Deze wijzigingen vereisen geen proactieve migratiestap. Bestaande opslagruimten doorlopen een rolmigratie, die transparant is voor de gebruiker. Het migratieproces wordt voor het eerst gestart AEM 6.5 (of verwante tools) toegang tot de opslagplaats.

Nadat de migratie naar de AEM 6.5 persistentieformulier is gestart, kan de repository niet worden teruggezet 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. Als er een nieuwe opslagplaats is, zal Online Revision Cleanup geen ruimte terugwinnen wanneer deze voor de eerste keer na de Offline Revision Cleanup wordt uitgevoerd omdat er geen generatie oud genoeg is om te worden teruggewonnen.

Lees ook de sectie "Online revisie opschonen na offlinerevisie opschonen" 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.

Adobe raadt u aan 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. Algemeen: Als een AEM instantie zo groot is dat deze het hoofd kan bieden aan de gebruiksgevallen en de verwachte nuttige lading ervan, verkrijgt het opschoonproces voldoende geheugen.

• 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, schoonmaakbeurtlooppas. 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
• Revisie GC doet dit 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 gaat in forceCompact, modus, zoals nader toegelicht in de Oak-documentatie. Tijdens forceren compact, wordt een exclusieve schrijfslot verworven om de veranderingen definitief te begaan zonder enige gelijktijdige schrijft het storen. Om de impact op responstijden te beperken, kan een time-outwaarde worden gedefinieerd. Deze waarde wordt standaard ingesteld op één minuut. Dit betekent dat als het compacte effect niet binnen één minuut wordt voltooid, het verrekeningsproces wordt afgebroken ten gunste van gelijktijdige verbintenissen.

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

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

In een koude stand-by opstelling, slechts moet de primaire instantie worden gevormd om Online de Opruiming 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 kunnen oude revisies direct worden verwijderd, 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 opschonen na offlinerevisie opschonen" 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.
• Op omgevingen buiten Windows, 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 vooraf 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.

De status, de vooruitgang, en de statistieken worden blootgesteld via JMX (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".

De statistieken zijn alleen beschikbaar sinds de laatste systeemstart. De externe controlehulpmiddelen zouden kunnen worden gebruikt om de gegevens voorbij 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 Opruiming van de Revisie bestaat uit drie fasen: raming, compensatie, en schoonmaakbeurt. 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". Formaat na opruimen is {} ({} bytes) en opnieuw geclaimde ruimte {} ({} 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. Raadpleeg de 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 is GROEN als de laatste uitvoering van de onderhoudstaak Onlinerevisie is voltooid.

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

Het is 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.

Ook wordt de status van de Health Check opnieuw ingesteld nadat het systeem opnieuw is opgestart. Dus een nieuw opgestarte instantie toont een groene status op de Revision Cleanup Health Check. De externe controlehulpmiddelen zouden kunnen worden gebruikt om de gegevens voorbij 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 blootgesteld via JMX door te gebruiken 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".

De statistieken zijn alleen beschikbaar sinds de laatste systeemstart. De externe controlehulpmiddelen zouden kunnen worden gebruikt om de gegevens voorbij 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 de Automatische Opruiming 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 repository controleren in het meetprogramma van de gegevensopslagplaats 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, controleert u of de instantie voldoende geheugen heeft.
  • Als er een late reactie is, zou de segmentstore te veel voor Online de Opruiming 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 de Opruiming van de Revisie van de Off-line in werking te stellen 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 dat 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 Revision Cleanup (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 gezet 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 exemplaren door Klantenservice Adoben.

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