Onverklaarbare periodieke CPU-Load pieken in Linux (centos)

[satya]

Op onze systemen hebben we te maken met een tot nu toe niet verklaarbaar fenomeen.

Het zijn voornamelijk Centos 6.5 systemen (Soms ook Suse) met applicaties van onze leverancier.

Op de systemen komt periodiek een CPU-Load piek voorbij die we niet kunnen verklaren. De normale load is bijvoorbeeld 0.2-0.3 en elke 40 minuten klopt dit voor 5 tot 6 minuten op tot 0.8 tot 0.10. De CPU-utilization blijft gewoon op 20% zonder afwijkingen zijn ding doen, en ook het geheugen blijft zoals het is. Het maakt niet uit of de server virtueel of fysiek is. Het betreft de 1 minute load.

Met diverse gebruikelijke tools is het onderzocht maar het geeft geen duidelijkheid waar het vandaan komt.



Zijn er anderen met een dergelijk verschijnsel, of wetend waar dit vandaan zou kunnen komen?

[ Voor 4% gewijzigd door satya op 26-08-2015 21:33 . Reden: png toegevoegd ]

[johnkeates]

Welke tools zijn 'gebruikelijk'? Hebben we het over APM? Of iemand die even een paar keer top uitvoerde om te kijken of er wat tussen stond.

[Yarisken]

Gebruik je shared storage ? Via top kan je de iowait tijd in het oog houden. Idealiter gaat dit nooit boven de 1% maar max 10% is toegelaten.

http://bencane.com/2012/0...ng-high-io-wait-in-linux/

Dit kan voor hogere cpu zorgen.

[Blokker_1999]

Indien het hier gaat over de load average moet je rekening houden met het feit dat deze gemiddelden rekening houden met 2 paramaters. In man 5 proc vinden we het volgende:

/proc/loadavg
The first three fields in this file are load average figures giving the number of jobs in the run queue (state R) or waiting for disk I/O (state D) averaged over 1, 5, and 15 minutes. They are the same as the load average numbers given by uptime(1) and other
programs.

Vaak word ook gesteld dat de avg load zonder problemen mag naderen tot aan het aantal CPUs dat je hebt. Heb je 2 CPUs dan mag de avg load dus perfect richting 2 gaan.

Met atop krijg je trouwens een overzicht van veel meer parameters die de belasting weergeven. Overbelasting word er in het rood weergegeven om aandacht te vragen.

[Hero of Time]

Je hebt een paar servers en die mogen eigenlijk niets doen? Waarom heb je ze dan? Het is juist de bedoeling dat ze werk verzetten. Idle servers zijn over powered servers en heb je dus in feite te veel uitgegeven voor wat 't moet doen.

Als het strak elke 40 minuten een piek geeft, dan doet de applicatie die erop draait iets. Maar als je idle 0.2 tot 0.3 doet en je krijgt daarna een piek naar 0.10, dan lijkt het mij juist dat 't op dat moment even wat minder werk verricht. Of ben je ergens een 0 vergeten?

Hoe dan ook, niet echt iets om je zorgen over te maken. Als de load nou naar 10 zou schieten, ipv onder de 1 te blijven was 't een ander verhaal.

[satya]

Hero of Time schreef op woensdag 26 augustus 2015 @ 20:59:
Als het strak elke 40 minuten een piek geeft, dan doet de applicatie die erop draait iets. Maar als je idle 0.2 tot 0.3 doet en je krijgt daarna een piek naar 0.10, dan lijkt het mij juist dat 't op dat moment even wat minder werk verricht. Of ben je ergens een 0 vergeten?

Hoe dan ook, niet echt iets om je zorgen over te maken. Als de load nou naar 10 zou schieten, ipv onder de 1 te blijven was 't een ander verhaal.

De applicatie "werkt" continu, en zoals vermeld blijft het de cpu-util en geheugen gebruik gelijk, ongeacht de applicatie die we draaien. We ervaren geen meetbare verandering in de resource consumptie van de applicaties zelf.

Gezien het aantal CPU's is het geen probleem, maar wel zijn de applicaties tijdkritisch aangezien er met real time data gewerkt wordt.

[satya]

johnkeates schreef op woensdag 26 augustus 2015 @ 17:46:
Welke tools zijn 'gebruikelijk'? Hebben we het over APM? Of iemand die even een paar keer top uitvoerde om te kijken of er wat tussen stond.

