FAQ #3622
Artikel editieren
Artikel weiterleiten

Hoe kan ik performanceproblemen op mijn server verhelpen?

Inhoudsopgave Inhoudsopgave

 

Performanceproblemen in het algemeen

Performanceproblemen ontstaan als de server niet zo goed presteert als het hoort. De oorzaken hiervan kunnen zeer uiteenlopend zijn. Vaak ligt de storing op een plaats die je niet direct verwacht. Daarom is het des te belangrijker de mogelijke oorzaken op te sporen en volledig uit te zoeken. Hoe je dat doet, lees je in dit artikel.

 

Houd er rekening mee dat STRATO medewerkers geen verbinding met je server mogen maken om gegevens op te vragen of server te monitoren.

 

Soorten performanceproblemen

Er zijn verschillende soorten performanceproblemen die dezelfde invloed hebben op de werking van de server. Het is hier belangrijk om het eigenlijke knelpunt te vinden.

 

Mogelijke problemen:

  • Trage harde schijf / SSD
    Is een harde schijf erg traag, dan blijkt dit vooral uit een erg langzaam gedrag bij het inloggen of starten van programma's. Maar als de programma's eenmaal gestart zijn, draait alles meestal vrij snel. Problemen ontstaan meestal pas weer als het wisselbestand of de partitie gebruikt wordt, of als gegevens opnieuw geladen of opgeslagen moeten worden.

  • Trage netwerkverbinding
    Een netwerkverbinding die bezet of te traag is, levert allerlei problemen op. Die kunnen variëren van een onjuiste tijd tot een foutmelding bij het opvragen van de website. Omdat vooral op servers veel functies en diensten afhankelijk zijn van een goed werkende netwerkverbinding, zijn de soorten problemen die opduiken ook zeer uiteenlopend.

  • Hoge systeem- of CPU-belasting
    Een hoge belasting van de CPU of het hele systeem is waarschijnlijk de bekendste oorzaak van performanceproblemen. Hier ontstaat een algemene vertraging in de weergave en in de responstijden. De server reageert niet zo snel als je zou verwachten.

Sporadisch of permanent

Je moet eerst onderzoeken of de problemen die je ondervindt bij het gebruik van de STRATO server permanent zijn of alleen op bepaalde momenten voorkomen.
Is het sporadisch gedrag? Kijk dan of er een patroon is, bijvoorbeeld elke donderdag om 13.00 uur. Is dat zo? Controleer dan of een geplande taak (bijvoorbeeld een back-up) de oorzaak kan zijn en plan die opnieuw in. Als de timing van de performanceproblemen daardoor verandert, heb je de oorzaak al gevonden.

 

Servermonitoring en logs

De logs die normaal door het systeem gegenereerd worden, kunnen de eerste aanwijzingen zijn over de oorzaak van performanceproblemen. Het is daarom altijd de moeite waard om eens door de systeemlogs te lopen.
Onder Linux kun je de kernel-logs bekijken met sudo dmesg (hier verschijnen hardwarefouten zoals problemen met de harde schijf). Je kunt meer logs zien met de opdracht) journalctl (hier loont het de moeite de main page te bekijken voor de verschillende opties) of in de logbestanden direct via /var/log.

 

Onder Windows is de Event Viewer in het computerbeheer het startpunt voor de logs. Hier is het gebruik van de verschillende filters van belang, want alle gebeurtenissen worden verzameld. Zelfs bij een normaal draaiend systeem is het normaal dat hier verschillende waarschuwingen of zelfs fouten verschijnen.


Een monitoring van de server is in elk geval aan te bevelen, zodat je tenminste achteraf kunt nagaan wat er op de server gebeurde. Het is immers moeilijk om op de server te kijken als een performanceprobleem precies op dat moment optreedt.


Er zijn veel monitoringtools, zowel voor Linux als voor Windows. Deze variëren van een eenvoudige registratie van enkele basisgegevens in een logbestand tot volwaardige oplossingen met registratie en presentatie van de data van meerdere servers.


