Övervaka och underhålla AEM monitoring-and-maintaining-your-aem-instance

CAUTION
AEM 6.4 har nått slutet på den utökade supporten och denna dokumentation är inte längre uppdaterad. Mer information finns i teknisk supportperiod. Hitta de versioner som stöds här.

När AEM har distribuerats behövs vissa uppgifter för att övervaka och underhålla deras åtgärder, prestanda och integritet.

En nyckelfaktor här är att för att identifiera potentiella problem måste du veta hur dina system ser ut och beter sig under normala förhållanden. Detta görs bäst genom att övervaka systemet och samla in information över en tidsperiod.

Kontrollera
Överväganden
Kommentar/åtgärder
Planen för säkerhetskopiering.
Se hur man Säkerhetskopiera instansen.
plan för katastrofåterställning.
Företagets riktlinjer för katastrofåterställning.
Det finns ett felspårningssystem för rapportering av problem.
Till exempel: bugzilla, jiraeller någon av många andra.
Filsystemen övervakas.
CRX-databasen "fryser" om det inte finns tillräckligt med ledigt diskutrymme. Den återupptas när det finns utrymme tillgängligt.
" *ERROR* LowDiskSpaceBlocker-meddelanden kan visas i loggfilen när det lediga utrymmet börjar ta slut.
Loggfiler övervakas.
Systemövervakning körs kontinuerligt i bakgrunden.
Inklusive processor-, minnes-, disk- och nätverksanvändning. Med exempelvis iostat / vmstat / permon.
Loggade data visas och kan användas för att spåra prestandaproblem. Rådata är också tillgängliga.
AEM prestanda övervakas.
Inklusive Begäranräknare övervaka trafiknivåerna.
Om en betydande eller långsiktig förlust av resultat konstateras bör en detaljerad undersökning göras.
Du övervakar dina Replikeringsagenter.
Rensa arbetsflödesinstanser regelbundet.
Databasstorlek och arbetsflödets prestanda.
Se Vanlig tömning av arbetsflödesinstanser.

Säkerhetskopior backups

Det är god praxis att säkerhetskopiera

  • Programvaruinstallationen - före/efter viktiga ändringar i konfigurationen
  • Innehållet i databasen - regelbundet

Företaget kommer förmodligen att ha en säkerhetskopieringsprincip som du måste följa, ytterligare överväganden om vad som ska säkerhetskopieras och när inkluderar:

  • hur viktigt systemet och data är.
  • hur ofta ändringar görs i antingen programvaran eller data.
  • datavolym, kapacitet kan ibland vara ett problem, liksom den tid som behövs för att utföra säkerhetskopieringen.
  • huruvida din säkerhetskopiering kan göras medan användarna är online; och, om möjligt, vilken är prestandapåverkan.
  • användarnas geografiska utbredning, d.v.s. när är det bästa tillfället att säkerhetskopiera (för att minimera påverkan)?
  • din återställningspolicy, Det finns riktlinjer för var säkerhetskopierade data ska lagras (t.ex. utanför platsen, ett visst medium).

Ofta utförs en fullständig säkerhetskopiering med regelbundna intervall (t.ex. dagligen, veckovis eller månadsvis), med inkrementella säkerhetskopieringar mellan (t.ex. varje timme, dag eller vecka).

CAUTION
När du implementerar säkerhetskopieringar av produktionsinstanser, testar måste bör göras för att säkerställa att säkerhetskopian kan återställas.
Utan detta kan säkerhetskopieringen vara oanvändbar (värsta scenariot).
NOTE
Mer information om prestanda för säkerhetskopiering finns i Säkerhetskopieringsprestanda -avsnitt.

Säkerhetskopiera programvaruinstallationen backing-up-your-software-installation

När installationen är klar, eller om konfigurationen har ändrats på ett betydande sätt, gör du en säkerhetskopia av programvaruinstallationen.

För att göra detta måste du säkerhetskopiera hela databasen och sedan:

  1. Sluta AEM.
  2. Säkerhetskopiera hela <cq-installation-dir> från filsystemet.
CAUTION
Om du använder en programserver från en annan tillverkare kan ytterligare mappar finnas på en annan plats och behöver också säkerhetskopieras. Se Installera AEM med en programserver om du vill ha information om hur du installerar programservrar.
CAUTION
Inkrementell säkerhetskopiering av fillagringen stöds. När du använder stegvis säkerhetskopiering för andra komponenter (till exempel Lucene-index) måste du se till att borttagna filer också markeras som borttagna i säkerhetskopian.
NOTE
Diskspegling kan också användas som en säkerhetskopieringsmekanism.

Säkerhetskopiera databasen backing-up-your-repository

The Säkerhetskopiering och återställning i CRX-dokumentationen täcker alla problem som rör säkerhetskopiering av CRX-databasen.

Mer information om hur du gör en "hot"-säkerhetskopiering online finns i Skapa en onlinesäkerhetskopiering.

Rensning av version version-purging

The Rensa versioner är avsett för att rensa versioner av en nod eller en hierarki av noder i din databas. Dess främsta syfte är att hjälpa dig att minska storleken på databasen genom att ta bort tidigare versioner av dina noder.

I det här avsnittet behandlas underhållsåtgärder som rör versionsfunktionen i AEM. The Rensa version är avsett för att rensa versioner av en nod eller en hierarki av noder i din databas. Dess främsta syfte är att hjälpa dig att minska storleken på databasen genom att ta bort tidigare versioner av dina noder.

Översikt overview

The Rensa versioner finns i verktyg konsol under Versionshantering eller direkt på

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