top, atop, htop, iotop, perf top, sar etc.

De leverancier heeft er zelfs een bedrijf bij gehad om het te onderzoeken.

[_trickster_]

Zoals @Hero of Time aangeeft, klopt het echt dat je 0.1 bedoeld ? dit is namelijk zelfs minder dan 0.2 / 0.3
En je geeft aan dat de piek elke 40 minuten komt.
Mischien wordt er als de load wel hoger is iets via een Cronjob ingestart ?

[satya]

Yarisken schreef op woensdag 26 augustus 2015 @ 17:47:
Gebruik je shared storage ? Via top kan je de iowait tijd in het oog houden. Idealiter gaat dit nooit boven de 1% maar max 10% is toegelaten.

http://bencane.com/2012/0...ng-high-io-wait-in-linux/

Dit kan voor hogere cpu zorgen.

Hier ga ik wat mee doen, op zich maken we geen gebruik van shared storage waar het om fysieke servers gaat.

[Yarisken]

satya schreef op woensdag 26 augustus 2015 @ 21:20:
[...]

Hier ga ik wat mee doen, op zich maken we geen gebruik van shared storage waar het om fysieke servers gaat.

Soms heb je bv via etc/fstab mounts van shared storage voor bv backup dumps op weg te schrijven. Doe is gewoon het command mount en zie of je iets ziet staan.
Kijk zoals hierboven gezegd ook is de crontab na.
Loopt er periodiek misschien een slecht geschreven query of heavy load query om de zoveel tijd... .
Neem is een tcpdump : tcpdump -i eth0 -s 1514 -w /opt/xxx/xxx
Misschien wordt er wel data ingelezen om de zoveel tijd. Via tcpdump kan je nakijken of er rond de periode van de heavy load bepaalde connecties worden gemaakt met andere servers.

Ik ben bijna wekelijks bezig met het troubleshooten van performatie problemen en met basic tools en monitoring kan je toch meestal snel pinpointen waar het probleem zich stelt.
In ons geval is het meestal storage I/0 ofwel slecht geschreven query's.
Bizar dat die firma niets vond.

[deadinspace]

satya schreef op woensdag 26 augustus 2015 @ 17:40:
Op de systemen komt periodiek een CPU-Load piek voorbij die we niet kunnen verklaren. De normale load is bijvoorbeeld 0.2-0.3 en elke 40 minuten klopt dit voor 5 tot 6 minuten op tot 0.8 tot 0.10. De CPU-utilization blijft gewoon op 20% zonder afwijkingen zijn ding doen, en ook het geheugen blijft zoals het is.

Zoals verschillende anderen al aankaartten zou dit door I/O kunnen komen. Hou eens een top open tijdens zo'n piek, en hou dan de "wa" waarde op de CPU-regel eens in de gaten.

I/O wait hoeft overigens helemaal niet door (gebruik van) een shared storage te komen, dat kan ook prima local storage zijn, of (niet-storage) netwerkactiviteit.


Verder kun je eens "vmstat 10" starten voordat zo'n piek begint (en weer afbreken als hij afgelopen is). Daarmee valt ook eea over I/O te zeggen.


Tot slot zou een output van "ps auxf" tijdens zo'n piek (doe het desnoods een paar keer achter elkaar met tussenpozen van 10 seconden ofzo) interessant kunnen zijn

[johnkeates]

Maar je hebt dus geen monitoring... dan is er ook niet perse wat zinvols over te zeggen. Heb je geen Zabbix o.i.d. om alle CPU usage en load te monitoren samen met 1-min top-snapshots? Zelf met wat tools lokaal wat uitvoeren gaat geen goed beeld geven van wat er nou precies gebeurt.

[Kees]

Voor en tijdens een piek, draai 'pidstat 1' en 'pidstat -d 1' in een tweede scherm en kijk welk proces er 'ineens' bijkomt.

[satya]

Kees schreef op donderdag 27 augustus 2015 @ 09:50:
Voor en tijdens een piek, draai 'pidstat 1' en 'pidstat -d 1' in een tweede scherm en kijk welk proces er 'ineens' bijkomt.

Super handig commando dank je. Komt in elke geval naar boven dat iets veel I/O veroorzaakt omdat I/O gerelateerde systeem processen zoals ksoftirqd, eventd, edac-poller naar boven komen.

[Kees]

