Revisie opschonen revision-cleanup

Vragen

Antwoorden

Wat zou ik van op de hoogte moeten zijn wanneer ik aan AEM 6.5 opwaardeer?

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 Oak-segment (AEM 6.2 en lager) moeten worden gemigreerd.

Extra voordelen van het wijzigen van de opslagindeling:

• Betere schaalbaarheid (geoptimaliseerde segmentgrootte).
• Sneller de Inzameling van de Opslag van Gegevens.
• Grondwerkzaamheden voor toekomstige verbeteringen.

Alleen de nieuwe Oak Segment Tar wordt ondersteund met AEM 6.3 of hoger.

Ja. Tenzij u met een nieuw exemplaar begint, zult u altijd de inhoud moeten migreren.

Nee, zoals hierboven is uiteengezet, is migratie van inhoud verplicht.

Nee. Dit is een eenmalige inspanning die niet op een lopende instantie kan worden gedaan.

Als u probeert om de eiken-segmentmodule tegen een eak-segment-teer bewaarplaats (of omgekeerd) in werking te stellen, ontbreekt het opstarten met een IllegalStateException met het bericht "Ongeldig segmentformaat". Er treedt geen gegevensbeschadiging op.

Nee. Bij het migreren van een eikensegment naar een eikensegment worden wijzigingen aangebracht in de containerindeling. De ingesloten gegevens worden niet beïnvloed en worden niet gewijzigd.

De migratie is gelijk aan het opnieuw maken van de segmentstore in de nieuwe indeling. Dit kan worden gebruikt om de extra schijfruimte te schatten nodig tijdens migratie. Na de migratie kan de oude segmentwinkel worden verwijderd om ruimte vrij te maken.

De prestaties van de migratie kunnen zeer worden verbeterd als off-line revisie schoonmaakbeurtvoorafgaand aan de migratie wordt uitgevoerd. Alle klanten wordt geadviseerd om het als eerste vereiste van het verbeteringsproces uit te voeren. In het algemeen, zou de duur van de migratie aan de duur van de off-line revisie schoonmaakbeurttaak gelijkaardig moeten zijn, veronderstellend dat de off-line revisie schoonmaakbeurttaak vóór de migratie is uitgevoerd.

Eenmaal per dag. Dit is de standaardconfiguratie in het Dashboard van Verrichtingen.

Zie hoe te om Online sectie van de Opruiming van de Revisiein werking te stellen.

Het wordt geadviseerd om Online Opruiming van de Revisie eenmaal per dag in werking te stellen, zoals die door gebrek wordt gevormd.

Er is geen behoefte om de frequentie te bepalen aangezien de Online Opruiming van de Revisie als onderhoudstaak wordt gevormd en het automatisch elke dag loopt.

Met Online revisie opschonen worden oude revisies door generaties teruggezet. Elke keer dat de revisie wordt opgeschoond, wordt een nieuwe generatie gegenereerd. Alleen de inhoud die minstens twee generaties oud is, zal worden teruggevorderd, wat betekent dat er voor het eerst niets terug te vorderen is.

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.

Ook, leest de "Lopende Online Opruiming van de Revisie na de Off-line sectie van de Opruiming van de Revisie van dit hoofdstuk.

Dit hangt van kantooruren en de verkeerspatronen van de klant online aanwezigheid af. De onderhoudsvensters moeten buiten de hoofdproductietijden worden geconfigureerd om de beste schoonmaakefficiëntie te waarborgen. Voor meerdere AEM Publish-instanties (TarMK Farm) moeten onderhoudsvensters voor Online Revision Cleanup worden gefaseerd.

Online Revision Cleanup is alleen beschikbaar bij AEM 6.3 en hoger. Ook, als u een oudere versie van AEM gebruikt, moet u aan nieuwe Tar van het Segment van Oak migreren.

De factoren zijn:

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