screen_shot_2012-03-15at14418pm

Startbana En absolut väg som rensningen måste göras på. Du kan välja Startsökväg genom att klicka på databasträdnavigatören.

Rekursiv När du rensar data kan du välja mellan att utföra åtgärden på en nod eller på en hel hierarki genom att välja Rekursiv. I det sista fallet definierar den angivna sökvägen rotnoden i hierarkin.

Högsta antal versioner att behålla Det högsta antalet versioner som kan behållas för en nod. När de här siffrorna överskrider det här värdet rensas de äldsta versionerna.

Högsta versionsålder Högsta ålder för en nods version. När en versions ålder överskrider det här värdet rensas den.

Torr körning Eftersom borttagning av versioner av ditt innehåll är definierat och inte kan återställas utan att du återställer en säkerhetskopia har verktyget Rensa versioner ett torrt körningsläge som gör att du kan förhandsgranska rensade versioner. Klicka på Torr körning om du vill starta en torr tömningsprocess.

Rensa Starta rensningen av versionerna på noden som definieras av startsökvägen.

Rensa versioner av en webbplats purging-versions-of-a-web-site

Så här rensar du versioner av en webbplats:

  1. Navigera till verktyg konsol, markera Versionshantering och dubbelklicka Rensa versioner.

  2. Ange startsökvägen för innehållet som ska rensas (t.ex. /content/geometrixx-outdoors).

    • Om du bara vill rensa den nod som definieras av sökvägen avmarkerar du Rekursiv.
    • Om du vill rensa noden som definieras av din sökväg och dess underordnade ska du markera Rekursiv.
  3. Ange maximalt antal versioner (för varje nod) som du vill behålla. Lämna tomt om du inte vill använda den här inställningen.

  4. Ange den maximala versionsåldern i dagar (för varje nod) som du vill behålla. Lämna tomt om du inte vill använda den här inställningen.

  5. Klicka Torr körning för att förhandsgranska vad rensningsprocessen skulle göra.

  6. Klicka Rensa för att starta processen.

CAUTION
Det går inte att återställa rensade noder utan att återställa databasen. Du bör ta hand om konfigurationen, så vi rekommenderar att du alltid utför en torr körning innan du tömmer den.

Analyserar konsolen analyzing-the-console

The Torr körning och Rensa I visas alla noder som har bearbetats. Under processen kan en nod ha någon av följande status:

  • ignore (not versionnable): noden stöder inte versionshantering och ignoreras under processen.
  • ignore (no version): noden har ingen version och ignoreras under processen.
  • retained: noden rensas inte.
  • purged: noden rensas.

Konsolen ger dessutom användbar information om versionerna:

  • V 1.0: versionsnumret.
  • V 1.0.1*: stjärnan anger att versionen är den aktuella.
  • Thu Mar 15 2012 08:37:32 GMT+0100: datum för versionen.

I nästa exempel:

  • The Shirts versionerna rensas eftersom versionsåldern är större än 2 dagar.
  • The Tonga Fashions! versionerna rensas eftersom deras antal versioner är större än 5.

global_version_screenshot

Arbeta med granskningsposter och loggfiler working-with-audit-records-and-log-files

Granskningsposter och loggfiler för Adobe Experience Manager (AEM) finns på olika platser. Här följer en översikt över vad du kan hitta.

Arbeta med loggar working-with-logs

AEM WCM registrerar detaljerade loggar. När du har packat upp och startat Quickstart hittar du loggar in:

  • <cq-installation-dir>/crx-quickstart/logs/
  • <cq-installation-dir>/crx-quickstart/repository/

Rotation av loggfil log-file-rotation

Rotation av loggfiler avser den process som begränsar filens tillväxt genom att skapa nya filer med jämna mellanrum. I AEM anropas en loggfil error.log roteras en gång om dagen enligt följande regler:

  • The error.log filen byter namn enligt mönstret {original_filename} .yyyy-MM-dd. Den aktuella loggfilen får till exempel ett nytt namn den 11 juli 2010 error.log-2010-07-10, sedan en ny error.og skapas.
  • Tidigare loggfiler tas inte bort, så det är ditt ansvar att regelbundet rensa gamla loggfiler för att begränsa diskanvändningen.
NOTE
Om du uppgraderar AEM kommer alla befintliga loggfiler som inte längre används av AEM att finnas kvar på disken. Du kan ta bort dem utan risk. Alla nya loggposter skrivs i de nya loggfilerna.

Hitta loggfilerna finding-the-log-files

Olika loggfiler finns på den filserver där du installerade AEM:

  • <cq-installation-dir>/crx-quickstart/logs

    • access.log

      Alla åtkomstbegäranden till AEM WCM och databasen registreras här.

    • audit.log

      Modereringsåtgärder registreras här.

    • error.log

      Felmeddelanden (av varierande allvarlighetsgrad) registreras här.

    • ImageServer-<PortId>-yyyy>-<mm>-<dd>.log

      Den här loggen används bara om dynamiska medier är aktiverade. Det innehåller statistik och analysinformation som används för att analysera beteendet i den interna ImageServer-processen.

    • request.log

      Varje åtkomstbegäran registreras här tillsammans med svaret.

    • s7access-<yyyy>-<mm>-<dd>.log

      Den här loggen används bara om dynamiska medier är aktiverade. s7access-loggen registrerar varje begäran som görs till Dynamic Media via /is/image och /is/content.

    • stderr.log

      Innehåller felmeddelanden, återigen av varierande allvarlighetsgrad, som genereras under start. Som standard är loggnivån inställd på Warning ( WARN)

    • stdout.log

      Innehåller loggningsmeddelanden som anger händelser under start.

    • upgrade.log

      Tillhandahåller en logg över alla uppgraderingsåtgärder som körs från com.day.compat.codeupgrade och com.adobe.cq.upgradesexecutor paket.

  • <cq-installation-dir>/crx-quickstart/repository

    • revision.log

      Information om revideringsjournaler.