satya schreef op donderdag 27 augustus 2015 @ 12:55:
[...]
eventd, edac-poller

Geheugenproblemen? Staat er iets in dmesg?

[ Voor 7% gewijzigd door Kees op 27-08-2015 12:58 ]

[satya]

Kees schreef op donderdag 27 augustus 2015 @ 12:58:
[...]

Geheugenproblemen? Staat er iets in dmesg?

Nee van de 6GB op het systeem waar ik nu het onderzoek doe is maar 1GB in gebruik.
Dit is een stevige HP Z400.

[Kees]

satya schreef op donderdag 27 augustus 2015 @ 13:04:
[...]

Nee van de 6GB op het systeem waar ik nu het onderzoek doe is maar 1GB in gebruik.
Dit is een stevige HP Z400.

Ik bedoel fysieke geheugenproblemen, dat dus die edac_poller heel veel errors moet corrigeren bijvoorbeeld. Maar dat zou een incidenteel probleem moeten zijn en niet op alle servers moeten voorkomen.

Gezien de frequentie lijkt het mij wel iets wat periodiek loopt, en aangezien het de frequency niet echt op een cron-task wijst zou dat de kernel moeten zijn.

Verder geef je aan dat ksoftirqd draait, je zou kunnen kijken in /proc/interrupts of er een interupt is die normaal weinig hits krijgt maar tijdens de pieken wel heel veel hits heeft.

offtopic:
Z400?

[satya]

Kees schreef op donderdag 27 augustus 2015 @ 13:10:
[...]

Verder geef je aan dat ksoftirqd draait, je zou kunnen kijken in /proc/interrupts of er een interupt is die normaal weinig hits krijgt maar tijdens de pieken wel heel veel hits heeft.

Tijdens de piek (load 0.8 tot 1.6) zie ik de interrupts 22 en 52 behoorlijk oplopen.

22 = IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb8
52 = PCI-MSI-edge eth0-rx-0
53 = PCI-MSI-edge eth0-rx-0

Vreemd, want cpu-util is 1-5%

[ Voor 8% gewijzigd door satya op 27-08-2015 18:20 ]

[satya]

Nog niet helemaal zeker, maar na het disabelen van USB komen de pieken tot nu toe niet voor
op mijn testserver.

(modprobe -r usb_storage)

[ Voor 7% gewijzigd door satya op 27-08-2015 22:12 ]

[satya]

OP een ander systeem werkt de truc niet, maar zie ik massa's interrupts (/proc/interrupts) op devices die er niet eens zijn. Hoe kan dit?

[ Voor 95% gewijzigd door satya op 27-08-2015 22:15 ]

[gekkie]

devices die er niet zijn .. of devices die je denkt niet te gebruiken ?
en is er een module/in kernel driver geladen voor die devices ?
En om wat voor devices gaat het eigenlijk ?

[satya]

Et is een ethernet interface actief, voor eth-0 tot 3 zijn er scripts aanwezig (/etc/sysconfig/network-scripts) en in zie interrupts bij 8 ethernet interfaces. In dmesg is er maar sprake van eth0-3.

59: 332567097 0 0 0 0 0 0 0 PCI-MSI-edge eth0-0
60: 18596633 4185280 5707963 31534688 21972550 133872071 388103752 495159534 PCI-MSI-edge eth0-1
61: 23204061 7066053 10701698 21695811 22281160 257667642 198977764 247942686 PCI-MSI-edge eth0-2
62: 20752834 10946930 13837613 49220412 53343631 196517134 555344010 388611221 PCI-MSI-edge eth0-3
63: 1 768500463 0 0 0 0 0 0 PCI-MSI-edge eth0-4
64: 1 0 1018555431 0 0 0 0 0 PCI-MSI-edge eth0-5
65: 1 0 0 516250753 0 0 0 0 PCI-MSI-edge eth0-6
66: 1 0 0 0 753087441 0 0 0 PCI-MSI-edge eth0-7

[Hero of Time]

Dat is allemaal op eth0, niet een andere interface. Ik zou haast zeggen dat die -x een ader is van de kabel, maar ik heb er te weinig kennis van om er echt iets van te kunnen zeggen. Maar probeer het eens met een andere kabel en switch poort. Wie weet.

[gekkie]

Wat is het .. intel srv-iov 4 of 8 ports controller / welke driver ?

Indien het idd 8 fysieke poorten zijn, zit er in poort 4 t/m 8 dan ook geen netwerkkabel ?