In het algemeen wordt een onderscheid gemaakt tussen real-time monitoring en langdurige monitoring. Bij real-time monitoring worden de gegevens vaker opgevraagd, maar niet zo lang bewaard. Hier kun je zelden verder dan een uur terugkijken. Bij langdurige monitoring daarentegen worden de gegevens langer bewaard (afhankelijk van de instelling kun je dagen, weken, of zelfs maanden of jaren terugkijken). De gegevens worden echter niet zo vaak opgevraagd.


Enkele voorbeelden van monitoringsystemen zijn Netdata, collectd, Nagios en Prometheus. Grafana zelf is geen monitoring, maar dient om de verzamelde gegevens (ook uit verschillende bronnen) te verwerken.


Heb je één van de nieuwe dedicated servers met het cloud-panel of een server in de ServerCloud? Dan raden we je aan monitoring in te stellen. Hoe je dit doet, lees je hier voor de dedicated servers en hier voor ServerCloud.


Onder Windows is real-time monitoring ook beschikbaar in het tabblad ‘Prestaties’ van het Taakbeheer. Voor meer gedetailleerde informatie kun je van hieruit de broncontrole openen. Hier kun je de oorzaak verder filteren, bijvoorbeeld hoog netwerkgebruik.

 

 

Zorg er trouwens voor dat de door monitoring verzamelde gegevens niet vrij beschikbaar zijn, maar alleen kunnen worden uitgelezen door geautoriseerde gebruikers. Ook de gegevensoverdracht moet beveiligd zijn. De data bevatten namelijk informatie die waardevol is voor potentiële hackers, zoals gegevens over de interne structuur van de server of servers.

Windows Server

Op een Windows-server controleer je eerst de huidige status op het tabblad Prestaties van het Taakbeheer. Het Taakbeheer open je via de toetscombinatie ‘Ctrl+Shift+Esc’ of via het menu dat opent als je met de rechtermuisknop op het Windows-icoon klikt.


Zoals met alle prestatietests kun je de tests het beste meerdere keren uitvoeren, op verschillende tijdstippen van de dag. Dit is de enige manier om een zinvol overzicht van de serverprestaties te krijgen. Een enkele test is slechts een momentopname van de huidige situatie.


In het geval van tijdelijke beperkingen moet je de tests uitvoeren tijdens het optreden van de storing. De waarden die in de normale toestand worden gemeten, dus als alles werkt, helpen je niet veel verder.

 

 

Prestaties van de harde schijven / SSD testen

Met de prestatie-evaluatie van Windows kun je eenvoudig de harde schijf testen. Voor dit doel is er de tool winsat die je start vanaf de opdrachtprompt (Windows-server 2016) of de Powershell (Windows-server 2019). Beide moet je met adminrechten openen.
Om de leessnelheid te testen, voer je dit in:

winsat disk -seq -read -drive X

 

Voor een test van de schrijfsnelheid gebruik je:
winsat disk -seq -write -drive X

 

Vervang de X door de juiste schijfletter (meestal C of D).  De resultaten kunnen er zo uitzien:
Festplatten-Performance

 

Op Windows-server 2012 R2 is winsat niet beschikbaar. Hier kun je andere tools gebruiken, die je apart moet installeren. Bijvoorbeeld Crystal Disk Mark of h2bench.

 

De netwerkverbinding testen

Je kunt een test van de netwerkverbinding uitvoeren via de vele verschillende snelheidstesten waarmee je bijvoorbeeld ook je internetverbinding thuis test. Het is raadzaam deze tests op verschillende tijdstippen en met verschillende aanbieders uit te voeren.
 
Onderstaand een voorbeeld hoe zo'n test er uit ziet:


Netzwerk-Check

 

De belasting van CPU en systeem

Voor de CPU-belasting en systeembelasting in het algemeen kun je in Windows het tabblad Prestaties van het Taakbeheer en de Broncontrole gebruiken.
Ressourcen-Monitor

 