NOTE
ImageServer- och s7access-loggarna ingår inte i Ladda ned fullständig paket som genereras från system/console/status-Bundlelist sida. Om du har problem med Dynamic Media bör du av supportskäl även bifoga loggarna för ImageServer och s7access när du kontaktar kundsupport.

Aktivera felsökningsloggnivån activating-the-debug-log-level

Standardloggnivån Konfiguration av Apache Sling-loggning är Information, så felsökningsmeddelanden loggas inte.

Om du vill aktivera felsökningsloggnivån för en loggare anger du egenskapen org.apache.sling.commons.log.level för att felsöka i databasen. På /libs/sling/config/org.apache.sling.commons.log.LogManager för att konfigurera global Apache Sling Logging.

CAUTION
Lämna inte loggen på felsökningsloggnivån längre än nödvändigt eftersom den genererar många loggposter och förbrukar därmed resurser.

En rad i felsökningsfilen börjar oftast med DEBUG och anger sedan loggnivån, installationsåtgärden och loggmeddelandet. Till exempel:

DEBUG 3 WebApp Panel: WebApp successfully deployed

Loggnivåerna är följande:

0
Allvarligt fel
Åtgärden misslyckades och installationsprogrammet kan inte fortsätta.
1
Fel
Åtgärden misslyckades. Installationen fortsätter, men en del av AEM WCM installerades inte korrekt och kommer inte att fungera.
2
Varning
Åtgärden har slutförts men problem uppstod. AEM WCM kanske inte fungerar som det ska.
3
Information
Åtgärden har slutförts.

Skapa en anpassad loggfil create-a-custom-log-file

NOTE
När du arbetar med Adobe Experience Manager finns det flera metoder för att hantera konfigurationsinställningarna för sådana tjänster. se Konfigurerar OSGi om du vill ha mer information och rekommenderade rutiner.

I vissa fall kanske du vill skapa en anpassad loggfil med en annan loggnivå. Du kan göra detta i databasen genom att:

  1. Om den inte redan finns skapar du en ny konfigurationsmapp ( sling:Folder) för ditt projekt /apps/<project-name>/config.

  2. Under /apps/<project-name>/config, skapa en nod för den nya Konfiguration av loggningsloggare för Apache Sling:

    • Namn:

    org.apache.sling.commons.log.LogManager.factory.config-<identifier> (eftersom detta är en loggare)

    Plats <identifier> ersätts med fri text som du (måste) anger för att identifiera instansen (du kan inte utelämna den här informationen). Till exempel, org.apache.sling.commons.log.LogManager.factory.config-MINE

    • Typ: sling:OsgiConfig
    note note
    NOTE
    Även om det inte är ett tekniskt krav är det tillrådligt att <identifier> unika.
  3. Ange följande egenskaper för den här noden:

    • Namn: org.apache.sling.commons.log.file

      Typ: Sträng

      Värde: Ange loggfilen. till exempel logs/myLogFile.log

    • Namn: org.apache.sling.commons.log.names

      Typ: String[] (String + Multi)

      Värde: Ange de OSGi-tjänster som loggningsmeddelanden ska användas för. till exempel alla följande:

      • org.apache.sling
      • org.apache.felix
      • com.day
    • Namn: org.apache.sling.commons.log.level

      Typ: Sträng

      Värde: ange den loggnivå som krävs ( debug, info, warn eller error). till exempel debug

    • Konfigurera de andra parametrarna efter behov:

      • Namn: org.apache.sling.commons.log.pattern

        Typ: String

        Värde: Ange loggmeddelandets mönster efter behov. till exempel

        {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}

    note note
    NOTE
    org.apache.sling.commons.log.pattern stöder upp till sex argument.
    {0} Tidsstämpeln av typen java.util.Date
    {1} loggmarkören
    {2} namnet på den aktuella tråden
    {3} namnet på loggen
    {4} loggnivån
    {5} loggmeddelandet
    Om logganropet innehåller en Throwable stackspårningen läggs till i meddelandet.
    note caution
    CAUTION
    org.apache.sling.Commons.log.names måste ha ett värde.
    note note
    NOTE
    Loggskrivarsökvägarna är relativa till crx-quickstart plats.
    Därför har en loggfil angetts som:
    logs/thelog.log
    skriver till:
    <cq-installation-dir>/crx-quickstart/logs/thelog.log.
    Och en loggfil har angetts som:
    ../logs/thelog.log
    skriver till en katalog:
    <cq-installation-dir>/logs/
    (t.ex. bredvid <cq-installation-dir>/crx-quickstart/)
  4. Det här steget är bara nödvändigt när ett nytt skrivprogram krävs (dvs. med en konfiguration som inte är densamma som standardskrivaren).

    note caution
    CAUTION
    En ny loggningsskrivarkonfiguration krävs bara när den befintliga standardinställningen inte är lämplig.
    Om inget explicit skrivprogram är konfigurerat genereras automatiskt ett implicit skrivprogram baserat på standardvärdet.

    Under /apps/<project-name>/config, skapa en nod för den nya Konfiguration av skrivprogram för Apache Sling Logging:

    • Namn: org.apache.sling.commons.log.LogManager.factory.writer-<identifier> (eftersom detta är ett skrivprogram)

      Precis som med Logger, <identifier> ersätts med fri text som du (måste) anger för att identifiera instansen (du kan inte utelämna den här informationen). Till exempel, org.apache.sling.commons.log.LogManager.factory.writer-MINE

    • Typ: sling:OsgiConfig

    note note
    NOTE
    Även om det inte är ett tekniskt krav är det tillrådligt att <identifier> unika.

    Ange följande egenskaper för den här noden:

    • Namn: org.apache.sling.commons.log.file

      Typ: String

      Värde: Ange loggfilen så att den överensstämmer med den fil som anges i loggboken.

      i det här exemplet ../logs/myLogFile.log.

    • Konfigurera de andra parametrarna efter behov:

      • Namn: org.apache.sling.commons.log.file.number

        Typ: Long

        Värde: Ange hur många loggfiler du vill behålla. till exempel 5

      • Namn: org.apache.sling.commons.log.file.size

        Typ: String

        Värde: Ange vad som krävs för att kontrollera filens rotation efter storlek/datum. till exempel '.'yyyy-MM-dd

    note note
    NOTE
    org.apache.sling.commons.log.file.size styr rotationen av loggfilen genom att ange antingen:
    • maximal filstorlek
    • ett tids-/datumschema
    för att ange när en ny fil ska skapas (och den befintliga filen får ett nytt namn enligt namnmönstret).
    • En storleksgräns kan anges med ett tal. Om ingen storleksindikator anges används detta som antal byte, eller så kan du lägga till en av storleksindikatorerna - KB, MB, eller GB (skiftläge ignoreras).
    • Ett tids-/datumschema kan anges som java.util.SimpleDateFormat mönster. Detta anger den tidsperiod efter vilken filen ska roteras. det suffix som läggs till i den roterade filen (för identifiering).
    Standardvärdet är '.'yyyy-MM-dd (för daglig loggrotation)
    Så vid midnatt den 20 januari 2010 (eller när det första loggmeddelandet efter detta blir exakt) kommer …/logs/error.log att byta namn till …/logs/error.log.2010-01-20. Loggning för den 21 januari kommer att skickas till (en ny och tom) …/logs/error.log tills den överförs vid nästa ändring av dagen.
    table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2 5-row-2
    '.'yyyy-MM Rotation i början av varje månad
    '.'yyyy-ww Rotation på den första dagen i varje vecka (beror på språkområdet).
    '.'yyyy-MM-dd Rotation vid midnatt varje dag.
    '.'yyyy-MM-dd-a Rotation vid midnatt och middag varje dag.
    '.'yyyy-MM-dd-HH Rotation överst varje timme.
    '.'yyyy-MM-dd-HH-mm Rotation i början av varje minut.
    Obs! När du anger tid/datum:
    1. Du bör"escape"-text inom ett par enkla citattecken (' ');

      om du vill undvika att vissa tecken tolkas som mönsterbokstäver.

    2. Använd bara tecken som är tillåtna för ett giltigt filnamn var som helst i alternativet.

  5. Läs den nya loggfilen med det verktyg du valt.

    Loggfilen som skapas i det här exemplet kommer att ../crx-quickstart/logs/myLogFile.log.

