Revisie opschonen

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 u Onlinerevisie opschonen kunt gebruiken.

Het opschoningsproces van de revisie bestaat uit drie fasen: Schatting, verdichting en opschonen. 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:

Daarnaast kunt u ook de officiële documentatie van eikenhout lezen.

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-opruiming 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 naar: https://serveraddress:serverport/libs/granite/operations/content/maintenance.html

    chlimage_1-90

  2. Houd de muis boven Dagelijks onderhoud Venster en klik op het pictogram Instellingen.

    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 Dagelijks Onderhoudsvenster.

  3. Houd de muis boven het pictogram Revision Cleanup.

  4. Klik Run.

    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. Dus wanneer u online revisie opschoont after offline revisie opschoont, gebeurt 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.

Compositiemodi

AEM 6.4 introduceert twee nieuwe modellen voor de ​concactionfase van het Online proces van de Overboeking van de Revisie:

  • In de modus volledige compactie worden alle segmenten en teerbestanden in de gehele opslagruimte 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.
  • In de modus tail compaction worden alleen de meest recente segmenten en teerbestanden in de opslagplaats 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 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 full.gc.days van RevisionCleanupTask onderhoudstaak te gebruiken.

Wanneer u de waarde full.gc.days configureert, moet u er rekening mee houden dat de volledige compressie wordt uitgevoerd tijdens 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:

  • De combinatie van staarten is minder effectief en heeft minder invloed op de normale werking van het systeem. Het is dus de bedoeling dat het gedurende werkdagen wordt uitgevoerd.
  • Volledige compatibiliteit 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 geeft de algemene status van de Online revisie-opschoning aan. 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 voor 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:

  • Betere schaalbaarheid (geoptimaliseerde segmentgrootte).
  • Sneller Gegevensopslag opschonen.
  • Grondwerkzaamheden voor toekomstige verbeteringen.
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 eak-segment-teerbewaarplaats (of vice versa) in werking te stellen, zal het opstarten met IllegalStateException met het bericht "Ongeldig segmentformaat"ontbreken. 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 migratieprestaties kunnen zeer worden verbeterd als off-line revisie schoonmaak voorafgaand 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.

Online revisie-opruiming 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 Online Revision Cleanup sectie uitvoeren.
Is er een maximumfrequentie die niet mag worden overschreden voor Online revisie-opschoning? Het wordt geadviseerd om Online Opruiming van de Revisie eenmaal per dag in werking te stellen, zoals die door gebrek wordt gevormd.
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-opruiming 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. Ook, als u een oudere versie van AEM gebruikt moet u aan nieuwe Oak Segment Tar migreren.

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 compaction
  • Revision GC wordt not uitgevoerd: De delta van de grootte is N% of N/N (N/N bytes), zo slaat compensatie voor nu 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 in forceCompact wijze, zoals meer gedetailleerd in eikedocumentatie wordt verklaard. 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-opruiming uitvoeren na offlinerevisie-opruiming" van dit hoofdstuk.

Eventuele overwegingen met betrekking tot bestandsbewerkingen die zijn toegewezen aan het geheugen?
  • In Windows-omgevingen wordt de reguliere bestandstoegang altijd afgedwongen, zodat in geheugen toegewezen 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.
  • In andere omgevingen dan Windows vergroot u het fysieke geheugen om de geheugentoewijzing van de opslagplaats te verbeteren.

Onlinerevisie-opruiming 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 samenstellingsstap tenzij voorafgegaan door het bericht "TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles", wat betekent er teveel gezamenlijke lading was.

Er is dus een bericht "TarMK GC #{}: cleanup completed in {} ({} ms" om de opschoonstap met succes te voltooien.

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

De status, de vooruitgang en de statistieken worden blootgesteld via JMX (SegmentRevisionGarbageCollection MBean). Lees voor meer informatie over de SegmentRevisionGarbageCollection MBean de volgende alinea.

De vooruitgang kan via het EstimatedRevisionGCCompletion attribuut van worden gevolgd 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 documentatie van het AEM voor het vastmaken van gezondheidscontroles aan Nagios als voorbeeld voor een extern controlehulpmiddel.

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 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 "TarMK 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 schoonmaakfase 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 onderstaande sectie Problemen oplossen op basis van foutberichten.

Hoe te om te controleren hoeveel ruimte werd teruggewonnen nadat de Online Opruiming van de Revisie heeft voltooid? Er staat een bericht in het logbestand aan het einde van de opschooncyclus: "TarMK GC #3: cleanup completed" dat de grootte van de opslagplaats en de hoeveelheid geregenereerd huisvuil 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:

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 onderstaande sectie Problemen oplossen op basis van foutberichten.
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 het Operations-dashboard.

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

Het zal YELLOW zijn als de Online het onderhoudstaak van de Opruiming van de Revisie eens werd geannuleerd.

Het zal RED zijn als de Online het onderhoudstaak van de Opruiming van de Revisie driemaal in een rij werd geannuleerd. In dit geval is handmatige interactie vereist of kan het opschonen van de online revisie waarschijnlijk opnieuw mislukken. Lees de onderstaande sectie Problemen oplossen voor meer informatie.

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 documentatie van het AEM voor het vastmaken van gezondheidscontroles aan Nagios als voorbeeld voor een extern controlehulpmiddel.

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

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

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

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

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-opruiming

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 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 forceCompact cyclus tonen, plant het onderhoudsvenster aan een stil tijd wanneer de hoeveelheid opbergingsbericht laag is. U kunt controleren of de gegevensopslagruimte schrijft in het hulpprogramma voor de bewaking van statistische gegevens in de repository dat zich bevindt 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 om worden het programma geopend error.log en hoe kan ik terugkrijgen?

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 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 de volgende Apache-documentatie voor meer informatie over het uitvoeren van de controle tijdens het gebruik van het eiken.
  3. Alle andere gevallen 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 de volgende Oak-documentatie en de laatste vraag van de sectie Online revisie opschonen uitvoeren.
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:

  • Gebruik voor eik-versies 1.0.0 tot en met 1.0.11 of 1.1.0 tot en met 1.1.6 een eekuitvoerversie ​ 1.0.11

  • Voor eikenversies nieuwer dan het 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 Oak-run voor het uitvoeren van het opschonen van revisies. 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.

Zie De prestaties van offlinerevisie opschonen verhogen voor tips over het verbeteren van de prestaties van het opschonen van de revisie.

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 het 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 werktuig versies 1.4 en hoger. Zie vraag 3 in de sectie Offline revisie opschonen Veelgestelde vragen voor meer informatie. 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

Als u de parameter --force gebruikt, wordt de segmentopslag bijgewerkt naar de nieuwste versie, die niet compatibel is met oudere Oak-versies. 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 triggeren van Revision Cleanup

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 te gaan
  2. Klik RevisionGarbageCollection MBean.
  3. Klik in het volgende venster op startRevisionGC() en Invoke om de Revision Garbage Collection-taak te starten.

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?
  • Eak-revisie: Met Eak ordent u alle inhoud in een grote boomstructuur die bestaat uit knooppunten en eigenschappen. 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 Werken met paginaversies voor meer informatie.
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 thread dumps onthullen dat de hoofdhotspot InMemoryCompactionMap.findEntry is, gebruikt u de volgende parameter met het gereedschap versies 1.4 of hoger: -Dtar.PersistCompactionMap=true. Houd er rekening mee dat de parameter -Dtar.PersistCompactionMap is verwijderd uit Oak versie 1.6.

Op deze pagina