Je kunt ook speciale CPU-stresstests uitvoeren als je vermoedt dat een hoge werkbelasting tot instabiliteit leidt. Hiervoor bestaan speciale programma's van andere aanbieders, die je afzonderlijk moet installeren. Heb je een VPS? Dan is de informatieve waarde beperkt, omdat de resultaten sterk afhangen van de actuele status van de virtualisatie.


Op een server met het cloud-panel kun je monitoring activeren (en bij voorkeur een monitoring agent installeren). Je kunt de waarden dan direct in het cloud-panel lezen:

 

Monitoring im Cloud Panel

 

Speciale gevallen

 

Een hoog geheugenverbruik op een VPS Windows

Zit in het taakbeheer van je VPS Windows het geheugenverbruik op vrijwel maximaal? We leggen je uit waarom dit zo is. Het getoonde beschikbare werkgeheugen is daarbij minder dan het gegarandeerde werkgeheugen van je VPS Windows.


De reden voor dit gedrag ligt in het geheugenbeheer van het virtualisatieplatform, waarbij geheugen dynamisch wordt toegewezen. Je VPS Windows krijgt altijd zoveel geheugen toegewezen als hij op dat moment nodig heeft, plus een kleine buffer. Als de belasting toeneemt, neemt ook de grootte van het toegewezen geheugen toe.

 

 

Voorbeeld:

Je VPS Windows toepassingen hebben 1,2 gigabyte geheugen nodig. Er is 1,44 gigabyte geheugen toegewezen. De geheugeneisen voor je server nemen vervolgens toe tot 2 gigabyte. Dan stijgt het toegewezen geheugen naar 2,4 gigabyte. Een vergroting van de geheugengrootte is mogelijk tot ten minste de gegarandeerde geheugengrootte van je VPS.

 

Deze informatie heeft onze support nodig

Als je op basis van de tot nu toe gegeven informatie geen oorzaak hebt kunnen vinden voor de schommelingen in de prestaties, kun je contact opnemen met onze supportafdeling. We hebben dan wat meer informatie en meetwaarden nodig:

  • Hoe uiten de performanceproblemen zich?
    Voorbeeld: ‘website xyz.nl laadt erg traag’ of ’zeer trage upload en download naar de server’.
  • Wanneer treedt het performanceprobleem precies op?
    Voorbeeld: ‘de hele tijd gedurende 2 dagen’ of ‘elke vrijdag om 15:00’.
  • Welke Windows-versie gebruik je precies?
  • Zijn alle updates geïnstalleerd?
  • De gemeten waarden voor de harde schijven / SSD's (zie hierboven)
  • In het geval van een defecte harde schijf of SSD, in ieder geval het serienummer van de harde schijf die nog in orde is (uit te lezen met bijv. smartmontools voor Windows).
  • Informatie uit de Windows event view (gefilterd)
  • De netwerkverbindingen en de resultaten van de upload en download (zie hierboven)
  • De evaluaties van de processen en het geheugengebruik
  • Weergave van CPU en systeembelasting (zie hierboven)
  • Afhankelijk van de beschikbaarheid, ook waarden uit de langetermijnmonitoring.

Bespreek het verzenden van de informatie altijd van tevoren met onze support.

 

Linux Server

Om performanceproblemen met een Linux-server tot op de bodem uit te zoeken, hebben we wat informatie nodig en de resultaten van diverse tests.


Zoals met alle prestatietests kun je de tests het beste meerdere keren uitvoeren, op verschillende tijdstippen van de dag. Dit is de enige manier om een zinvol overzicht van de serverprestaties te krijgen. Een enkele test is slechts een momentopname van de huidige situatie.


In het geval van tijdelijke performanceproblemen moeten de tests uitgevoerd worden tijdens het optreden van zo’n probleem. Gemeten waarden in de normale toestand, als alles goed werkt, helpen je niet verder.

 

 

Test de prestaties van de harde schijven / SSD