Felix Console innehåller även information om stöd för att lagra loggar på ../system/console/slinglog; till exempel http://localhost:4502/system/console/slinglog.

Söka efter granskningsposter finding-the-audit-records

Granskningsregister förs för att visa vem som gjorde vad och när. Olika granskningsposter genereras för både AEM WCM- och OSGi-händelser.

AEM WCM-granskningsposter visas vid sidredigering aem-wcm-audit-records-shown-when-page-authoring

  1. Öppna en sida.

  2. I sidosparken kan du välja fliken med låsikonen och sedan dubbelklicka på Granskningslogg…

  3. Ett nytt fönster öppnas med en lista över granskningsposter för den aktuella sidan.

    screen_shot_2012-02-02at43601pm

  4. Klicka OK när du vill stänga fönstret.

AEM WCM-granskningsposter i databasen aem-wcm-auditing-records-within-the-repository

I /var/audit mapp, granskningsposter sparas enligt resursen. Du kan gå nedåt tills du ser de enskilda posterna och den information de innehåller.

Dessa poster innehåller samma information som den som visas när du redigerar en sida.

OSGi Granskningsposter från webbkonsolen osgi-audit-records-from-the-web-console

OSGi-händelser genererar också granskningsposter som kan ses av Konfigurationsstatus tab -> Loggfiler i AEM webbkonsol:

screen_shot_2012-02-13at50346pm

Övervaka replikeringsagenter monitoring-your-replication-agents

Du kan övervaka dina replikeringsköer för att identifiera när en kö är avstängd eller blockerad - vilket i sin tur kan tyda på ett problem med en publiceringsinstans eller ett externt system:

  • Är alla obligatoriska köer aktiverade?

  • Krävs det fortfarande inaktiverade köer?

  • alla enabled köer ska ha statusen idle eller active, som anger normal drift, inga köer ska vara blocked, som ofta är ett tecken på problem på mottagarsidan.

  • om storleken på kön ökar över tiden kan detta ange en blockerad kö.

