Uw AEM controleren en onderhouden monitoring-and-maintaining-your-aem-instance

Nadat uw AEM instanties zijn opgesteld zullen bepaalde taken nodig zijn om hun verrichting, prestaties en integriteit te controleren en te handhaven.

Een belangrijke factor hierbij is dat u, om potentiële problemen te herkennen, moet weten hoe uw systemen er onder normale omstandigheden uitzien en zich gedragen. Dit kan het best worden gedaan door het systeem te controleren en informatie over een bepaalde periode te verzamelen.

Back-ups backups

Het is een goede gewoonte back-ups te maken van:

Uw bedrijf zal waarschijnlijk een reservebeleid hebben dat u zult moeten volgen, extra overwegingen van wat aan steun en wanneer omvatten:

Vaak wordt een volledige back-up gemaakt met regelmatige tussenpozen (bijvoorbeeld dagelijks, wekelijks of maandelijks), met incrementele back-ups tussen (bijvoorbeeld uur, dag of week).

Back-up maken van de software-installatie backing-up-your-software-installation

Maak na de installatie of na belangrijke wijzigingen in de configuratie een back-up van de software-installatie.

Om dit te doen, moet u back-up maken van de gehele opslagplaats en dan:

Back-up maken van uw opslagplaats backing-up-your-repository

De Back-up en herstel in de CRX-documentatie worden alle problemen besproken die te maken hebben met back-ups van de CRX-opslagplaats.

Voor meer informatie over het maken van een online "hot" back-up raadpleegt u Een online back-up maken.

Versie leegmaken version-purging

De Purperen is bedoeld voor het verwijderen van de versies van een knooppunt of een hiërarchie van knooppunten in uw opslagplaats. Het belangrijkste doel is om u te helpen de grootte van uw opslagplaats te verminderen door oude versies van uw knopen te verwijderen.

Deze sectie behandelt onderhoudswerkzaamheden met betrekking tot de versieeigenschap van AEM. De Versie wissen is bedoeld voor het verwijderen van de versies van een knooppunt of een hiërarchie van knooppunten in uw opslagplaats. Het belangrijkste doel is om u te helpen de grootte van uw opslagplaats te verminderen door oude versies van uw knopen te verwijderen.

Overzicht overview

De Purperen is beschikbaar in het dialoogvenster Gereedschappen console krachtens Versioning of rechtstreeks bij:

https://<server>:<port>/etc/versioning/purge.html

Startpad Een absoluut pad waarop moet worden gewist. U kunt het Startpad selecteren door op de boomnavigator in de repository te klikken.

Recursief Bij het wissen van gegevens kunt u kiezen tussen het uitvoeren van de bewerking op één knooppunt of op een hele hiërarchie door Recursive te selecteren. In het laatste geval definieert het opgegeven pad het basisknooppunt van de hiërarchie.

Maximale aantal versies om te behouden Het maximum aantal versies dat voor een knooppunt moet worden bewaard. Wanneer dit getal deze waarde overschrijdt, worden de oudste versies gewist.

Maximale versieleeftijd De maximumleeftijd van de versie van een knooppunt. Wanneer de leeftijd van een versie deze waarde overschrijdt, wordt het leeggemaakt.

Droog Omdat het verwijderen van versies van uw inhoud definitief is en niet kan worden hersteld zonder een back-up te herstellen, biedt het gereedschap Versies wissen een modus voor droog uitvoeren waarmee u een voorvertoning van de gezuiverde versies kunt weergeven. Klik op Droog uitvoeren om een droge run van het zuiveringsproces te starten.

Leegmaken Start het leegmaken van de versies op het knooppunt dat wordt gedefinieerd door het beginpad.

Versies van een website wissen purging-versions-of-a-web-site

Ga als volgt te werk om versies van een website te wissen:

De console analyseren analyzing-the-console

De Droog en Leegmaken in processen worden alle knooppunten weergegeven die zijn verwerkt. Tijdens het proces, kan een knoop één van de volgende status hebben:

Bovendien verstrekt de console nuttige informatie over de versies:

In het volgende voorbeeld:

Werken met auditrecords en logbestanden working-with-audit-records-and-log-files

Op verschillende plaatsen zijn controledossiers en logbestanden met betrekking tot Adobe Experience Manager (AEM) te vinden. Hieronder vindt u een overzicht van waar u kunt vinden.

Werken met logbestanden working-with-logs

