Revisie opschonen

LET OP

AEM 6.4 heeft het einde van de uitgebreide ondersteuning bereikt en deze documentatie wordt niet meer bijgewerkt. Raadpleeg voor meer informatie onze technische ondersteuningsperioden. Ondersteunde versies zoeken hier.

Inleiding

Bij elke update van de opslagplaats wordt een nieuwe inhoudsrevisie gemaakt. Als gevolg hiervan neemt de grootte van de gegevensopslagruimte bij elke update toe. Om ongecontroleerde groei van opslagplaatsen te voorkomen, moeten oude revisies worden opgeschoond tot vrije schijfmiddelen. Deze onderhoudsfunctionaliteit wordt Revision Cleanup genoemd. Het is sinds AEM 6.0 als offline routine beschikbaar.

Met AEM 6.3 is een online versie van deze functie genaamd Online Revision Cleanup geïntroduceerd. In vergelijking met de offlinerevisie Cleanup, waarbij de AEM instantie moet worden afgesloten, kan Online revisie Cleanup worden uitgevoerd terwijl de AEM online is. Onlinerevisie opschonen is standaard ingeschakeld en is de aanbevolen manier om een revisie op te schonen.

Opmerking: Bekijk de video voor een inleiding en hoe te om Online Correctie van de Revisie te gebruiken.

Het opschoningsproces van de revisie bestaat uit drie fasen: schatting, samenpersen en opruimen. Schatting bepaalt of de volgende fase (compensatie) al dan niet wordt uitgevoerd op basis van hoeveel huisvuil kan worden verzameld. Tijdens de samenstellingsfase worden de segmenten en de teerdossiers herschreven verlaten om het even welke ongebruikte inhoud. De opschoonfase verwijdert vervolgens de oude segmenten, inclusief eventuele ongewenste details. In de offlinemodus kan doorgaans meer ruimte worden vrijgemaakt, omdat in de onlinemodus rekening moet worden gehouden met AEM werkset, waarbij extra segmenten niet worden verzameld.

Raadpleeg de volgende koppelingen voor meer informatie over Revision Cleanup:

Bovendien kunt u ook de officiële eiken-documentatie.

Wanneer u de Online revisie-opruiming wilt gebruiken in tegenstelling tot de offlinerevisie-opruiming?

Online revisie opschonen is de aanbevolen manier om revisie op te schonen. Offline revisie-opruiming mag alleen bij wijze van uitzondering worden gebruikt, bijvoorbeeld voordat u naar de nieuwe opslagindeling gaat of als de klantenservice van Adobe u hierom verzoekt.

Onlinerevisie-opschoning uitvoeren

Onlinerevisie-opschoning is standaard geconfigureerd om automatisch één keer per dag te worden uitgevoerd op zowel AEM-auteur- als -publicatieexemplaren. U hoeft alleen het onderhoudvenster te definiëren gedurende een periode met de minste gebruikersactiviteit. U kunt de Online taak van de Opruiming van de Revisie als volgt vormen:

  1. Ga in het AEM hoofdvenster naar Gereedschappen - Bewerkingen - Dashboard - Onderhoud of wijs uw browser aan: https://serveraddress:serverport/libs/granite/operations/content/maintenance.html

    chlimage_1-90

  2. Overslaan Dagelijks onderhoudvenster en klik op de knop Instellingen pictogram.

    chlimage_1-91

  3. Voer de gewenste waarden in (herhaling, begintijd, eindtijd) en klik op Opslaan.

    chlimage_1-92

Alternatief, als u de revisie schoonmaakbeurttaak manueel wilt in werking stellen, kunt u:

  1. Ga naar Gereedschappen - Bewerkingen - Dashboard - Onderhoud of blader rechtstreeks naar https://serveraddress:serverport/libs/granite/operations/content/maintenance.html

  2. Klik op de knop Dagelijks onderhoudvenster.

  3. Houd de aanwijzer boven de Revisie opschonen pictogram.

  4. Klikken Uitvoeren.

    chlimage_1-93

Online revisie opschonen na offlinerevisie opschonen uitvoeren