Ja, Online Revision Cleanup kan gelijktijdige schrijvingen verwerken. Onlinerevisie opschonen werkt echter sneller en efficiënter zonder gelijktijdige schrijftransacties. De Adobe adviseert het plannen van de Online het onderhoudstaak van de Opruiming van de Revisie aan een vrij rustige tijd zonder veel verkeer.

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 genoeg wordt gerangschikt om de gebruiksgevallen en verwachte nuttige lading daarop te behandelen, verkrijgt het schoonmaakbeurtproces genoeg geheugen.

Online Revision Cleanup is een achtergrondproces dat tegelijkertijd leest van en schrijft naar de opslagplaats voor normale systeembewerkingen. Het kan met name nodig zijn om gedurende een korte periode exclusieve toegang tot de opslagplaats te verkrijgen, waardoor andere draden niet in de opslagplaats kunnen worden geschreven.

Het duurt niet langer dan twee uur om te worden uitgevoerd volgens de meest recente Adobe van prestatietests die intern worden uitgevoerd.

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

Zorg ervoor dat andere onderhoudstaken de uitvoering ervan niet vertragen. Dit zou het geval kunnen zijn als meer onderhoudstaken dan Online Revision Cleanup binnen het zelfde onderhoudsvenster worden uitgevoerd. Onderhoudstaken worden opeenvolgend uitgevoerd zonder een configureerbare volgorde.

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:

• De looppas van GC van de revisie: de delta van de Grootte is N% of N/N (N/N bytes), zo lopend compaction
• De controle GC stelt niet in werking: de delta van de Grootte is N% of N/N (N/N bytes), zo overgevend compensatie voor nu

Ja. Sinds AEM 6.3, kan het veilig door middel van het Venster van de Taak van het Onderhoud binnen het Dashboard van Verrichtingen of door middel van JMX worden tegengehouden.

Revision Cleanup wordt onderbroken en de repository wordt veilig afgesloten.

In dergelijke gevallen bestaat er geen risico op gegevensbeschadiging. Restrevers worden opgeschoond door een volgende run.

Verslechtering van prestaties in de loop der tijd.

Standaard verzamelt de Online revisie-opruiming alleen revisies die minstens 24 uur oud zijn.

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 wijze , zoals die in meer detail in de documentatie van Oakwordt verklaard. 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.

Ook, leest de "Lopende Online Opruiming van de Revisie na de Off-line sectie van de Opruiming van de Revisie van dit hoofdstuk.

Eventuele overwegingen met betrekking tot bestandsbewerkingen die zijn toegewezen aan het geheugen?

• op de milieu's van Vensters , wordt de regelmatige dossiertoegang altijd afgedwongen zodat geheugen in kaart gebrachte toegang 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 milieu's niet-Vensters , vergroot de grootte van het fysieke geheugen om de geheugenafbeelding van de bewaarplaats 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 samenstellingsstap tenzij voorafgegaan door het bericht "TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles", wat betekent er teveel gezamenlijke lading was.

Het correspondentatieve is er een bericht "TarMK GC #{}: cleanup completed in {} ({} ms"voor de succesvolle voltooiing van de schoonmaakbeurt stap.

De status, de vooruitgang, en de statistieken worden blootgesteld via JMX (SegmentRevisionGarbageCollection MBean). Voor meer details over SegmentRevisionGarbageCollection MBean, lees volgend paragraaf.

De voortgang kan worden bijgehouden via het kenmerk EstimatedRevisionGCCompletion van het 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. Extern controlehulpmiddel kon worden gebruikt om de gegevens voorbij AEM uptimete houden.

• 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 recentste versie van AEM, merkt het bericht "TarMK GC #{}: estimation started"het begin van raming, "TarMK GC #{}: compaction started, strategy={}"het begin van compensatie en "T arMK GC #{}: cleanup started. Current repository size is {} ({} bytes"merkt het begin van schoonmaakbeurt.
• Schijfruimte die wordt opgeschoond door de revisie
  • De ruimte wordt slechts teruggewonnen wanneer de schoonmaakfase voltooit. De voltooiing van de schoonmaakbeurt fase wordt duidelijk door het logboekbericht "T arMK GC #{}: cleanup completed in {} ({} ms". De opschoningsgrootte van Post is {} ({} bytes) en ruimte teruggewonnen {} ({} bytes). Het gewicht/de diepte van de compactiekaart 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.