AEM WCM registreert gedetailleerde logboeken. Nadat u QuickStart hebt uitpakken en gestart, kunt u logbestanden vinden:

Bestandsrotatie logbestand log-file-rotation

De omwenteling van het dossier van het logboek verwijst naar het proces dat de groei van dossier door nieuw dossier periodiek te creëren beperkt. In AEM wordt een logbestand met de naam error.log eenmaal per dag worden geroteerd volgens de volgende regels:

De logbestanden zoeken finding-the-log-files

Verschillende logbestanden worden opgeslagen op de bestandsserver waarop u AEM hebt geïnstalleerd:

Het FOUTOPSPORINGSlogniveau activeren activating-the-debug-log-level

Het standaardlogniveau Configuratie van Apache Sling-logboekregistratie is Informatie, zodat zuiver berichten niet worden geregistreerd.

Om het debug logboekniveau voor een Logger te activeren, plaats het bezit org.apache.sling.commons.log.level om fouten op te sporen in de opslagplaats. Bijvoorbeeld, aan /libs/sling/config/org.apache.sling.commons.log.LogManager om het global Apache Sling Logging.

Een lijn in zuivert dossier begint gewoonlijk met DEBUG, dan verstrekt het logboekniveau, de installeractie en het logboekbericht. Bijvoorbeeld:

DEBUG 3 WebApp Panel: WebApp successfully deployed

De logniveaus zijn als volgt:

Een aangepast logbestand maken create-a-custom-log-file

In bepaalde omstandigheden wilt u mogelijk een aangepast logbestand met een ander logniveau maken. U kunt dit in de repository doen door:

De Felix-console biedt ook informatie over de ondersteuning voor het verkooplogboek op ../system/console/slinglog; bijvoorbeeld http://localhost:4502/system/console/slinglog.

Controleregisters zoeken finding-the-audit-records

Er worden auditrecords bijgehouden om een overzicht te geven van wie wat heeft gedaan en wanneer. Er worden verschillende auditverslagen gegenereerd voor zowel AEM WCM- als OSGi-gebeurtenissen.

AEM WCM-auditrecords die worden weergegeven bij het ontwerpen van pagina's aem-wcm-audit-records-shown-when-page-authoring

AEM WCM-controlegegevens in de opslagplaats aem-wcm-auditing-records-within-the-repository

Binnen de /var/audit map, worden auditrecords bijgehouden op basis van de bron. U kunt naar beneden boren tot u de individuele verslagen en de informatie kunt zien zij bevatten.

Deze vermeldingen bevatten dezelfde gegevens als bij het bewerken van een pagina.

OSGi-auditrecords van de webconsole osgi-audit-records-from-the-web-console

OSGi-gebeurtenissen genereren ook controlegegevens die kunnen worden afgeleid uit de Configuratiestatus tab -> Logbestanden in de AEM webconsole:

Uw replicatieagents controleren monitoring-your-replication-agents

U kunt uw replicatiewachtrijen om te ontdekken wanneer een rij of neer of geblokkeerd is - die op zijn beurt op een probleem met een het publiceren instantie of extern systeem zou kunnen wijzen:

Om een replicatieagent te controleren:

Opnieuw kunt u een oplossing ontwikkelen om alle replicatieagenten te ontdekken (onder worden gevestigd /etc/replication/author of /etc/replication/publish), controleert u vervolgens de status van de agent ( enabled, disabled) en de onderliggende wachtrij ( active, idle, blocked).

Monitorprestaties monitoring-performance

Optimalisatie van prestaties is een interactief proces dat tijdens de ontwikkeling de nadruk krijgt. Na plaatsing wordt het gewoonlijk herzien na specifieke intervallen of gebeurtenissen.

Methoden die worden gebruikt bij het verzamelen van informatie voor optimalisatie kunnen ook worden gebruikt voor doorlopende bewaking.

Hieronder worden gemeenschappelijke prestatieproblemen opgesomd die zich voordoen, samen met voorstellen voor het opsporen en bestrijden van deze problemen.

Prestatieproblemen kunnen het gevolg zijn van een aantal oorzaken die niets te maken hebben met uw website, zoals tijdelijke vertragingen in de verbindingssnelheid, CPU-belasting en nog veel meer.

Het kan ook gevolgen hebben voor al uw bezoekers of alleen voor een deel ervan.

Al deze informatie moet worden verkregen, gesorteerd en geanalyseerd voordat u de algemene prestaties kunt optimaliseren of specifieke problemen kunt oplossen.