Het opschoningsproces van de herziening herstelt oude herzieningen door generaties. Dit betekent dat telkens als u revisie in werking stelt een nieuwe generatie wordt gecreeerd en op de schijf gehouden. Er is echter een verschil tussen de twee soorten opschoning: offline revisie opschonen houdt één generatie bij terwijl online revisie opschonen twee generaties lang duurt. Opschonen wanneer u online revisie uitvoert na offline revisie opschort het volgende:

  1. Nadat de eerste online revisie is gereinigd, wordt de gegevensopslagruimte twee keer zo groot. Dit gebeurt omdat er nu twee generaties op schijf zitten.
  2. Tijdens de volgende runtime zal de opslagplaats tijdelijk groeien terwijl de nieuwe generatie wordt gemaakt en zich vervolgens stabiliseren tot de grootte die het had na de eerste run, terwijl het proces voor online revisie-opruiming de vorige generatie opruimt.

Houd er ook rekening mee dat elke generatie afhankelijk van het type en het aantal bewerkingen een andere grootte kan hebben dan de vorige, zodat de uiteindelijke grootte van de afzonderlijke bewerkingen kan verschillen.

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

Compactiemodi voor volledig en op het spoor

AEM 6,4 introduceren twee nieuwe modi voor de samenpersen Fase van het proces voor online revisie-opschoning:

  • De volledige compressie in de modus worden alle segmenten en teerbestanden in de gehele opslagplaats opnieuw genoteerd. De volgende opschoningsfase kan zo de maximumhoeveelheid huisvuil over de bewaarplaats verwijderen. Aangezien volledige compactie de gehele opslagplaats beïnvloedt, vereist het een aanzienlijke hoeveelheid systeembronnen en tijd om te voltooien. De volledige compactie komt overeen met de verdichtingsfase in AEM 6.3.
  • De staarten samenvoegen in mode worden alleen de meest recente segmenten en teerbestanden in de repository herschreven. De meest recente segmenten en teerbestanden zijn de segmenten die zijn toegevoegd sinds de laatste keer dat de volledige of eindcompressie is uitgevoerd. De volgende opschoningsfase kan dus alleen het afval verwijderen dat zich in het recente deel van de opslagplaats bevindt. Aangezien de staartcompensatie slechts een deel van de bewaarplaats beïnvloedt vereist het aanzienlijk minder systeemmiddelen en tijd om te voltooien dan volledige compensatie.

Deze verrekeningsmodi vormen een afweging tussen efficiëntie en hulpbronnengebruik: hoewel de "tail compaction" minder effectief is, heeft het ook minder invloed op de normale werking van het systeem. Daarentegen is volledige compressie effectiever, maar heeft deze een grotere invloed op de normale werking van het systeem.

AEM 6.4 introduceert ook een efficiënter mechanisme voor het dedupliceren van inhoud tijdens het comprimeren, waardoor de ruimte op de schijf van de opslagplaats verder wordt verkleind.

De twee onderstaande grafieken zijn de resultaten van interne laboratoriumtests die de vermindering van de gemiddelde uitvoeringstijden en de gemiddelde voetafdruk op de schijf in AEM 6.4 ten opzichte van AEM 6.3 aantonen:

onrc-duration-6_4vs63 segmentstore-6_4vs63

Hoe te om Volledige en Samenstelling van het Lusje te vormen

Bij de standaardconfiguratie wordt op weekdagen een verdichtingseffect en op zondag een volledige vereffening uitgevoerd. De standaardconfiguratie kan worden veranderd door de nieuwe configuratiewaarde te gebruiken full.gc.days van de RevisionCleanupTask onderhoudstaak.

Wanneer u vormt full.gc.days Houd er rekening mee dat de volledige compressie wordt uitgevoerd op de dag(en) die in de waarde en de eindvervorming zijn gedefinieerd, tijdens de dagen die niet in de waarde zijn gedefinieerd. Als u bijvoorbeeld volledige compressie configureert om op zondag te worden uitgevoerd, wordt de compressie van de staart van maandag tot en met zaterdag uitgevoerd. Als, bijvoorbeeld, u volledige compilatie vormt om elke dag van de week in werking te stellen dan zal de staartcompensatie niet bij allen lopen.

