Re: Problème load average Debian

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
>>>>>
>>>>>
>>>>>
>>
>>
>
>