Crashende GPU server, kan geen oorzaak vinden

[Kortfragje]

We hebben twee servers met de volgende specs:

code:

  1x X10DRG-OT+-CPU
  2x Xeon E5-2650V4
 128 GB geheugen
  2x Samsung SM863,240GB
 10x SEAGATE 2.5", 2TB, SATA3 6Gb/s,
  8x Geforce GTX 1080 Founders Edition
  1x Super Micro LSI00447 SAS3
Draait onder CentOS 7
Kernel is 3.10.0-514.21.2.el7.x86_64

Nu loopt de ene prima, maar de anders crash zonder duidelijke aanleiding (ook steeds vaker lijkt het). Eerst dacht ik dat het met het updaten van de kernel te maken had, maar dat lijkt ongerelateerd.

We kunnen geen verband vinden, met externe omstandigheden maar het lijkt wel vaker te gebeuren nu het warmer is.. (echter dit zien we nergens in de logs terug en is meer een gut feeling dan een echte correlatie)

Het volgende hebben we geprobeerd:
-smart checks van de SSD (in raid 1 boot) --> geen probleem
-smart checks van de HDDs (in raidz3) --> geen probleem
-scrub van HDDs --> geen probleem
-softwarematig uitschakelen van GPUs --> toch crash
-softwarematig uitschakelen van CPUs --> toch crash
-temperaturen & voltage monitoren --> geen probleem
-memtest --> geen probleem
-gpu burn --> geen probleem
-cpu & hdd burn --> geen probleem

/var/log/mcelog staat hier : https://pastebin.com/8kGi9ZHv
/var/log/messages staat hier : https://pastebin.com/BGGwKRPq
/var/log/boot.log staat hier : https://pastebin.com/dzrrEwpC
/var/log/dmesg staat hier: https://pastebin.com/p0erqXgC

temps:


irq:


cpu_load:


diskio:



ter vergelijking de graphs van de tweede stabiele server
temps:


irq:


cpu load:


diskio:


Ik kom er niet uit, ik begin te vermoeden dat het ofwel moederbord ofwel PSU is. Is er iemand die hier ervaring mee heeft en/ of dit herkent?

[MAX3400]

Je snapt zeker ook wel dat die PRTG (??) grafieken niet helpen? 1 of 2 balken per dag; daar is niks aan te vinden. Beetje van "ja, ergens in een interval van 12 uur gaat er iets fout".

Wat je zelf ook al had gevonden na het doorlezen van de eerste 20 regels van je log-files:

DESCRIPTION
X86 CPUs report errors detected by the CPU as machine check events (MCEs). These can be data corruption detected in the CPU caches, in main memory by an integrated memory controller, data transfer errors on the front side bus or CPU interconnect or other internal errors. Possible causes can be cosmic radiation, instable power supplies, cooling problems, broken hardware, or bad luck.

Most errors can be corrected by the CPU by internal error correction mechanisms. Uncorrected errors cause machine check exceptions which may panic the machine.

When a corrected error happens the x86 kernel writes a record describing the MCE into a internal ring buffer available through the /dev/mcelog device mcelog retrieves errors from /dev/mcelog, decodes them into a human readable format and prints them on the standard output or optionally into the system log.

[Kortfragje]

Dank voor je reactie. Figuren zijn toegevoegd als extra.

Ja inderdaad, maar in de messages lijkt het juist weer op een HDD fout te wijzen :

code:

Jul 23 03:47:17 trajanus kernel: sd 11:0:2:0: attempting task abort! scmd(ffff88201b9d5340)
Jul 23 03:47:17 trajanus kernel: sd 11:0:2:0: [sdg] CDB: Write(10) 2a 00 07 4a 74 00 00 04 00 00
Jul 23 03:47:17 trajanus kernel: scsi target11:0:2: handle(0x000b), sas_address(0x4433221102000000), phy(2)
Jul 23 03:47:17 trajanus kernel: scsi target11:0:2: enclosure_logical_id(0x500062b20139bac0), slot(0)
Jul 23 03:47:17 trajanus kernel: scsi target11:0:2: enclosure level(0x0000),connector name(    #003)
Jul 23 03:47:17 trajanus kernel: sd 11:0:2:0: task abort: SUCCESS scmd(ffff88201b9d5340)
Jul 23 03:47:17 trajanus kernel: sd 11:0:2:0: attempting task abort! scmd(ffff88201a325c00)
Jul 23 03:47:17 trajanus kernel: sd 11:0:2:0: [sdg] CDB: Write(10) 2a 00 07 4a 78 00 00 04 00 00
Jul 23 03:47:17 trajanus kernel: scsi target11:0:2: handle(0x000b), sas_address(0x4433221102000000), phy(2)
Jul 23 03:47:17 trajanus kernel: scsi target11:0:2: enclosure_logical_id(0x500062b20139bac0), slot(0)
Jul 23 03:47:18 trajanus kernel: scsi target11:0:2: enclosure level(0x0000),connector name(    #003)
Jul 23 03:47:18 trajanus kernel: sd 11:0:2:0: task abort: SUCCESS scmd(ffff88201a325c00)
Jul 23 03:47:18 trajanus kernel: sd 11:0:2:0: attempting task abort! scmd(ffff8820162672c0)
Jul 23 03:47:18 trajanus kernel: sd 11:0:2:0: [sdg] CDB: Write(10) 2a 00 07 4a 7c 00 00 04 00 00
Jul 23 03:47:18 trajanus kernel: scsi target11:0:2: handle(0x000b), sas_address(0x4433221102000000), phy(2)
Jul 23 03:47:18 trajanus kernel: scsi target11:0:2: enclosure_logical_id(0x500062b20139bac0), slot(0)
Jul 23 03:47:18 trajanus kernel: scsi target11:0:2: enclosure level(0x0000),connector name(    #003)
Jul 23 03:47:18 trajanus kernel: sd 11:0:2:0: task abort: SUCCESS scmd(ffff8820162672c0)

vandaar dat ik dacht aan PSU / mobo.

[MAX3400]

Kortfragje schreef op dinsdag 25 juli 2017 @ 20:40:
Dank voor je reactie. Figuren zijn toegevoegd als extra.

Ja inderdaad, maar in de messages lijkt het juist weer op een HDD fout te wijzen :
...
vandaar dat ik dacht aan PSU / mobo.

Ik volg je niet maar mijn kennis van Linux is dan ook beperkt.

Op het moment dat er specifiek 1 disk wordt genoemd in de array die issues lijkt te hebben, zou ik allicht beginnen met de data-kabel te vervangen en/of de power-kabel van die disk.

Indien het een RAID1/5/6/10 array is, kan je ook de disk loshalen en kijken of de errors wegblijven; dan weet je dat de disk defect is. Komen de fouten terug, dan kan het de controller, controller-memory of de data-bus zijn.

En de data-bus kan een defect zijn in CPU, PSU, RAM, moederbord.

[Kortfragje]

Nou ik bedoelde, omdat fouten in de ene log op cpu/psu/mem wijzen en de andere log op hdd/controller/psu is het wellicht de psu.

Maar klopt idd vd week wil ik het systeem herbouwen met 1 disk die goed is, met vervangen kabels, om zo het probleem te proberen te isoleren.

Ik hoopte dat uit deze logs al een duidelijke oorzaak zou komen waardoor ik meteen met oorzaak kan RMA'en en niet trial and error hoef te troubkeshooten.

Machine valt nog onder garantie. Iig dank voor je antwoorden.