Om de harde schijven of de SSD te testen, gebruik je het programma fio, de ‘Flexible I/O Tester’. Het kan zijn dat dit nog geïnstalleerd moet worden. Het voordeel hiervan is dat het ook realistische resultaten geeft met een geheugenconfiguratie zoals die met onze VPS’en gebruikt wordt. Een test met dd is niet representatief, vanwege de verschillende geheugentechnologie die gebruikt wordt. Ga als volgt te werk:
 
Voor een test van de schrijfsnelheid:
sudo fio --rw=write --name=FIO --size=1G --filename=testfile

Er wordt een 1 GB-bestand ‘testfile’ aangemaakt. Dit kan ook gebruikt worden voor de volgende test..

Voor een test van de leessnelheid:

sudo fio --rw=read --name=FIO --size=1G --filename=testfile

Na het beëindigen van de tests met fio kan het bestand ‘testfile’ weer verwijderd worden:

sudo rm testfile

Een sterk gebruikte partitie kan ook performanceproblemen veroorzaken. Controleer daarom het verbruik van de partities::

sudo df -h

Interessant is ook de bezetting van de zogenaamde inodes, want ook te weinig inodes kunnen performanceproblemen opleveren:

sudo df -hi

In het geval van een dedicated server kan ook een gedeeltelijk of geheel defecte harde schijf of SSD een mogelijke oorzaak zijn. Als je vermoedt dat dit het geval is, start dan de server in het reddingssysteem en controleer het volgende:
 
Worden alle harde schijven herkend?

Opdracht: lsblk
De ontdekte harde schijven en hun partities worden hier getoond. De harde schijf of SSD zelf kun je vinden als sda en/of sdb en misschien sdc. Komen het nummer en de ontdekte grootte overeen met de informatie over je server?

DDe schijven (harde schijf en SSD) hebben enkele zelftest-mogelijkheden door middel van SMART, waarmee je de SMART-waarden kunt laten uitvoeren. Basisinformatie over de harde schijf kun je krijgen via:

smartctl -i /dev/sdX

Je kunt een volledig overzicht genereren met

smartctl -a /dev/sdX

(Vervang de X door de respectieve letter volgens de weergave van lsblk).

Let op dat de vermeldingen ‘pre-fail’ of ‘old-age’ normaal zijn voor de attributen. Alleen als hier iets anders staat, zoals ‘Failing now’, is er reden tot bezorgdheid.

Je kunt verder de uitvoer van lsblk en smartctl converteren naar een bestand en het naar ons sturen voor analyse. Bespreek dit in elk geval vooraf met onze support..

De netwerkverbinding testen

Om de actueel geopende netwerkverbindingen te controleren, kun je het beste deze opdracht gebruiken::

sudo ss -tpn

Hebben de verbindingsproblemen alleen effect op bepaalde diensten of programma’s, zoals de webserver? Dan kun je ook op de server nagaan welke processen momenteel wachten op verbindingen van buitenaf:

sudo ss -tulpn

Op een VPS Linux is het aantal gelijktijdige verbindingen beperkt. Controleer in het bestand /proc/user_beancounters de waarden “numtcpsock” (maximum aantal TCP-verbindingen) en “numothersock” (maximum aantal niet-TCP-verbindingen, dit omvat ook lokale Unix-sockets).

Om de netwerksnelheid te testen, raden we een upload en een download aan van een groot bestand. Dit doe je van en naar een andere server of een cloud storage. Hier moet je een programma gebruiken dat de overdrachtssnelheid weergeeft (bv. wget, curl of scp).

Een test met ‘speedtest’ of ‘speedtest-cli’ raden we af, omdat dit tot verkeerde resultaten kan leiden. Die zijn namelijk afhankelijk van de gebruikte versie en omgeving.