Houd er ook rekening mee dat:

  • Tagcompressie is minder effectief en heeft minder invloed op normale systeembewerkingen. Het is dus de bedoeling dat het gedurende werkdagen wordt uitgevoerd.
  • Volledige compressie is effectiever, maar heeft ook een grotere invloed op normale systeembewerkingen. Het is dus bedoeld om buiten werkdagen te worden gebruikt.
  • Zowel de staartvervorming als de volledige vervorming zouden moeten worden gepland om tijdens buiten piekuren te lopen.

Problemen oplossen

Houd rekening met het volgende wanneer u de nieuwe compressiemodi gebruikt:

  • U kunt bijvoorbeeld de invoer-/uitvoeractiviteit (I/O) controleren: I/O-bewerkingen, CPU die wacht op IO, limiet van wachtrijgrootte vastleggen. Dit helpt bepalen of het systeem I/O verbindend wordt en vereist upsizing.
  • De RevisionCleanupTaskHealthCheck Hiermee wordt de algemene gezondheidsstatus van de Online revisie-opschoning aangegeven. Het werkt op dezelfde manier als in AEM 6.3 en maakt geen onderscheid tussen volledige en eindverdichtingen.
  • De logberichten bevatten relevante informatie over de compactiemodi. Bijvoorbeeld, wanneer de Online Opruiming van de Revisie begint, zullen de overeenkomstige logboekberichten op de samenstellingswijze wijzen. Bovendien, in sommige hoekgevallen, zal het systeem aan volledige compressie terugkeren wanneer het werd gepland om een staartcompensatie in werking te stellen en de logboekberichten zullen op deze verandering wijzen. De hieronder logboeksteekproeven wijzen op de samenstellingswijze en de verandering van staart in volledige compressie:
TarMK GC: running tail compaction
TarMK GC: no base state available, running full compaction instead

Bekende beperkingen

In sommige gevallen vertraagt het opruimen door het afwisselen tussen de eindmodus en de volledige-compressiemodi. Meer in het bijzonder, zal de bewaarplaats na een volledige compensatie groeien (het zal in grootte verdubbelen). De extra ruimte wordt teruggezet in de volgende 'tail'-compactie, wanneer de opslagplaats onder de pre-volledige compactiegrootte daalt. Parallelle uitvoering van onderhoudstaken moet ook worden vermeden.

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

Online revisie opschonen Veelgestelde vragen

AEM 6.4 Overwegingen bij upgrades

Vragen Antwoorden
Wat zou ik van op de hoogte moeten zijn wanneer ik aan AEM 6.4 opwaardeer?

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.

Migreren naar eiken segmentteer

Vragen Antwoorden
Waarom moet ik de repository migreren?

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:

Wordt de vorige opmaak van de Tar nog steeds ondersteund? Alleen de nieuwe kleurensegmentstrip wordt ondersteund met AEM 6.3.
Is migratie van inhoud altijd verplicht? Ja. Tenzij u met een nieuw exemplaar begint, zult u altijd de inhoud moeten migreren.
Kan ik upgraden naar 6.3 en de migratie later uitvoeren (bijvoorbeeld met een ander onderhoudsvenster)? Nee, zoals hierboven is uiteengezet, is migratie van inhoud verplicht.
Kan downtime tijdens migreren worden voorkomen? Nee. Dit is een eenmalige inspanning die niet op een lopende instantie kan worden gedaan.
Wat gebeurt er als ik per ongeluk tegen de verkeerde gegevensopslagindeling looppas? Als u probeert om de eiken-segmentmodule tegen een eiken-segment-teer bewaarplaats (of vice versa) in werking te stellen, zal het opstarten met een mislukking ontbreken IllegalStateException met het bericht "Invalid segment format". Er treedt geen gegevensbeschadiging op.
Zal een herindex van de zoekindexen noodzakelijk zijn? 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.
Hoe kan de verwachte schijfruimte die tijdens en na de migratie nodig is het beste worden berekend? 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.
Hoe kan de duur van de migratie het best worden ingeschat? De prestaties van de migratie kunnen aanzienlijk worden verbeterd als offline revisie opruimen wordt uitgevoerd vóór de migratie. 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.

Onlinerevisie opschonen uitvoeren

