CentOS 6.5 server loopt vast

[hommer]

Ik heb een Dell Optiplex T310 staan die CentOS 6.5 draait, het ding draait als secondary mailserver voor een bedrijf. Zeer onregelmatig, ongeveer eens in de twee week (nu ook weer eens), besluit het ding volledig vast te lopen.

Ik kan er echter niet achter komen waarom het ding vast loopt.

De kerneldump op het scherm is erg lang en zijn niet terug te scrollen na het moment van vastlopen. De logging meldt helemaal niets zinnigs; de laatste logging voor het vastlopen is vaak wisselend en niet consequent. Ik heb wel eens systemen gehad die nog iets van kernel dump info naar de syslog wisten te krijgen, deze stopt simpelweg. De kernel meldt bij het booten niets dat duid op problemen met het systeem.

Het systeem lijkt het meest vast te lopen tijdens een backup naar LTO. Ik heb daarom de SCSI kaart al eens verplaatst naar een ander slot en een andere SCSI kaart er in gezet, maar ook zonder veel succes. Hij geeft er de voorkeur aan om van vrijdag op zaterdag vast te lopen, maar dan weer niet op regelmatige momenten en soms vind hij ook geen bezwaar om door de week er eens mee op te houden.

Ik heb (gelukkig?) zeer weinig ervaring met het vaststellen van systeem crashes en ben dus op zoek naar wat suggesties, leesvoer, tips, whatever.

[ Voor 3% gewijzigd door hommer op 12-04-2014 09:30 ]

[Hero of Time]

Je hebt dus al door dat het systeem er na ongeveer 2 weken uptime uit klapt. Wat als je 1x per week de machine een reboot geeft? Dan kan je eventuele memoryleaks uitsluiten, of andere dingen die lange tijd nodig hebben om onderuit te gaan. Ideaal is het niet, maar je bent dan iig bezig met troubleshooting.

Dan moet je nog gaan kijken hoe de server is ingericht. Je zegt dat 't een mailserver is, is die van butienaf te benaderen? Kan je er vrij op relayen (wil je niet!), andere zaken die zijn ingesteld, zoals iptables?

[CAPSLOCK2000]

Je kan de syslog de logs via het netwerk naar een andere server laten sturen, misschien kun je zo de crashlogs vast leggen.

[johnkeates]

Duidt meestal op hardware problemen of te weinig ram/swap. Met je SCSI kaart zou het kunnen duiden op slechte SCSI configuratie en/of drivers.

Je zal inderdaad betere logging moeten regelen, en het probleem moeten kunnen reproduceren.

Als je zelf een backup start, krijg je dan niet hetzelfde probleem? Hoe groot is je swap?

[hommer]

Het is een Postfix server, natuurlijk relayt deze alleen de benodigde domeinen. Hij doet diverse 'backup' zaken; secondary interne DNS (powerDNS), DHCPd secondary en MySQL replication slave (voor Postfix en PowerDNS). Maar allemaal niet spannend groot.
Het systeem heeft 4G Ram een 4G swap, maar gebruikt gemiddeld rond de 3G Ram en geen tot nauwlijks swap. Hij heeft slechts twee SATA schijven op een PERC6 controller. Systeem load is zo goed als 0.
Het systeem draait elke door de weekse nacht de zelfde full backup. Dat het wat te maken heeft met de crash is slechts een vermoeden.

Je kan de syslog de logs via het netwerk naar een andere server laten sturen, misschien kun je zo de crashlogs vast leggen.

Dat is ook nog wel een idee inderdaad. Maar omdat het zo abrupt stopt telkens vraag ik me af of het wat oplevert, ik ga het denk ik wel proberen.

Duidt meestal op hardware problemen

Daar ben ik ook het meest bang voor. maar kom er maar eens achter wat er nou werkelijk roet in het eten gooit. Hardware wisselen en maar weer afwachten. En hoe lang wacht je dan, hé...

Ik heb in tussentijd bedacht dat ik de LTO drive maar eens in een ander systeem ga zetten en via NFS backups ga trekken.

Heeft iemand nog ervaring met analyse van kdump output? In principe moet dat ook in te schakelen zijn, misschien levert dat nog wat op.

[ Voor 13% gewijzigd door hommer op 12-04-2014 19:04 ]

[Super_ik]

CAPSLOCK2000 schreef op zaterdag 12 april 2014 @ 14:35:
Je kan de syslog de logs via het netwerk naar een andere server laten sturen, misschien kun je zo de crashlogs vast leggen.

Je kan ook de kernel console op de een seriele poort zetten, en dan op een andere bak die seriele poort loggen.

[hommer]

Super_ik schreef op zaterdag 12 april 2014 @ 19:12:
[...]

Je kan ook de kernel console op de een seriele poort zetten, en dan op een andere bak die seriele poort loggen.

Goed idee, want daar staat wel wat op inderdaad! Eens kijken dat ik dat voor elkaar krijg

[ Voor 6% gewijzigd door hommer op 12-04-2014 21:59 ]

[Rainmaker]

Draai de full backup eens 2 weken lang op zondag en kijk of het tijdstip verschuift.

Geeft je een ieder geval een indicatie waar het mee te maken kan hebben...

[Verwijderd]

Je kan ook gewoon eens een diskscan of memoryscan doen. Logs hoef je daar niet voor te gebruiken. En dan kan je snel uitsluiten of daar iets mee mis is.

[init6]

Wat voor monitoring tools gebruik je?

[u_nix_we_all]

Dat zou wel eens een slecht reepje geheugen kunnen zijn. Dat het tijdstip vaak samenhangt met het maken van je backup is logisch, als je bedenkt dat dat een geheugenintensief proces is.
Begin (dat is sowieso aan te raden) met een memory check. Een nachtje laten draaien met memtest86 lijkt me verstandig.

[hommer]

ter informatie; Ik heb het backup moment verplaatst van vrijdagavond naar zaterdagavond en sinds die tijd is het systeem niet meer vastgelopen. Dat is nu ruim twee week geleden. De load logging met Munin lijkt niet noemenswaardig anders rond die tijd dus ik wacht nog even af.
* hommer klopt op ongeverfd hout....