Een test op pakketverlies kun je doen met een ping. De gemakkelijkste manier om dit te doen is vanaf je bureaublad. Open een opdrachtprompt (of een terminal) en ping de server:
Linux: ping -c <aantal> <serveradres>
Windows: ping -n <aantal> <serveradresse>
Het aantal pakketten moet zo gekozen worden dat je kunt schatten hoeveel pakketten er verloren zullen gaan. We raden aan te testen met minstens 10 tot 20 pakketjes.

Bij verbindingsproblemen kan informatie via een traceroute ook helpen. Dit laat de weg zien die een pakket aflegt. Ook hier kun je de test starten vanaf je computer met een opdrachtprompt of een terminal.
Linux: traceroute <serveradresse>
Windows: tracert <serveradresse>

CPU- en systeembelasting

Een overzicht van de huidige CPU-belasting krijg je met het programma top (einde weergave met de q toets ). In de standaardsortering zie je het proces dat de meeste CPU-prestaties verbruikt, bovenaan..

e kunt een beter overzicht krijgen met het programm htop, maar dat moet je meestal nog installeren.

Een volledige lijst van de processen die momenteel draaien, zie je met deze opdracht:

sudo ps -ely

Je kunt ook het geheugengebruik laten weergeven. Dit toont tevens het gebruik van het wisselgeheugen (swap):

sudo free -h

Het gebruik van swapgeheugen leidt meestal tot aanzienlijke prestatiedalingen, zelfs met een SSD.

Hoog geheugengebruik kan ook veroorzaakt worden door een programma- of configuratiefout. Een andere mogelijke oorzaak is een groot aantal toegangspogingen (weergegeven webpagina’s). Dit betekent dan dat het systeem gewoon te klein is voor de eisen.

Speciale gevallen

VPS Linux-grenswaardes

Een VPS Linux heeft enkele grenswaardes. Controleer ook het bestand /proc/user_beancounters op overschreden grenzen. In het bestand staat in de laatste kolom hoe vaak de desbetreffende limiet is overschreden sinds de laatste start van het systeem..

 

Overschrijding van sommige waarden kan tot gevolg hebben dat geen nieuwe processen meer gestart kunnen worden. Sommige programma's proberen dit steeds opnieuw en verhogen zo de belasting van het systeem.


Worden de grenzen al bij normaal gebruik overschreden? Neem dan wederom contact op met onze helpdesk. Daar kunnen ze bepalen of een upgrade van de server uitkomst biedt

 

 

Processen vs. threads voor VPS Linux

Kun je geen nieuwe processen starten, terwijl de bovenstaande grenzen niet overschreden zijn? Krijg je meldingen dat er niet genoeg geheugen vrij is, hoewel er toch voldoende geheugen beschikbaar is?


In dit geval kan de oorzaak liggen in een instelling in Linux zelf. De waarde hiervoor heet ‘DefaultTasksMax’.
Om de huidige grenswaarde te bepalen, voer je in de shell deze opdracht in:

systemctl show --property=DefaultTasksMax

Deze waarde geeft aan hoeveel threads een proces mag starten. Je bent vrij om de waarde naar eigen behoefte in te stellen in het bestand /etc/systemd/system.conf. Herstart de server na het aanbrengen van een wijziging. Dit zorgt ervoor dat de nieuwe instelling volledig effect heeft.

 

Het is niet verstandig om de waarde gelijk te stellen aan de maximumwaarde die voor het product is toegestaan. Want als dan één binary die waarde volledig benut, kunnen andere belangrijke systeemacties vastlopen. En dat leidt tot een blokkade van het hele systeem.

Je kunt de waarde in deze bestanden instellen:

/etc/systemd/system.conf