Vragen Antwoorden
Hoe vaak moet Onlinerevisie opschonen worden uitgevoerd? Eenmaal per dag. Dit is de standaardconfiguratie in het Dashboard van Verrichtingen.
Hoe kan ik de begintijd van de Online het onderhoudstaak van de Opruiming van de Revisie vormen? Zie de Onlinerevisie-opschoning uitvoeren sectie.
Is er een maximumfrequentie die niet mag worden overschreden voor Online revisie-opschoning? Het wordt aanbevolen om online revisie-opschoning eenmaal per dag uit te voeren, zoals standaard is geconfigureerd.
Wat zijn de belangrijkste indicatoren die de frequentie bepalen waarop Online de Opruiming van de Revisie zou moeten worden in werking gesteld? 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.
Waarom wordt bij Online revisie-opruiming geen ruimte vrijgemaakt wanneer deze voor het eerst wordt uitgevoerd? 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.
Waarom wint de eerste Online Opruiming van de Revisie geen ruimte terug wanneer die na de Offline Opruiming van de Revisie in werking wordt gesteld?

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.

Zouden Auteur en Publiceren typisch verschillende Online vensters van de Overgang van de Herziening hebben? 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-publicatie-instanties (TarMK Farm) moeten de onderhoudsvensters voor Online revisie Cleanup worden gefaseerd.
Zijn er om het even welke eerste vereisten alvorens Online de Opruiming van de Revisie in werking te stellen?

Online Revision Cleanup is alleen beschikbaar bij AEM 6.3 en hoger. Als u een oudere versie van AEM gebruikt, moet u ook migreren naar de nieuwe eiken segmentteer.

Wat zijn de factoren die de duur van de Online Opruiming van de Revisie bepalen? De factoren zijn:
  • Grootte opslagplaats
  • Laden op het systeem (aanvragen per minuut, schrijven specifiek bewerkingen)
  • Activiteitspatroon (lezen versus schrijven)
  • Hardwarespecificaties (CPU-prestaties, geheugen, IOPS)
Kunnen auteurs nog steeds werken terwijl Online revisie Cleanup wordt uitgevoerd? Ja, Online Revision Cleanup kan gelijktijdige schrijvingen verwerken. Onlinerevisie opschonen werkt echter sneller en efficiënter zonder gelijktijdige schrijftransacties. Het wordt geadviseerd om de Online het onderhoudstaak van de Opruiming van de Revisie aan een vrij rustige tijd zonder veel verkeer te plannen.
Wat zijn de minimumvereisten voor schijfruimte en heapgeheugen wanneer het runnen van Online Herziening Opschoning?

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.

Wat is het verwachte effect op de prestaties tijdens het uitvoeren van Online Revision Cleanup? 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 korte tijd exclusieve toegang tot de opslagplaats te verkrijgen, zodat andere draden niet naar de opslagplaats kunnen schrijven.
Hoe lang wordt de Online Correctie van de Revisie verwacht om te lopen? Het mag niet langer dan twee uur duren voordat de uitvoering plaatsvindt volgens de laatste prestatietests die we intern hebben uitgevoerd.
Wat moet u doen als het opruimen van online revisies langer duurt?
  • 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.
Wat gebeurt als de Online Opruiming van de Revisie gevormde Vensters van het Onderhoud overschrijdt? 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. Merk op dat de onderhoudstaken opeenvolgend zonder een configureerbare orde worden uitgevoerd.
Waarom wordt afvalophaling overgeslagen?

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
Is het mogelijk om de automatische compressie veilig af te breken als de invloed op de prestaties te groot is? Ja. Sinds AEM 6.3 kan het veilig worden tegengehouden via het venster Onderhoudstaken binnen het vluchthandboek of via JMX.
Als de AEM instantie tijdens een geplande opschoontaak wordt afgesloten, veilig afbreekt het proces, of wordt de sluiting geblokkeerd tot de compensatie heeft gebeëindigd? Revision Cleanup wordt onderbroken en de repository wordt veilig afgesloten.
Wat gebeurt er als het systeem vastloopt tijdens het opschonen van de online revisie? In dergelijke gevallen bestaat er geen risico op gegevensbeschadiging. De afvalrestanten worden opgeschoond door een volgende run.
Wat is de impact van het niet uitvoeren van Online Revision Cleanup? Verslechtering van prestaties in de loop der tijd.
Welke herzieningen worden verzameld? Standaard verzamelt de Online revisie-opruiming alleen revisies die minstens 24 uur oud zijn.
Wat gebeurt er in het geval van te veel interferentie van gelijktijdig schrijven naar de dataopslag?

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.