Ook, zie het Oplossen van problemen die op de sectie van de Berichten van de Fouthieronder worden gebaseerd.

Er is een bericht in het logboek aan het eind van de opschooncyclus: "TarMK GC #3: cleanup completed"die de grootte van de bewaarplaats en de hoeveelheid geregenereerd huisvuil omvat.

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 bewaarplaats traversal controle
• Gebruik het gereedschap voor het uitvoeren van de eik nadat het opschoonproces is voltooid om te controleren op inconsistenties. Voor verdere informatie over hoe te om dit te doen, controleer de Documentatie Apache. U hoeft AEM niet uit te schakelen om het gereedschap uit te voeren.

De voorwaarden van de mislukking worden duidelijk door WARN of FOUTlogboekberichten die met "TarMK GC"beginnen. Ook, zie het Oplossen van problemen die op de sectie van de Berichten van de Fouthieronder worden gebaseerd.

De Controle van de Gezondheid van de Reiniging van de Herziening maakt deel uit van het Dashboard van Verrichtingen.

De status is GROEN als de laatste uitvoering van de Online het onderhoudstaak van de Opruiming van de Revisie met succes heeft voltooid.

Het is GEEL als de Online het onderhoudstaak van de Opruiming van de Revisie eens werd geannuleerd.

Het is ROOD als de Online het onderhoudstaak van de Opruiming van de Revisie drie keer in een rij werd geannuleerd. In dit geval wordt de handinteractie vereist of de Online Opruimen van de Revisie zal waarschijnlijk opnieuw ontbreken. Voor meer informatie, lees de sectie van het Oplossen van problemen 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.Extern controlehulpmiddel kon worden gebruikt om de gegevens voorbij AEM uptimete houden.

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

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

De statistieken zijn alleen beschikbaar sinds de laatste systeemstart. Extern controlehulpmiddel kon worden gebruikt om de gegevens voorbij AEM uptimete houden.

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.

De AEM instantie loopt zonder schijfruimte, wat productieonderbrekingen veroorzaakt.

Het hoge gebruikersverkeer beïnvloedt of de samenstellingsfase met succes kan voltooien of niet.

U kunt verscheidene stappen nemen om de kwestie te vinden en te bevestigen:

• Controleer eerst de logitems

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

  • Als de logboeken vijf gemiste compacte cycli en een onderbreking op de forceCompact cyclus tonen, plant het onderhoudsvenster aan een stille tijd wanneer de hoeveelheid opbergingsbericht laag is. U kunt bewaarplaats controleren schrijft in het hulpmiddel van de gegevensverwerking van de bewaarplaats in 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.

Zie het vorige punt.

Onlinerevisie-opschoning is geannuleerd en de resterende versies worden verwijderd. De volgende keer dat het onderhoudsvenster is gepland, wordt het programma opnieuw gestart.

Een 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 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. Voor meer details op hoe te om de eiken-looppas controle uit te voeren, lees de volgende documentatie van Apache.
3. Adres alle andere voorkomen door de Zorg van de Klant van de Adobe.

De grootte van de opslagplaats en het aantal revisies dat moet worden opgeschoond, bepalen de duur van de opruiming.

• de revisie van Oak: Oak organiseert alle inhoud in een grote boomhiërarchie die uit knopen 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.
• Versie van de Pagina: Versioning leidt tot een "momentopname"van een pagina op een specifiek punt in tijd. Gewoonlijk wordt een nieuwe versie gemaakt wanneer een pagina wordt geactiveerd. Voor meer informatie, zie Werkend met de Versies van de Pagina.

Als de revisietaak niet binnen 8 uren voltooit en draaddumpsopenbaren dat belangrijkste hotspot InMemoryCompactionMap.findEntry is, gebruik de volgende parameter met het eiken-in werking gestelde hulpmiddel versies 1.4 of hoger: -Dtar.PersistCompactionMap=true. De parameter -Dtar.PersistCompactionMap is verwijderd uit Oak versie 1.6.