Maar goed er is neem ik aan flink netwerk verkeer, is er ook geen spike daarin om de 40 minuten in aantallen pakketjes ?

Zo te zien doet tie aan irq-balance behalve voor eth-0-0 / msi 59 en de niet actieve poorten.

Misschien een driver issue dat er zoveel irq's worden gerapporteerd voor poorten die eigenlijk
niet actief zouden moeten zijn.

En als laatste welke kernel versie draait de machine ?

[ Voor 5% gewijzigd door gekkie op 27-08-2015 23:22 ]

[satya]

Er zijn maar 4 poorten, en er zit er maar een aangesloten. De anderen zijn niet eens op gebracht.

Het lijkt er op dat er vanuit het systeem periodiek naar devices gekeken/gezocht wordt.

In de virtuele omgevingen zie ik Interrupts pieken tijdens de load piek op onderstaande devices:

ata1: PATA max UDMA/33 cmd 0x1f0 ctl 0x3f6 bmdma 0x10c0 irq 14
ata2: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0x10c8 irq 15

Dit is de virtuele cd-rom drive die door vmware wordt aangeboden.

[gekkie]

Ok .. dus wellicht dat tie 2 interrupts gebruikt per poort, eentje voor rx eentje voor tx.

Erhmm is het nou baremetal of een bak die draait op een hypervisor ?

[satya]

gekkie schreef op donderdag 27 augustus 2015 @ 23:30:
Ok .. dus wellicht dat tie 2 interrupts gebruikt per poort, eentje voor rx eentje voor tx.

Erhmm is het nou baremetal of een bak die draait op een hypervisor ?

Situatie is er zowel op bare metal als in vmware.

Net in de virtuele bak met 'moderobe -r ata_piix' de cdrom eruit geknald. kieken wat het wordt.

[ Voor 14% gewijzigd door satya op 28-08-2015 00:17 ]

[Dennism]

Heb je het probleem ook als je server hardware gebruikt, in plaats van een workstation? Geen idee of het hier van invloed is, maar bij VMware kan het goed zijn dat niet alle hardware in een Z400 op de HCL staat, misschien dat dit bij bepaalde Linux distro's die je gebruikt ook zo is?

[gekkie]

En welke kernel draai je erop .. recent exemplaar of een fijne oude server-distro-kernel ?

Neem aan dat die NIC een SR-IOV kaart is die gebruikt wordt om je VM's van een NIC te voorzien ipv een softwarematige-bridge/switch ?

Ben opzich nog niet helemaal overtuigd van het interrupt verhaal, opzich is een computer gebouwd om veel interrupts te verwerken.

[Kees]

Kun je zo veel mogelijk services uitzetten om te kijken of het dan ook nog voorkomt?

[satya]

Kernel: vmlinuz-2.6.32-431.el6.x86_64

[satya]

Kees schreef op vrijdag 28 augustus 2015 @ 11:02:
Kun je zo veel mogelijk services uitzetten om te kijken of het dan ook nog voorkomt?

Die oefening heb ik al gedaan, met de aangegeven commando's kom ik dan bij het OS zelf uit.

Bij de fysieke PC (HP Z400) heb ik het er uit kunnen krijgen door de usb modules niet te laden. Daar komt de piek niet meer voor.

In de virtuele omgeving zie ik 'iets' wat met de cdrom gaat babbelen, en lijkt de LOAD of io/wait te ontstaan omdat er niets in de cdrom zit en zelfs niet gemount is.

Het likt wel een soort crosstalk tussen devices/interrupts.

[johnkeates]

Is een nieuwere kernel een optie? En irqpoll?

[satya]

johnkeates schreef op vrijdag 28 augustus 2015 @ 13:14:
Is een nieuwere kernel een optie? En irqpoll?

Andere kernel is nog even geen optie. irqpol optie heb ik nu toegevoegd. Eens kijken wat er nu gebeurd.

[satya]

Resumerend.

Het lijkt in alle opzichten op IO congestie waar enkele kernels last van hebben gehad. Een update zit er niet in voor nu, maar een workaround brengt in alle configuraties de oplossing.

Aan de kernel wordt als extra parameters bij het opstarten meegeegeven "nohz=off highres=off".

Dit elimineerd de "spontane" load pieken en reduceerd de load tot nagenoeg 0.

Allen bedankt voor julie reacties hier.