Comment déterminer la cause d'un crash système?

Mon serveur se bloque environ une fois par semaine et ne laisse aucun indice sur la cause de ce problème. J'ai vérifié /var/log/messageset il arrête juste d'enregistrer à un moment donné et démarre à partir des informations de publication de l'ordinateur lorsque j'effectue un redémarrage dur.

Y a-t-il quelque chose que je peux vérifier ou un logiciel que je peux installer qui peut en déterminer la cause?

J'utilise CentOS 7.

Voici la seule erreur / problème dans mon /var/log/dmesg: https://paste.netcoding.net/cosisiloji.log

[    3.606936] md: Waiting for all devices to be available before autodetect
[    3.606984] md: If you don't use raid, use raid=noautodetect
[    3.607085] md: Autodetecting RAID arrays.
[    3.608309] md: Scanned 6 and added 6 devices.
[    3.608362] md: autorun ...
[    3.608412] md: considering sdc2 ...
[    3.608464] md:  adding sdc2 ...
[    3.608516] md: sdc1 has different UUID to sdc2
[    3.608570] md:  adding sdb2 ...
[    3.608620] md: sdb1 has different UUID to sdc2
[    3.608674] md:  adding sda2 ...
[    3.608726] md: sda1 has different UUID to sdc2
[    3.608944] md: created md2
[    3.608997] md: bind<sda2>
[    3.609058] md: bind<sdb2>
[    3.609116] md: bind<sdc2>
[    3.609175] md: running: <sdc2><sdb2><sda2>
[    3.609548] md/raid1:md2: active with 3 out of 3 mirrors
[    3.609623] md2: detected capacity change from 0 to 98520989696
[    3.609685] md: considering sdc1 ...
[    3.609737] md:  adding sdc1 ...
[    3.609789] md:  adding sdb1 ...
[    3.609841] md:  adding sda1 ...
[    3.610005] md: created md1
[    3.610055] md: bind<sda1>
[    3.610117] md: bind<sdb1>
[    3.610175] md: bind<sdc1>
[    3.610233] md: running: <sdc1><sdb1><sda1>
[    3.610714] md/raid1:md1: not clean -- starting background reconstruction
[    3.610773] md/raid1:md1: active with 3 out of 3 mirrors
[    3.610854] md1: detected capacity change from 0 to 20970405888
[    3.610917] md: ... autorun DONE.
[    3.610999] md: resync of RAID array md1
[    3.611054] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
[    3.611119] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for resync.
[    3.611180] md: using 128k window, over a total of 20478912k.
[    3.611244]  md1: unknown partition table
[    3.624786] EXT3-fs (md1): error: couldn't mount because of unsupported optional features (240)
[    3.627095] EXT2-fs (md1): error: couldn't mount because of unsupported optional features (244)
[    3.630284] EXT4-fs (md1): INFO: recovery required on readonly filesystem
[    3.630341] EXT4-fs (md1): write access will be enabled during recovery
[    3.819411] EXT4-fs (md1): orphan cleanup on readonly fs
[    3.836922] EXT4-fs (md1): 24 orphan inodes deleted
[    3.836975] EXT4-fs (md1): recovery complete
[    3.840557] EXT4-fs (md1): mounted filesystem with ordered data mode. Opts: (null)

Vous pouvez vérifier le fichier dmesg à /var/log/dmesg, qui enregistre les messages du noyau. Le journal des messages ne fait que consigner les messages des services et des applications et si vous avez une erreur de noyau, les services et les applications cesseront de fonctionner, mais l'erreur de noyau est toujours enregistrée dans dmesg.

Si vous avez crashkernel/kdumpinstallé et activé, vous devriez être en mesure d'examiner le noyau en panne avec relativement facile à l'aide de l' crashutilitaire. Par exemple, en supposant que vous avez planté les vidages du noyau sont enregistrés sous /var/crash: crash /var/crash/2009-07-17-10\:36/vmcore /usr/lib/debug/lib/modules/uname -r /vmlinux.

Jetez un œil ici et ici pour plus de détails.

• test de mémoire du bios
• test du disque dur du bios
• Vérifier le journal du lecteur intelligent smartctl /dev/sda -a
• Tests de conduite intelligents
• laisser dmesg -wHcourir dans une fenêtre