/etc/systemd/system.conf.d/*.conf

/run/systemd/system.conf.d/*.conf

/usr/lib/systemd/system.conf.d/*.conf

/etc/systemd/user.conf

/etc/systemd/user.conf.d/*.conf

/run/systemd/user.conf.d/*.conf

/usr/lib/systemd/user.conf.d/*.conf

Controleer deze bestanden als je een verandering in de waarde hebt aangebracht, maar de wijziging niet wordt overgenomen.

Voor meer informatie over configureerbare parameters gebruik je deze opdrach:

man systemd-system.conf

 

Hoge belasting door rsyslogd (Ubuntu 12.04 en 14.04)

In Ubuntu 14.04. en Ubuntu 12.04. bestaat een bekende bug met de rsyslogd. Dit resulteert in een verhoogde systeembelasting. De bug treedt niet meer op bij nieuwere Ubuntu-versies.


De oorzaak is de geactiveerde kernel-logging in het configuratiebestand van rsyslogd. Dit werkt niet onder het virtualisatieplatform van STRATO.


Je kunt in een paar stappen nagaan of deze bug de oorzaak is van een verhoogde belasting van je VPS..

 

1. Controleer het logbestand

Check of de volgende regels herhaaldelijk worden uitgevoerd in het logbestand van je VPS onder /var/log/syslog::
Nov 12 18:22:19 h123456 rsyslogd: message repeated 498 times: [imklog: error reading kernel log - shutting down: Bad file descriptor]
Nov 12 18:22:25 h123456 rsyslogd-2177: rsyslogd[internal_messages]: 2954152 messages lost due to rate-limiting

2. Controleer de belasting van je server

Je kunt de belasting van je server bepalen met behulp van SSH-toegang en het commando top. Log hiertoe in op je server met het programma putty en voer het commando top in. Vervolgens krijg je de belasting van de afzonderlijke taken van je server te zien. Controleer de opdracht rsyslogd en de CPU-belasting voor deze taak

 

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
371 syslog    20   0  261940   1500    944 S 100,1  0,0   2:00.82 rsyslogd

Heeft deze taak een erg hoge CPU-belasting? Dan is deze verantwoordelijk voor de performanceproblemen van je VPS. Je kunt de bug dan in een paar stappen verhelpen.

3. De bug verhelpen

Stop de dienst rsyslogd. Om dit te doen, gebruik je het commando:

sudo service rsyslog stop

In deze stap wordt kernel-logging uitgeschakeld. Gebruik hiervoor het commando:

sudo sed -i -e 's/^\$ModLoad imklog/#\$ModLoad imklog/g' /etc/rsyslog.conf

Je kunt ook met een editor het bestand /etc/rsyslog.conf controleren en deze regel uitschakelen met:

$ModLoad imklog   # provides kernel logging support

Dit doe je door een # voor de regel te zetten, zodat het een commentaar wordt.

4.Start de dienst rsyslogd opnieuw

Gebruik hiervoor de het commando:

sudo service rsyslog start

In de toekomst zal de dienst rsyslogd niet langer de prestaties van je VPS nadelig beïnvloeden.

Deze informatie heeft onze support nodig

Als je op basis van de tot nu toe gegeven informatie geen oorzaak hebt kunnen vinden voor de schommelingen in de prestaties, kun je contact opnemen met onze supportafdeling. We hebben dan wat meer informatie en meetwaarden nodig:

  • Hoe uiten de performanceproblemen zich?
    Voorbeeld: ‘website xyz.nl laadt erg traag’ of ’zeer trage upload en download naar de server’.
  • Wanneer treedt het performanceprobleem precies op?
    Voorbeeld: ‘permanent gedurende 2 dagen’ of ‘elke vrijdag om 15:00’.
  • Wurden alle Updates der jeweiligen Distribution installiert?
  • De gemeten waarden voor de harde schijven / SSD's (zie hierboven)
  • In het geval van een defecte harde schijf of SSD, in ieder geval het serienummer van de harde schijf die nog in orde is (kan bijvoorbeeld worden uitgelezen met smartctl).
  • De netwerkverbindingen en de resultaten van de upload en download (zie hierboven)
  • De evaluaties van de processen en het geheugengebruik (zie hierboven).
  • De uitvoer van het kernel-log (sudo dmesg)
  • Voor de VPS Linux: inhoud van het bestand /proc/user_beancounters
Bespreek het verzenden van de waarden altijd van tevoren met onze support.

 

×