Hoe wordt de Online Opruiming van de Revisie uitgevoerd op een reserve instantie?

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.

Kan offlinerevisie opschonen meer schijfruimte vrijmaken dan online revisie opschonen?

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.

Eventuele overwegingen met betrekking tot bestandsbewerkingen die zijn toegewezen aan het geheugen?
  • Windows-omgevingenRegelmatige 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.

Onlinerevisie controleren

Wat moet worden gecontroleerd tijdens Online Revision Cleanup?
  • 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.
Hoe te om te controleren als Online Correctie van de Revisie met succes heeft voltooid?

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.

Waar kunnen wij de statistieken van de laatste Online Uitvoeren van de Herziening vinden?

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.

Wat zijn relevante logbestandvermeldingen?
  • 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.

Hoe te om te controleren hoeveel ruimte werd teruggewonnen nadat de Online Opschoning van de Revisie heeft voltooid? Er staat een bericht in het logbestand aan het einde van de opschooncyclus: "TarMK GC #3: cleanup completed" die de grootte van de opslagplaats en de hoeveelheid geregenereerd afval omvat.
Hoe kan de integriteit van de opslagplaats worden gecontroleerd nadat de Online Revision Cleanup is voltooid?

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.
Hoe te om te ontdekken als de Online Opruiming van de Revisie heeft ontbroken en welke stappen zijn om te herstellen? De voorwaarden van de mislukking worden duidelijk door WARN of FOUTlogboekberichten die met "TarMK GC"beginnen. Zie ook de Problemen oplossen op basis van foutberichten hieronder.
Welke informatie wordt in de Controle van de Gezondheid van de Reinigingscontrole van de Revisie blootgesteld? Hoe en wanneer dragen ze bij aan de statusniveaus van de kleurcodering?

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.

Hoe te om Automatische Opschoning op een reserve instantie te controleren?

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.

Wat moet tijdens Automatische Opschoning op een reserve instantie worden gecontroleerd?

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

Oplossen van problemen met online revisie

Wat is het ergste dat kan gebeuren als u de Online Opruiming van de Revisie niet in werking stelt? De AEM instantie zal uit schijfruimte lopen, die stroomonderbrekingen in productie zal veroorzaken.
Is het hoge gebruikersverkeer problematisch voor het runnen van Online Opruiming van de Revisie op een publicatieinstantie? Het hoge gebruikersverkeer beïnvloedt of de samenstellingsfase met succes kan voltooien of niet.
Volgens de Health Check en de logbestandvermeldingen is de Online Revision Cleanup niet driemaal achter elkaar voltooid. Wat is vereist om het opruimen van online revisie met succes te voltooien? 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.
Wat moet er gebeuren als het alarm voor de health check is ingeschakeld? Zie het vorige punt.
Wat gebeurt er als de Online Opruiming van de Revisie uit tijd tijdens het geplande onderhoudsvenster loopt? De Online revisie-opschoning wordt geannuleerd en de restanten worden verwijderd. De volgende keer dat het onderhoudsvenster is gepland, wordt het programma opnieuw gestart.
Wat veroorzaakt SegmentNotFoundException instanties die moeten worden aangemeld bij de error.log en hoe kan ik herstellen?

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.

Problemen oplossen op basis van foutberichten

Error.log zal uitgebreid zijn als er incidenten tijdens het online herzieningsproces schoonmaakbeurt zijn. De volgende matrix is bedoeld om de meest voorkomende boodschappen uit te leggen en mogelijke oplossingen te bieden:

Fase Logberichten Toelichting Volgende stappen
Schatting TarMK GC #2: Schatting overgeslagen omdat de compressie is gepauzeerd De schattingsfase wordt overgeslagen wanneer de compressie op het systeem door configuratie wordt onbruikbaar gemaakt. Onlinerevisie opschonen inschakelen.
TarMK GC #2: Schatting onderbroken: ${REASON}. Compressie wordt overgeslagen. De schattingsfase liep voortijdig af. Enkele voorbeelden van gebeurtenissen die de schattingsfase kunnen onderbreken: onvoldoende geheugen of schijfruimte op het hostsysteem. Afhankelijk van de gegeven reden.
Compactie TarMK GC #2: verdichting gepauzeerd Zolang de samenstellingsfase door configuratie wordt gepauzeerd, noch zal de ramingsfase noch de samenstellingsfase worden uitgevoerd. Opschonen van online revisie inschakelen.
TarMK GC #2: verdichting geannuleerd: ${REASON}. De samenstellingsfase eindigde voortijdig. Enkele voorbeelden van gebeurtenissen die de compactiefase kunnen onderbreken: onvoldoende geheugen of schijfruimte op het hostsysteem. Bovendien kan de vereffening ook worden geannuleerd door het systeem te sluiten of door het expliciet te annuleren via administratieve interfaces zoals het onderhoudvenster binnen de operatiedashobard. Afhankelijk van de gegeven reden.
TarMK GC #2: Verwerking mislukt in 32,902 min (1974140 ms), na 5 cycli Dit bericht betekent niet dat er een onherstelbare fout is opgetreden, maar alleen dat de compensatie na een bepaalde hoeveelheid pogingen is beëindigd. Lees ook de volgende alinea. Lees het volgende Oak-documentatieen de laatste vraag van de Onlinerevisie opschonen uitvoeren sectie.
Overbodig verwijderen TarMK GC #2: opruiming onderbroken Opruiming is geannuleerd door de opslagplaats te sluiten. Er wordt geen invloed op de consistentie verwacht. Bovendien wordt de schijfruimte hoogstwaarschijnlijk niet volledig vrijgemaakt. Deze wordt teruggewonnen tijdens de volgende opschoningscyclus van de revisie. Onderzoek waarom de opslagplaats is afgesloten en probeer in de toekomst te voorkomen dat de opslagplaats tijdens onderhoudsvensters wordt afgesloten.

Offline revisie opschonen uitvoeren

LET OP

Afhankelijk van de eikenversie die u gebruikt bij de installatie van de AEM, moeten verschillende versies van het gereedschap voor het uitvoeren van de eek worden gebruikt. Controleer de onderstaande lijst met versievereisten voordat u het gereedschap gebruikt:

  • Voor eiken-versies 1.0.0 tot en met 1.0.11 of 1.1.0 tot en met 1.1.6, gebruik Oak-run versie ​ 1.0.11

  • Voor eiken-versies nieuwer dan bovenstaande, gebruikt u de versie van de eik-run die overeenkomt met de eik-kern van de AEM-installatie.

Adobe biedt een hulpprogramma met de naam Eak-run voor het uitvoeren van revisie opschonen. U kunt het downloaden op de volgende locatie:

https://repo1.maven.org/maven2/org/apache/jackrabbit/oak-run/

Het hulpmiddel is een runnable pot die manueel kan worden in werking gesteld om de bewaarplaats te comprimeren. Het proces wordt genoemd off-line revisie schoonmaakbeurt omdat de bewaarplaats moet worden gesloten om het hulpmiddel behoorlijk in werking te stellen. Zorg ervoor dat u de opschoonbewerking plant in overeenstemming met uw onderhoudspad.

Voor tips over het verbeteren van de prestaties van het opschoningsproces raadpleegt u De prestaties van opschonen van offlinerevisie verhogen.

OPMERKING

U kunt ook oude controlepunten wissen voordat het onderhoud plaatsvindt (stappen 2 en 3 in de onderstaande procedure). Dit wordt alleen aanbevolen voor instanties met meer dan 100 controlepunten.

  1. Zorg altijd dat u een recente back-up van de AEM hebt.

    Sluit AEM af.

  2. (Optioneel) Gebruik het gereedschap om oude controlepunten te zoeken:

    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore
    
  3. (Optioneel) Verwijder vervolgens de controlepunten waarnaar niet wordt verwezen:

    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore rm-unreferenced
    
  4. Voer de compressie uit en wacht tot deze is voltooid:

    java -jar -Dsun.arch.data.model=32 oak-run.jar compact install-folder/crx-quickstart/repository/segmentstore
    

De prestaties van opschonen van offlinerevisie verhogen

Het gereedschap voor het uitvoeren van een eikenhout bevat verschillende functies die tot doel hebben de prestaties van het opschonen van de revisie te verbeteren en het onderhoudsvenster zoveel mogelijk te minimaliseren.