Så här övervakar du en replikeringsagent:

  1. Öppna verktyg AEM.

  2. Klicka Replikering.

  3. Dubbelklicka på länken till agenterna för lämplig miljö (antingen vänster eller höger ruta). till exempel Agenter på författare.

    I det resulterande fönstret visas en översikt över alla dina replikeringsagenter för redigeringsmiljön, inklusive mål och status.

  4. Klicka på lämpligt agentnamn (som är en länk) för att visa detaljerad information om agenten:

    chlimage_1-8

    Här kan du:

    • Se om agenten är aktiverad.
    • Se målet för alla replikeringar.
    • Kontrollera om replikeringskön är aktiv (aktiverad).
    • Se om det finns några objekt i kön.
    • Uppdatera eller Rensa uppdatera visningen av köposter, så att du lättare kan se objekt komma in i och lämna kön.
    • Visa logg för att få åtkomst till loggen över eventuella åtgärder från replikeringsagenten.
    • Testanslutning till målinstansen.
    • Tvinga återförsök på alla köobjekt om det behövs.
    note caution
    CAUTION
    Använd inte länken Testa anslutning för den omvända replikeringsutkorgen på en publiceringsinstans.
    Om ett replikeringstest utförs för en Utkorgskö kommer alla objekt som är äldre än testreplikeringen att bearbetas på nytt med varje omvänd replikering.
    Om sådana objekt redan finns i en kö kan de hittas med följande XPath JCR-fråga och bör tas bort.
    /jcr:root/var/replication/outbox//*[@cq:repActionType='TEST']

Du kan också utveckla en lösning för att identifiera alla replikeringsagenter (som finns under /etc/replication/author eller /etc/replication/publish) och sedan kontrollera status för agenten ( enabled, disabled) och den underliggande kön ( active, idle, blocked).

Övervakningsprestanda monitoring-performance

Prestandaoptimering är en interaktiv process som får fokus under utvecklingen. Efter distributionen granskas den vanligtvis efter specifika intervall eller händelser.

Metoder som används för att samla in information för optimering kan också användas för kontinuerlig övervakning.

NOTE
Specifik tillgängliga konfigurationer för att förbättra prestanda kan också kontrolleras.

Nedan visas vanliga prestandaproblem som uppstår, tillsammans med förslag på hur du kan hitta och motverka dem.

Yta
Symtom
Öka kapaciteten…
Minska volymen…
Klient
Hög klientprocessoranvändning.
Installera en klientprocessor med högre prestanda.
Förenkla (HTML) layouten.
Låg processoranvändning på servern.
Uppgradera till en snabbare webbläsare.
Förbättra cacheminnet på klientsidan.
Vissa kunder är snabba, vissa långsamma.
Server
Nätverk
CPU-användningen låg på både servrar och klienter.
Ta bort eventuella flaskhalsar i nätverket.
Förbättra/optimera konfigurationen av klientcachen.
Det går snabbt att bläddra lokalt på servern (relativt).
Öka nätverkets bandbredd.
Minska"vikten" på dina webbsidor (t.ex. färre bilder, optimerad HTML).
Webbserver
Processoranvändningen på webbservern är hög.
Klustra dina webbservrar.
Minska antalet träffar per sida (besök).
Använd en maskinvarubaserad belastningsutjämnare.
Program
Serverns processoranvändning är hög.
Klustera dina AEM instanser.
Sök efter, och eliminera, processor- och minnesgropar (använd kodgranskning, tidsutdata osv.).
Hög minnesförbrukning.
Förbättra cachelagringen på alla nivåer.
Låga svarstider.
Optimera mallar och komponenter (t.ex. struktur, logik).
Databas
Cache

Prestandaproblem kan bero på ett antal orsaker som inte har något att göra med webbplatsen, bland annat tillfälliga avbrott i anslutningshastigheten, processorbelastningen och många andra.

Det kan även påverka alla besökare eller bara en del av dem.

All denna information måste hämtas, sorteras och analyseras innan du kan optimera den allmänna prestandan eller lösa specifika problem.

  • Innan du upplever ett prestandaproblem:

    • Samla in så mycket information som möjligt för att bygga upp goda kunskaper om systemet under normala förhållanden
  • När du får ett prestandaproblem:

    • försök att replikera den med en (eller helst med flera) standardwebbläsare, på en annan klient som du vet har bra allmänna prestanda och/eller på själva servern (om möjligt)

    • kontrollera om något (relaterat till systemet) har ändrats inom en lämplig tidsperiod och om någon av dessa ändringar kan ha påverkat prestandan

    • ställa frågor som:

      • inträffar problemet endast vid vissa tidpunkter?
      • uppstår problemet endast på vissa sidor?
      • Påverkas andra förfrågningar?
    • Samla in så mycket information som möjligt för att jämföra med dina kunskaper om systemet under normala förhållanden:

Verktyg för övervakning och analys av prestanda tools-for-monitoring-and-analyzing-performance

Nedan ges en kort översikt över några av de verktyg som är tillgängliga för övervakning och analys av prestanda.

Vissa av dessa kommer att vara beroende av operativsystemet.

Verktyg
Används för att analysera..
Användning/Mer information..
request.log
Svarstider och samtidighet.
Tolka request.log.
truss/strace
Sidinläsning

Unix/Linux-kommandon för att spåra systemanrop och signaler. Öka loggnivån till INFO.

Analysera antalet sidinläsningar per begäran, vilka sidor, osv.

Tråddumpar
Observera JVM-trådar. Identifiera innehåll, lås och långa löptider.

Beroende på operativsystem:
- Unix/Linux: kill -QUIT <pid>
- Windows (konsolläge): Ctrl-Break

Analysverktyg finns också tillgängliga, till exempel TDA.

Heap Dumps
Slut på minne som orsakar långsamma prestanda.

Lägg till:
-XX:+HeapDumpOnOutOfMemoryError
till java-anropet till AEM.

Se Felsökningsguide för Java SE 6 med HotSpot VM.

Systemanrop
Identifiera timingproblem.