Gereedschappen voor het bewaken en analyseren van prestaties tools-for-monitoring-and-analyzing-performance

Hieronder vindt u een kort overzicht van enkele gereedschappen die beschikbaar zijn voor het bewaken en analyseren van de prestaties.

Sommige hiervan zijn afhankelijk van uw besturingssysteem.

Het interpreteren van request.log interpreting-the-request-log

In dit bestand wordt basisinformatie geregistreerd over elk verzoek aan AEM. Uit deze waardevolle conclusies kunnen we lering trekken.

De request.log biedt een ingebouwde manier om te zien hoe lang verzoeken duren. Voor ontwikkelingsdoeleinden is het nuttig om tail -f de request.log en let op langzame reactietijden. Een groter object analyseren request.log wij bevelen de gebruik van rlog.jar waarmee u kunt sorteren en filteren op responstijden.

We raden u aan om de pagina's met de notatie 'traag' te isoleren van de request.logen deze vervolgens individueel af te stemmen voor betere prestaties. Dit gebeurt meestal door prestatiemetriek per component op te nemen of een hulpmiddel te gebruiken om prestaties te profileren zoals [yourkit](https://www.yourkit.com/).

Bewaking van verkeer op uw website monitoring-traffic-on-your-website

Het aanvraaglogboek registreert elke ingediende aanvraag, samen met het gegeven antwoord:

09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms

Door alle GET-items in een bepaalde periode op te tellen (bijvoorbeeld over verschillende periodes van 24 uur), kunt u instructies geven over het gemiddelde verkeer op uw website.

De reactietijden van de controle met request.log monitoring-response-times-with-the-request-log

Een goed uitgangspunt voor prestatiesanalyse is het verzoeklogboek:

<cq-installation-dir>/crx-quickstart/logs/request.log

Het logbestand ziet er als volgt uit (de regels worden ingekort om het eenvoudig te houden):

31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms

Dit logboek heeft één lijn per verzoek of reactie:

Met behulp van kleine scripts kunt u de vereiste informatie uit het logbestand extraheren en de gewenste statistieken samenstellen. Hieruit kunt u zien welke pagina's of typen pagina's langzaam zijn en of de prestaties over het geheel genomen bevredigend zijn.

De onderzoekreactie tijden van het toezicht met request.log monitoring-search-response-times-with-the-request-log

Zoekverzoeken worden ook in het logbestand geregistreerd:

31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms

Dus, zoals hierboven, kunt u manuscripten gebruiken om de relevante informatie te halen en statistieken op te bouwen.

Als u echter eenmaal de responstijd hebt bepaald, moet u misschien analyseren waarom het verzoek de tijd neemt die het nodig heeft en wat er kan worden gedaan om de reactie te verbeteren.

Het aantal en de gevolgen van gelijktijdige gebruikers controleren monitoring-the-number-and-impact-of-concurrent-users

Opnieuw request.log kan worden gebruikt om de samenhang en de reactie van het systeem daarop te controleren.

Er moeten tests worden uitgevoerd om te bepalen hoeveel gelijktijdige gebruikers het systeem kan verwerken voordat een negatieve invloed wordt waargenomen. Opnieuw kunnen de manuscripten worden gebruikt om resultaten uit het logboekdossier te halen:

31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms

Het gebruiken van rlog.jar om verzoeken met lange duurtijden te vinden using-rlog-jar-to-find-requests-with-long-duration-times

AEM bevat diverse hulpgereedschappen in:
<cq-installation-dir>/crx-quickstart/opt/helpers

Eén van deze rlog.jar, kan worden gebruikt om snel te sorteren request.log zodat verzoeken op duur, van langste tot kortste tijd worden getoond.

De volgende opdracht toont de mogelijke argumenten:

$java -jar rlog.jar
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG
Usage:
  java -jar rlog.jar [options] <filename>
Options:
  -h               Prints this usage.
  -n <maxResults>  Limits output to <maxResults> lines.
  -m <maxRequests> Limits input to <maxRequest> requests.
  -xdev            Exclude POST request to CRXDE.

U kunt bijvoorbeeld de opdracht uitvoeren door request.log bestand als parameter en geef de 10 eerste aanvragen weer die de langste duur hebben:

$ java -jar ../opt/helpers/rlog.jar -n 10 request.log
*Info * Parsed 464 requests.
*Info * Time for parsing: 22ms
*Info * Time for sorting: 2ms
*Info * Total Memory: 1mb
*Info * Free Memory: 1mb
*Info * Used Memory: 0mb
------------------------------------------------------
     18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html
      2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript
      1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html
      1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html
      1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript
      1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
      1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript
      1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
      1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json
      1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8

