En général, il est bon de le laisser tourner quelques heures, pour
tenir compte de l'échauffement. A priori, ça se présente bien.
Le ven. 26 juil. 2019 à 16:34, Hugues Levasseur
<hugues.levasseur@???> a écrit :
>
> Patrice :
>
> J'ai trouvé ça
>
> #>memtester 1024 5
> memtester version 4.3.0 (64-bit)
> Copyright (C) 2001-2012 Charles Cazabon.
> Licensed under the GNU General Public License version 2 (only).
>
> pagesize is 4096
> pagesizemask is 0xfffffffffffff000
> want 1024MB (1073741824 bytes)
> got 1024MB (1073741824 bytes), trying mlock ...locked.
> Loop 1/5:
> Stuck Address : ok
> Random Value : ok
> Compare XOR : ok
> Compare SUB : ok
> Compare MUL : ok
> Compare DIV : ok
> Compare OR : ok
> Compare AND : ok
> Sequential Increment: ok
> Solid Bits : ok
> Block Sequential : ok
> Checkerboard : ok
> Bit Spread : ok
> Bit Flip : ok
> Walking Ones : ok
> Walking Zeroes : ok
> 8-bit Writes : ok
> 16-bit Writes : ok
>
> Les 5 boucles sont toute à OK
>
> Tu penses que le test sufit à écarter un éventuel problème de RAM ?
>
>
> On 26/07/2019 15:40, Hugues Levasseur wrote:
> > Ah, ok
> >
> > ...
> >
> > Memtest c'est un truc qui se fait au boot; non ?
> >
> > Comment on fait pour accéder au boot d'un serveur dédié chez un hébergeur
> > (online.net) ?
> >
> >
> > Pas compris la remarque sur npm.
> >
> > Il semble fonctionner correctement (en tout cas quand je fais un "npm install"
> > ) et, de plus, il n'est pas lié à Apache
> >
> >
> > On 26/07/2019 15:19, Patrice Karatchentzeff wrote:
> >> Je voulais dire memtest... pour tester les barrettes...
> >>
> >> Manifestement, ta cond d'Apache est moisie. Tu utilises mpm sur une
> >> conf qui ne la supporte pas...
> >>
> >> Le ven. 26 juil. 2019 à 12:09, Hugues Levasseur
> >> <hugues.levasseur@???> a écrit :
> >>> Patrick,
> >>>
> >>> La log apache en PJ
> >>>
> >>> Le memckek (pas sur d'avoir bien compris ce que tu voulais)
> >>>
> >>> 11:56:20 #>valgrind --tool=memcheck /usr/sbin/apache2
> >>> ==26185== Memcheck, a memory error detector
> >>> ==26185== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> >>> ==26185== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright
> >>> info
> >>> ==26185== Command: /usr/sbin/apache2
> >>> ==26185==
> >>> [Fri Jul 26 11:56:34.504742 2019] [core:warn] [pid 26185] AH00111: Config
> >>> variable ${APACHE_RUN_DIR} is not defined
> >>> apache2: Syntax error on line 80 of /etc/apache2/apache2.conf:
> >>> DefaultRuntimeDir
> >>> must be a valid directory, absolute or relative to ServerRoot
> >>> ==26185==
> >>> ==26185== HEAP SUMMARY:
> >>> ==26185== in use at exit: 4,293 bytes in 10 blocks
> >>> ==26185== total heap usage: 28 allocs, 18 frees, 17,698 bytes allocated
> >>> ==26185==
> >>> ==26185== LEAK SUMMARY:
> >>> ==26185== definitely lost: 0 bytes in 0 blocks
> >>> ==26185== indirectly lost: 0 bytes in 0 blocks
> >>> ==26185== possibly lost: 0 bytes in 0 blocks
> >>> ==26185== still reachable: 4,293 bytes in 10 blocks
> >>> ==26185== suppressed: 0 bytes in 0 blocks
> >>> ==26185== Rerun with --leak-check=full to see details of leaked memory
> >>> ==26185==
> >>> ==26185== For counts of detected and suppressed errors, rerun with: -v
> >>> ==26185== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> >>>
> >>>
> >>> Merci
> >>>
> >>>
> >>> On 26/07/2019 11:05, Patrice Karatchentzeff wrote:
> >>>> Salut
> >>>>
> >>>> Donne les logs apache correspondant.
> >>>>
> >>>> Ça sent assez mauvais ce genre de message du noyau. Si tu peux, fais
> >>>> une passe de memcheck sur les barrettes de mémoire.
> >>>>
> >>>>
> >>>> Le ven. 26 juil. 2019 à 11:00, Hugues Levasseur
> >>>> <hugues.levasseur@???> a écrit :
> >>>>> Salut la guilde,
> >>>>>
> >>>>>
> >>>>> J'ai un mystère ... bien mystérieux* sur un serveur Debian.
> >>>>>
> >>>>> Si quelqu'un à une idée pour m'aider à comprendre le problème : je suis
> >>>>> preneur.
> >>>>>
> >>>>>
> >>>>> D'avance merci
> >>>>>
> >>>>> Hugues
> >>>>>
> >>>>> * Principalement parce que je suis développeur, pas administrateur
> >>>>> système :-)
> >>>>>
> >>>>> ---------------------------------------------------
> >>>>>
> >>>>> *Le contexte : *
> >>>>>
> >>>>> 2 serveurs dédiés (Debian 9), sur lesquels tournent des applications en
> >>>>> Apache /
> >>>>> PHP / MariaDB
> >>>>>
> >>>>> L'un chez OVH, l'autre chez Online.
> >>>>>
> >>>>> Ils sont synchronisés entre eux par GlusterFS pour un point de montage
> >>>>> commun et
> >>>>> par le plugin Galera de MariaDB pour les bases
> >>>>>
> >>>>> Tout roule depuis plus d'1 an
> >>>>>
> >>>>> Les serveurs sont à jour de mises à jour (dépôts stretch main)
> >>>>>
> >>>>> *
> >>>>> *
> >>>>>
> >>>>> *Les symptômes : *
> >>>>>
> >>>>> Depuis 3 jours, Le serveur B, à 3h du matin ... part en couilles sucette.
> >>>>>
> >>>>> La surveillance Nagios (sur une 3eme machine) me lève des alarmes de LOAD
> >>>>> AVERAGE CRITICAL : 15.02,15.06,15.00
> >>>>>
> >>>>> Et, bien sur, les applications deviennent - quasiment - inutilisables.
> >>>>>
> >>>>> A chaque fois un reboot résous le problème ... jusqu’à la prochaine fois
> >>>>>
> >>>>>
> >>>>> *Les - tentatives - d'analyse :*
> >>>>>
> >>>>> - Aucune tache cron ne se lance à 3h du mat' (Y'en a chaque heure, mais
> >>>>> aucune
> >>>>> spécifiquement à 3h)
> >>>>>
> >>>>> - htop voit le load average, mais pas les process en cause
> >>>>>
> >>>>> Pour essayer de comprendre ce qui se passe à à 3h du mat :
> >>>>>
> >>>>> - cat /var/log/syslog.1 |grep "Jul 25 03:" > syslog.txt
> >>>>>
> >>>>> Ce que je comprends, c'est que Apache se met à redémarrer en boucle
> >>>>> (Lignes 5 &
> >>>>> 127 de la PJ)
> >>>>>
> >>>>>
> >>>>> je met aussi tout les /var/log/* qui ont "quelque chose à 3h du mat'" :
> >>>>>
> >>>>> - cat /var/log/message |grep "Jul 25 03:" > message.txt
> >>>>>
> >>>>> - cat /var/log/kern.log |grep "Jul 25 03:" > kern.log.txt
> >>>>>
> >>>>> - cat /var/log/daemon.log |grep "Jul 25 03:" > daemon.log.txt
> >>>>>
> >>>>>
> >>>>>
> >>
> >>
> >
> >
>
--
|\ _,,,---,,_ Patrice KARATCHENTZEFF
ZZZzz /,`.-'`' -. ;-;;,_ mailto:patrice.karatchentzeff@gmail.com
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_)