De lijst bevat verschillende opdrachtregelparameters, zoals hieronder wordt beschreven:

  • -mmap. U kunt deze waarde instellen op true of false. Indien ingesteld op true, wordt toegewezen toegang tot het geheugen gebruikt. Indien ingesteld op false, wordt bestandstoegang gebruikt. Indien niet gespecificeerd, wordt de geheugen in kaart gebrachte toegang gebruikt op systemen met 64 bits en de dossiertoegang wordt gebruikt op systemen met 32 bits. In Windows wordt de reguliere bestandstoegang altijd afgedwongen en wordt deze optie genegeerd. Deze parameter heeft de parameter -Dtar.memoryMapping vervangen.

  • -Dupdate.limit. Bepaalt de drempel voor het spoelen van een tijdelijke transactie aan schijf. De standaardwaarde is 10000.

  • -Dcompress-interval. Het aantal items in de compactiekaart dat behouden moet blijven totdat de huidige kaart wordt gecomprimeerd. De standaardwaarde is 1000000. U zou deze waarde aan een nog hoger aantal voor snellere productie moeten verhogen, als genoeg heapgeheugen beschikbaar is. Deze parameter is verwijderd uit Oak versie 1.6 en heeft geen effect.

  • -Dcompaction-progress-log. Het aantal gecomprimeerde knooppunten dat wordt geregistreerd. De standaardwaarde is 150000, wat betekent dat de eerste 150000 samengeperste knopen tijdens de verrichting zullen worden geregistreerd. Gebruik dit in combinatie met de volgende parameter die hieronder wordt beschreven.

  • -Dtar.PersistCompactionMap. Stel deze parameter in op true als u schijfruimte wilt gebruiken in plaats van heapgeheugen voor de persistentie van de compactietoewijzing. Vereist het gereedschap voor het uitvoeren van een eiken versie 1.4 en hoger. Zie vraag 3 in de Offline revisie opschonen Veelgestelde vragen sectie. Deze parameter is verwijderd uit Oak versie 1.6 en heeft geen effect.

  • —kracht. Drijf compensatie en negeer een niet passende versie van de segmentopslag.

LET OP

Met de --force de parameter zal de segmentopslag aan de recentste versie bevorderen, die met oudere versies van het Eak onverenigbaar is. Houd er ook rekening mee dat een downgrade niet mogelijk is. Als algemene regel, zou u deze parameters met voorzichtigheid en slechts moeten gebruiken als u kennis over hoe te om hen te gebruiken bent.

Een voorbeeld van de gebruikte parameters:

java -Dupdate.limit=10000 -Dcompaction-progress-log=150000 -Dlogback.configurationFile=logback.xml -Xmx8g -jar oak-run-*.jar checkpoints <repository>

Aanvullende methoden voor het opschonen van revisies

Naast de hierboven vermelde methodes, kunt u het mechanisme van de revisieschoonmaakbeurt ook teweegbrengen door de console te gebruiken JMX als volgt:

  1. Open de JMX-console door naar http://localhost:4502/system/console/jmx
  2. Klik op de knop RevisionGarbageCollection MBean.
  3. Klik in het volgende venster op startRevisionGC() en vervolgens Invoeden om de baan van de Inzameling van het Afval van de Herziening te beginnen.

Offline revisie opschonen Veelgestelde vragen

Wat zijn de factoren die de duur van de Offline Opruiming van de Revisie bepalen?

De grootte van de opslagplaats en de hoeveelheid revisies die moeten worden opgeschoond, bepalen de duur van de opruiming.

Wat is het verschil tussen een revisie en een paginaversie?
  • 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.
Hoe te om de Offline taak van de Opruiming van de Revisie te versnellen als het niet binnen 8 uur voltooit? Als de revisietaak niet binnen 8 uur wordt voltooid en de schroefdraad tonen dat de hoofdhotspot InMemoryCompactionMap.findEntry, gebruik de volgende parameter met het hulpmiddel van de eikenlooppas versie 1.4 of hoger: -Dtar.PersistCompactionMap=true. Houd er rekening mee dat de -Dtar.PersistCompactionMap parameter is verwijderd uit Oak versie 1.6.

Op deze pagina