Samtal till System.currentTimeMillis() eller com.day.util.Timing används för att generera tidsstämplar från koden eller via HTML-kommentarer.

Obs! Dessa bör implementeras så att de kan aktiveras/avaktiveras efter behov. När ett system fungerar smidigt behövs inte de allmänna kostnaderna för att samla in statistik.

Apache Bench
Identifiera minnesläckor och analysera responstiden selektivt.

grundanvändningen är:

ab -k -n <requests> -c <concurrency> <url>

Se Apache Bench och ab man page för fullständig information.

Sökanalys
Kör sökfrågor offline, identifiera svarstid för frågan, testa och bekräfta resultatuppsättningen.
JMeter
Belastnings- och funktionstester.
https://jakarta.apache.org/jmeter/
JProfiler
Detaljerad processor- och minnesprofilering.
https://www.ej-technologies.com/
JConsole
Observera JVM-statistik och trådar.

Användning: jconsole

Se jconsole och Övervaka prestanda med JConsole.

Obs! Med JDK 1.6 kan JConsole byggas ut med plugin-program. till exempel Top eller TDA (Thread Dump Analyzer).

Java VisualVM
Observera JVM-statistik, trådar, minne och profilering.

Användning: jvisualvm eller visualvm

Se jvisualvm, visualvm och Övervakningsprestanda med (J)VisualVM.

Obs! Med JDK 1.6 kan VisualVM utökas med plugin-program.

truss/strace, lsof
Ingående kernelanrop och processanalys (Unix).
Unix/Linux-kommandon.
Timingstatistik
Se timingstatistik för sidåtergivning.
Om du vill se tidsstatistik för sidåtergivning kan du använda Ctrl-Skift-U tillsammans med ?debugClientLibs=true anges i URL:en.
Verktyg för processor- och minnesprofilering
Används vid analys av långsamma begäranden under utveckling.
Till exempel: YourKit.
Informationsinsamling
Installationens aktuella tillstånd.
Om du vet så mycket som möjligt om din installation kan det också hjälpa dig att spåra vad som kan ha orsakat prestandaförändringar och om dessa ändringar är motiverade. Dessa mätvärden måste samlas in med regelbundna intervall så att du enkelt kan se betydande ändringar.

Tolka request.log interpreting-the-request-log

Den här filen registrerar grundläggande information om varje begäran som görs till AEM. Denna värdefulla slutsats kan extraheras.

The request.log erbjuder ett inbyggt sätt att se hur lång tid det tar att begära. I utvecklingssyfte är det användbart att tail -f den request.log och hålla utkik efter långsamma svarstider. Analysera en större request.log rekommenderar vi användning av rlog.jar som gör att du kan sortera och filtrera efter svarstider.