Mogelijk moet u de afzonderlijke request.log bestanden als u deze bewerking wilt uitvoeren in een groot gegevensvoorbeeld.

Apache Bench apache-bench

Om het effect van speciale gevallen (zoals afvalophaling, enz.) tot een minimum te beperken, wordt aangeraden een hulpmiddel te gebruiken zoals apachebench (zie bijvoorbeeld ab voor verdere documentatie) om geheugenlekken te helpen identificeren en selectief reactietijd te analyseren.

Apache Bench kan als volgt worden gebruikt:

$ ab -c 5 -k -n 1000 "http://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503

Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes

Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106

Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)

De bovenstaande nummers zijn afkomstig van een standaard MAcBook Pro-laptop (medio 2010) die toegang heeft tot de geometrixx-bedrijfspagina, zoals opgenomen in een standaard AEM installatie. De pagina is heel eenvoudig, maar niet geoptimaliseerd voor prestaties.

apachebench geeft ook de tijd per verzoek als gemiddelde, over alle gezamenlijke verzoeken weer; zie Time per request: 54.595 [ms] (gemiddeld over alle gelijktijdige aanvragen). U kunt de waarde van de parameter voor gelijktijdige uitvoering wijzigen -c (aantal meerdere verzoeken om tegelijk uit te voeren) om effecten te zien.

Aanvraagtellers request-counters

De informatie over verzoekverkeer (aantal verzoeken tijdens een specifieke tijdspanne) geeft u een aanwijzing van de lading op uw geval. Deze informatie kan worden afgeleid uit request.log, hoewel het gebruiken van tellers gegevensinzameling zal automatiseren om u te laten zien:

Om informatieinzameling te automatiseren kunt u een RequestFilter ook installeren om een teller op elk verzoek te verhogen. De veelvoudige tellers kunnen voor verschillende tijdsperioden worden gebruikt.

De verzamelde informatie kan worden gebruikt om aan te geven:

Opmerkingen HTML html-comments

Aanbevolen wordt dat elk project html comments voor serverprestaties. Er zijn veel goede openbare voorbeelden te vinden; Selecteer een pagina, open de paginabron voor weergave en schuif naar de onderkant. U ziet bijvoorbeeld de volgende code:

</body>
 </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

Prestaties controleren met behulp van JConsole monitoring-performance-using-jconsole

De opdracht Gereedschap jconsole is beschikbaar bij de JDK.

Prestaties bewaken met behulp van (J)VisualVM monitoring-performance-using-j-visualvm

Sinds JDK 1.6, de hulpmiddelbevel jvisualvm is beschikbaar. Nadat u JDK 1.6 hebt geïnstalleerd, kunt u:

U kunt dit gereedschap gebruiken om thread-dumps en dumps voor geheugenkoppen te maken. Deze informatie wordt vaak gevraagd door het technische ondersteuningsteam.

Informatie verzamelen information-collection

Als u zoveel mogelijk weet wat u met de installatie kunt doen, kunt u nagaan wat een wijziging in de prestaties heeft veroorzaakt en of deze wijzigingen gerechtvaardigd zijn. Deze gegevens moeten regelmatig worden verzameld, zodat u gemakkelijk significante veranderingen kunt zien.

De volgende informatie kan nuttig zijn:

Hoeveel auteurs werken met het systeem? how-many-authors-are-working-with-the-system

Om het aantal auteurs te zien die het systeem sinds installatie hebben gebruikt gebruik de bevellijn:

cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l

Om het aantal auteurs te zien die op een bepaalde datum werken:

grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l

Wat is het gemiddelde aantal paginanavigaties per dag? what-is-the-average-number-of-page-activations-per-day

Om het totale aantal paginanavigaties te zien sinds de serverinstallatie een dataopslagvraag gebruikt; via CRXDE - Hulpmiddelen - Vraag:

Bereken vervolgens het aantal dagen dat is verstreken sinds de installatie om het gemiddelde te berekenen.

Hoeveel pagina's handhaaft u momenteel op dit systeem? how-many-pages-do-you-currently-maintain-on-this-system

Om het aantal pagina's momenteel op de server te zien gebruik een bewaarplaatvraag; via CRXDE - Hulpmiddelen - Vraag:

Als u MSM gebruikt, wat is het gemiddelde aantal rollouts per maand? if-you-use-msm-what-is-the-average-number-of-rollouts-per-month

Om het totale aantal rollouts sinds installatie te bepalen gebruik een bewaarplaatvraag; via CRXDE - Hulpmiddelen - Vraag:

Bereken het aantal maanden dat is verstreken sinds de installatie om het gemiddelde te berekenen.

Wat is het gemiddelde aantal levende exemplaren per maand? what-is-the-average-number-of-live-copies-per-month

Om het totale aantal Actieve Kopieën te bepalen die sinds installatie worden gemaakt gebruikt een bewaarplaatvraag; via CRXDE - Hulpmiddelen - Vraag:

Gebruik opnieuw het aantal maanden dat sinds installatie is verstreken om het gemiddelde te berekenen.

Als u AEM Assets gebruikt, hoeveel middelen handhaaft u momenteel in Middelen? if-you-use-aem-assets-how-many-assets-do-you-currently-maintain-in-assets

Als u wilt zien hoeveel DAM-middelen u momenteel beheert, gebruikt u een query voor de opslagplaats. via CRXDE - Hulpmiddelen - Vraag:

Wat is de gemiddelde omvang van de activa? what-is-the-average-size-of-the-assets

Om de totale grootte van te bepalen /var/dam map:

Hoeveel sjablonen worden momenteel gebruikt? how-many-templates-are-currently-used

Om het aantal malplaatjes momenteel op de server te zien gebruik een bewaarplaatvraag; via CRXDE - Hulpmiddelen - Vraag:

Hoeveel componenten worden momenteel gebruikt? how-many-components-are-currently-used

Om het aantal componenten te zien momenteel op de server gebruik een bewaarplaatvraag; via CRXDE - Hulpmiddelen - Vraag:

Hoeveel verzoeken hebt u per uur op het auteurssysteem op piektijd? how-many-requests-per-hour-do-you-have-on-the-author-system-at-peak-time

Om de verzoeken per uur te bepalen hebt u op het auteurssysteem bij piektijd:

Hoeveel verzoeken per uur hebt u op het publicatiesysteem bij piektijd? how-many-requests-per-hour-do-you-have-on-the-publish-system-at-peak-time

Herhaal de bovenstaande procedure voor uw publicatieexemplaar.

Specifieke scenario's analyseren analyzing-specific-scenarios

Hieronder volgt een lijst met suggesties voor het controleren of er bepaalde prestatieproblemen optreden. De lijst is (helaas) niet volledig.

CPU bij 100% cpu-at

Als de CPU van uw systeem constant op 100% draait, zie dan:

Onvoldoende geheugen out-of-memory

Hoewel dergelijke fouten tijdens de ontwikkeling en het testen moeten worden ontdekt, kunnen bepaalde scenario's door glijden.

Als er onvoldoende geheugen beschikbaar is voor uw systeem, is dit op verschillende manieren zichtbaar, zoals prestatievermindering en foutmeldingen, waaronder de subtekst:

java.lang.OutOfMemoryError

Controleer in deze gevallen:

I/O schijf disk-i-o

Als er onvoldoende schijfruimte beschikbaar is op uw systeem of als u merkt dat de schijf wordt vastgezet, zie:

Reguliere prestatievermindering regular-performance-degradation

Als u ziet dat de prestaties van uw instantie achteruitgaan nadat u opnieuw hebt opgestart (soms een week of meer later), kunt u het volgende controleren:

JVM-tuning jvm-tuning

De JVM (Java Virtual Machine) is aanzienlijk verbeterd op het gebied van tuning (vooral sinds Java 7). Daarom is het vaak handig om een redelijke, vaste JVM-grootte op te geven en de standaardinstellingen te gebruiken.

Als de standaardinstellingen niet geschikt zijn, is het belangrijk een methode vast te stellen om de GC-prestaties te controleren en te beoordelen voordat wordt geprobeerd de JVM af te stemmen. dit kan bestaan uit monitoringfactoren zoals heapgrootte , algoritme en andere aspecten .

Enkele algemene keuzen zijn:

Het resulterende logboek kan door GC visualizer zoals worden opgenomen:

[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)

Of JConsole:

Zo kunt u zien hoeveel geheugen wordt gebruikt, welke GC-algoritmen worden gebruikt, hoe lang het duurt om te werken en welk effect dit heeft op de prestaties van uw toepassing. Zonder dit, is het stemmen enkel "willekeurig het draaien knopen".