Vi rekommenderar att du isolerar de"långsamma" sidorna från request.logoch sedan justera dem individuellt för bättre prestanda. Detta görs vanligtvis genom att prestandamätningar per komponent inkluderas eller genom att ett prestandaprofileringsverktyg som [yourkit](https://www.yourkit.com/).

Övervaka trafik på din webbplats monitoring-traffic-on-your-website

Begärandeloggen registrerar varje begäran som gjorts, tillsammans med svaret:

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

Genom att summera alla GETTER under en viss period (t.ex. under olika 24-timmarsperioder) kan du göra utdrag om den genomsnittliga trafiken på webbplatsen.

Övervaka svarstider med request.log monitoring-response-times-with-the-request-log

En bra utgångspunkt för prestandaanalys är begärandeloggen:

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

Loggen ser ut så här (raderna förkortas för enkelhetens skull):

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

Den här loggen har en rad per begäran eller svar:

  • Det datum då varje begäran eller svar gjordes.

  • Numret på begäran, inom hakparentes. Numret matchar för begäran och svaret.

  • En pil som anger om det är en begäran (pil som pekar till höger) eller ett svar (pilen till vänster).

  • För begäranden innehåller raden:

    • metoden (vanligtvis GET, HEAD eller POST)
    • begärd sida
    • protokollet
  • För svar innehåller raden:

    • statuskoden (200 betyder "lyckades", 404 betyder "sidan hittades inte"
    • MIME-typen
    • svarstid

Med små skript kan du extrahera den information som behövs från loggfilen och sammanställa den statistik som du vill ha. Därifrån ser du vilka sidor eller typer av sidor som är långsamma och om de totala prestandan är tillfredsställande.

Övervaka söksvarstider med request.log monitoring-search-response-times-with-the-request-log

Sökbegäranden registreras också i loggfilen:

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

Så som ovan kan du använda skript för att extrahera relevant information och bygga upp statistik.

När du väl har bestämt svarstiden kan du behöva analysera varför begäran tar den tid som behövs och vad som kan göras för att förbättra svaret.

Övervaka antalet samtidiga användare och deras inverkan monitoring-the-number-and-impact-of-concurrent-users

Igen request.log kan användas för att övervaka samtidighet och systemets reaktion på detta.

Testerna måste göras för att avgöra hur många samtidiga användare som systemet kan hantera innan en negativ påverkan ses. Återigen kan du använda skript för att extrahera resultat från loggfilen:

  • övervaka hur många förfrågningar som görs inom en viss tidsperiod, t.ex. en minut
  • testa effekterna av ett visst antal användare som alla gör samma förfrågningar samtidigt (så nära som möjligt), t.ex. 30 användare klickar Spara samtidigt.
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

Använda rlog.jar för att hitta begäranden med lång varaktighet using-rlog-jar-to-find-requests-with-long-duration-times

AEM innehåller olika hjälpverktyg som finns i:
<cq-installation-dir>/crx-quickstart/opt/helpers

En av dessa, rlog.jar, kan användas för att snabbt sortera request.log så att förfrågningar visas med varaktighet, från längst till kortast.

Följande kommando visar möjliga argument:

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

Du kan till exempel köra den och ange request.log som en parameter och visa de 10 första begäranden som har längst varaktighet:

$ 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

Du kan behöva sammanfoga den enskilda personen request.log filer om du behöver utföra den här åtgärden på ett stort dataprov.

Apache Bench apache-bench

För att minimera specialfall (t.ex. skräpinsamling) rekommenderar vi att du använder ett verktyg som apachebench (se t.ex. ab för ytterligare dokumentation) för att identifiera minnesläckor och selektivt analysera svarstiden.

Apache Bench kan användas på följande sätt:

$ 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)

Siffrorna ovan är tagna från en vanlig bärbar MAcBook Pro-dator (mitten av 2010) med åtkomst till företagssidan för geometrixx, som ingår i en AEM. Sidan är mycket enkel, men inte optimerad för prestanda.

apachebench visar också tiden per begäran som medelvärde för alla samtidiga begäranden, se Time per request: 54.595 [ms] (medelvärde, för alla samtidiga begäranden). Du kan ändra värdet på parametern concurrency -c (antal flera begäranden om att utföra samtidigt) för att se eventuella effekter.

Begäranräknare request-counters

Information om begärandetrafik (antal förfrågningar under en viss tidsperiod) ger dig en indikation på belastningen på din instans. Den här informationen kan extraheras från request.logmen med räknare kan du automatisera datainsamlingen så att du kan se:

  • signifikanta skillnader i aktivitet (dvs. skillnader mellan"många förfrågningar" och"låg aktivitet")
  • när en instans inte används
  • alla omstarter (räknarna återställs till 0)

Om du vill automatisera informationsinsamlingen kan du även installera ett RequestFilter för att öka antalet räknare vid varje begäran. Flera räknare kan användas för olika tidsperioder.

De insamlade uppgifterna kan användas för att ange

  • betydande förändringar i verksamheten
  • en redundant instans
  • alla omstarter (räknaren återställs till 0)

HTML kommentarer html-comments

Vi rekommenderar att alla projekt innehåller html comments för serverprestanda. Många bra exempel finns. Välj en sida, öppna sidkällan för visning och bläddra längst ned. Kod som följande kan visas:

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

Övervaka prestanda med JConsole monitoring-performance-using-jconsole

Verktygskommandot jconsole är tillgängligt med JDK.

  1. Starta AEM.

  2. Kör jconsole.

  3. Markera AEM och Anslut.

  4. Från Local program, dubbelklicka com.day.crx.quickstart.Main; Översikten visas som standard:

    chlimage_1-87

    Därefter kan du välja andra alternativ.

Övervakningsprestanda med (J)VisualVM monitoring-performance-using-j-visualvm

Sedan JDK 1.6 kommando för verktyget jvisualvm är tillgängligt. När du har installerat JDK 1.6 kan du:

  1. Starta AEM.

    note note
    NOTE
    Om du använder Java 5 kan du lägga till -Dcom.sun.management.jmxremote -argument till den java-kommandorad som startar JVM. JMX är aktiverat som standard med Java 6.
  2. Kör antingen:

    • jvisualvm: i mappen JDK 1.6 bin (testversion)
    • visualvm: kan hämtas från VisualVM (avskalningsversion)
  3. Från Local program, dubbelklicka com.day.crx.quickstart.Main; Översikten visas som standard:

    chlimage_1-88

    Därefter kan du välja andra alternativ, bland annat Bildskärm:

    chlimage_1-89

Du kan använda det här verktyget för att generera tråddumpar och minnesdumpar. Den här informationen begärs ofta av den tekniska supportteamet.

Informationsinsamling information-collection

Om du vet så mycket som möjligt om din installation kan det hjälpa dig att spåra vad som kan ha orsakat prestandaförändringar och om dessa ändringar är motiverade. Dessa mätvärden måste samlas in med regelbundna intervall så att du enkelt kan se betydande ändringar.

Följande information kan vara användbar:

Hur många författare arbetar med systemet? how-many-authors-are-working-with-the-system

Använd kommandoraden för att se hur många författare som har använt systemet sedan installationen:

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

Så här ser du hur många författare som arbetar ett visst datum:

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

Vilket är det genomsnittliga antalet sidaktiveringar per dag? what-is-the-average-number-of-page-activations-per-day

Om du vill se det totala antalet sidaktiveringar sedan serverinstallationen använder en databasfråga, via CRXDE - Tools - Query:

  • Typ XPath

  • Bana /

  • Fråga //element(*, cq:AuditEvent)[@cq:type='Activate']

Beräkna sedan medelvärdet genom att beräkna antalet dagar som har gått sedan installationen.

Hur många sidor har du i det här systemet? how-many-pages-do-you-currently-maintain-on-this-system

Om du vill se antalet sidor som för närvarande finns på servern använder du en databasfråga; via CRXDE - Tools - Query:

  • Typ XPath

  • Bana /

  • Fråga //element(*, cq:Page)

Om du använder MSM, vilket är det genomsnittliga antalet utrullningar per månad? if-you-use-msm-what-is-the-average-number-of-rollouts-per-month

För att fastställa det totala antalet utrullningar sedan installationen använder du en databasfråga. via CRXDE - Tools - Query:

  • Typ XPath

  • Bana /

  • Fråga //element(*, cq:AuditEvent)[@cq:type='PageRolledOut']

Beräkna medelvärdet genom att beräkna antalet månader som har gått sedan installationen.

Vilket är det genomsnittliga antalet Live-kopior per månad? what-is-the-average-number-of-live-copies-per-month

För att fastställa det totala antalet live-kopior som gjorts sedan installationen använder du en databasfråga. via CRXDE - Tools - Query:

  • Typ XPath

  • Bana /

  • Fråga //element(*, cq:LiveSyncConfig)

Använd återigen antalet månader som har gått sedan installationen för att beräkna genomsnittet.

Om du använder AEM Assets, hur många mediefiler har du för närvarande i Assets? if-you-use-aem-assets-how-many-assets-do-you-currently-maintain-in-assets

Om du vill se hur många DAM-resurser du för närvarande har använder du en databasfråga; via CRXDE - Tools - Query:

  • Typ XPath

  • Bana /

  • Fråga /jcr:root/content/dam//element(*, dam:Asset)

Vilken är den genomsnittliga storleken på resurserna? what-is-the-average-size-of-the-assets

Så här avgör du den totala storleken på /var/dam mapp:

  1. Använd WebDAV för att mappa databasen till det lokala filsystemet.

  2. Använd kommandoraden:

    code language-shell
    cd /Volumes/localhost/var
    du -sh dam/
    

    För att få medelstorleken dividerar du den globala storleken med det totala antalet resurser i /var/dam (se ovan).

Hur många mallar används för närvarande? how-many-templates-are-currently-used

Om du vill se antalet mallar som för närvarande finns på servern använder du en databasfråga. via CRXDE - Tools - Query:

  • Typ XPath

  • Bana /

  • Fråga //element(*, cq:Template)

Hur många komponenter används för närvarande? how-many-components-are-currently-used

Om du vill se antalet komponenter som för närvarande finns på servern använder du en databasfråga. via CRXDE - Tools - Query:

  • Typ XPath

  • Bana /

  • Fråga //element(*, cq:Component)

Hur många förfrågningar per timme har du på författarsystemet vid maximal tid? how-many-requests-per-hour-do-you-have-on-the-author-system-at-peak-time

Så här tar du reda på begäranden per timme som du har på författarsystemet vid maximal tid:

  1. Använd kommandoraden för att bestämma det totala antalet begäranden sedan installationen:

    code language-shell
    cd <cq-installation-dir>/crx-quickstart/logs
    grep -R "\->" request.log | wc -l
    
  2. Så här bestämmer du start- och slutdatum:

    code language-shell
    vim request.log
    G / 1G: for the last/first lines
    

    Använd dessa värden för att beräkna antalet timmar som har gått sedan installationen, och sedan det genomsnittliga antalet begäranden per timme.

Hur många begäranden per timme har du i publiceringssystemet vid maximal tid? how-many-requests-per-hour-do-you-have-on-the-publish-system-at-peak-time

Upprepa proceduren ovan på din publiceringsinstans.

Analyserar specifika scenarier analyzing-specific-scenarios

Här följer en lista med förslag på vad du ska kontrollera om du får vissa prestandaproblem. Listan är tyvärr inte helt heltäckande.

CPU vid 100 % cpu-at

Om datorns CPU hela tiden körs med 100 % kan du se:

Slut på minne out-of-memory

Även om sådana fel bör identifieras under utveckling och testning kan vissa scenarier gå igenom.

Om minnet håller på att ta slut kan du se det på olika sätt, bland annat på prestandaförsämringar och felmeddelanden, inklusive undertexten:

java.lang.OutOfMemoryError

I dessa fall ska du kontrollera:

Skiva-I/O disk-i-o

Om det inte finns tillräckligt med diskutrymme på datorn eller om disktrassel börjar visas följande:

Regelbunden prestandaförsämring regular-performance-degradation

Om du ser att prestanda för instansen försämras efter varje omstart (ibland en vecka eller mer senare) kan du kontrollera följande:

JVM-justering jvm-tuning

Java Virtual Machine (JVM) har kraftigt förbättrats när det gäller justering (särskilt sedan Java 7). Därför är det ofta lämpligt att ange en rimlig fast JVM-storlek och att använda standardvärdena.

Om standardinställningarna inte är lämpliga är det viktigt att fastställa en metod för att övervaka och utvärdera prestandan för global katalog innan du försöker justera den virtuella datorn. Detta kan inbegripa övervakningsfaktorer som stackstorlek, algoritm och andra aspekter.

Några vanliga alternativ är:

  • VerboseGC:

    code language-none
    -verbose:gc \
     -Xloggc:$LOGS/verbosegc.log \
     -XX:+PrintGCDetails \
     -XX:+PrintGCDateStamps
    

Den resulterande loggen kan importeras av en GC-visualiserare som:

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

Eller JConsole:

  • De här inställningarna gäller för en "bred" JMX-anslutning:

    code language-none
    -Dcom.sun.management.jmxremote \
     -Dcom.sun.management.jmxremote.port=8889 \
     -Dcom.sun.management.jmxremote.authenticate=false \
     -Dcom.sun.management.jmxremote.ssl=false
    
  • Anslut sedan till JVM med JConsole; se:
    [https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html](https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html)

Detta hjälper dig att se hur mycket minne som används, vilka GC-algoritmer som används, hur lång tid det tar att köra dem och vilken effekt detta har på programmets prestanda. Utan detta är finjustering bara "slumpmässigt virvlande knoppar".

NOTE
För Oraclets virtuella dator finns även information på:
https://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html
recommendation-more-help
6a71a83d-c2e0-4ce7-a6aa-899aa3885b56