Auteur Sujet: Linux: Réaliser un test de débit descendant/montant avec CURL (Lu 80454 fois)

vivien · « **Réponse #60 le:** 16 avril 2023 à 08:56:11 »

Désolé, Apache a été tué par un manque de mémoire dans ce qui ressemble à une attauqe. Impréssionant de voir un OOM sur un serveur avec 32 Go de ram (mais c'est vrai que je ne mets que quelques Go de SWAP)

apache2.service: A process of this unit has been killed by the OOM killer. apache2.service: Killing process 1577912 (apache2) with signal SIGKILL. apache2.service: Killing process 1578320 (apache2) with signal SIGKILL. apache2.service: Killing process 1609348 (apache2) with signal SIGKILL. apache2.service: Failed with result 'oom-kill'. apache2.service: Consumed 1w 3d 19h 22min 8.114s CPU time.

C'est relancé.

piwik · « **Réponse #61 le:** 16 avril 2023 à 11:34:26 »

Super ca fonctionne parfaitement a present. merci

m@rco123 · « **Réponse #62 le:** 30 avril 2023 à 07:37:51 »

perso,, je me suis fais ca depuis la chute de bouygues.testdebit.info et de speedtest.cli

Citer

#!/bin/bash

# Creation du fichier de mesure
echo "HEURE DL UL PING" > speedtest.csv

# comme ca, un " ctrl c " arrete tout
for i in `seq 1 1 100000`;
do

# calcul download
#dl=($(curl -o /dev/null http://bouygues.testdebit.info/100M.iso 2>&1))
dl=($(curl -o /dev/null http://paris.testdebit.info/100M.iso 2>&1))

# calcul upload
#ul=($(curl --max-time 60 -4 -w %{size_upload} -o /dev/null -F "file=@/tmp/temp.iso" http://bouygues.testdebit.info/ul/ 2>&1))
ul=($(curl --max-time 60 -4 -w %{size_upload} -o /dev/null -F "file=@/tmp/temp.iso" http://paris.testdebit.info/ul/ 2>&1))

# calcul ping
pg=$(LC_ALL=C ping -c1 1.1.1.1 | sed -e '/time=/!d' -e 's|^.*time=$[\.[:digit:]]\+$ ms$|\1|')

# heure
dte=$(date "+%T")

# inscription dans le fichier et à l'ecran
echo $dte "${dl[-6]:0:-1}" "${ul[-6]:0:-1}" $pg >> speedtest.csv
echo $i $dte "${dl[-6]:0:-1}" "${ul[-6]:0:-1}" $pg

# pour 1 minute entre chaque test à modifier selon usage
sleep 1m

done

vivien · « **Réponse #63 le:** 30 avril 2023 à 15:35:02 »

Même problème que la dernière fois, j'ai relancé.

Il faut(t que je comprenne la cause du probléme.

fregate84 · « **Réponse #64 le:** 06 juillet 2023 à 20:03:55 »

Les fichiers 1Go et 10Go semble down, non ?

- Exemple avec un fichier de 1 Go : curl -o /tmp/temp.iso https://bouygues.testdebit.info/1G.iso
- Exemple avec un fichier de 10 Go : curl -o /tmp/temp.iso https://bouygues.testdebit.info/10G.iso

vivien · « **Réponse #65 le:** 06 juillet 2023 à 20:47:34 »

Encore apache qui a été tué :

Code: [Sélectionner]

juil. 03 12:28:14 nperf1-ntr systemd[1]: apache2.service: A process of this unit has been killed by the OOM killer.
juil. 03 12:28:15 nperf1-ntr apachectl[510545]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using ::1. Set the 'ServerName' directive globally t>
juil. 03 12:28:26 nperf1-ntr systemd[1]: apache2.service: Failed with result 'oom-kill'.
juil. 03 12:28:26 nperf1-ntr systemd[1]: apache2.service: Consumed 17h 12min 57.694s CPU time.

Je ne comprends pas pourquoi. J'ai modifié la configuration d'Apache pour limiter les process, cela ne change rien. C'est le seul serveur où j'ai ce problème, et il a pourtant 32 Go de ram.

En désespoir de cause, j'ai modifié vm.swappiness = 1 par vm.swappiness = 10 toutefois, j'aimerais bien comprendre la root cause.

J'ai redémarré le serveur.

hwti · « **Réponse #66 le:** 07 juillet 2023 à 01:15:44 »

Il faut regarder les logs kernel sur l'oom-killer : est-ce qu'il y avait beaucoup de processus, ou au contraire un processus apache consommant énormément de RAM ?

Actuellement quand un des processus est tué par le kernel, systemd arrête le service.
Donc il pourrait être utile de configurer le service systemd avec OOMPolicy=continue.
S'il s'agit d'un processus fils, seuls les clients gérés par celui-ci seraient déconnectés, le serveur resterait fonctionnel.
Mais ça pourrait ne pas être pris en compte, cf https://github.com/systemd/systemd/issues/25376.

vivien · « **Réponse #67 le:** 07 juillet 2023 à 08:38:51 »

L'événement oom-killer s'est produit le 3 juillet, là où on voit un changement brutal de l'utilisation de la mémoire.

/tmp est en ramdisque de même que /var/log/apache2 (cela limite les écritures sur le SSD) mais je ne vois rien de particulier à ce moment-là.

kgersen · « **Réponse #68 le:** 07 juillet 2023 à 09:45:36 »

C'est peut-etre un bug ou l'exploitation d'un bug. il est a jour ton Apache (2.4.57 a ce jour) ainsi que les autres composants utilisés (php,ssl,un mod particulier)?

vivien · « **Réponse #69 le:** 07 juillet 2023 à 10:03:33 »

Oui, Ubuntu 22.04 LTS à jour et pas de composants externes ou particuliers.

Le serveur est par contre ouvert dur de très nombreux ports, pour permettre des tests de neutralité.

kgersen · « **Réponse #70 le:** 07 juillet 2023 à 11:17:00 »

Citation de: vivien le 07 juillet 2023 à 10:03:33

Oui, Ubuntu 22.04 LTS à jour et pas de composants externes ou particuliers.

si tu ne dépend que de Ubuntu pour les maj tu n'aura pas grand chose a jour...hormis les CVE importantes.

dixit https://packages.ubuntu.com/km/jammy/apache2
-> t'en donc en " 2.4.52 : Released on December 20, 2021" au niveau fonctionnalités/bugs non critiques.

et https://bugs.launchpad.net/ubuntu/+source/apache2/2.4.52-1ubuntu4.6 pour le dernier patch critiques/secu.

bon apres ce n'est peut-être pas un bug logiciel Apache ou Php.

hwti · « **Réponse #71 le:** 08 juillet 2023 à 00:43:19 »

Citation de: vivien le 07 juillet 2023 à 08:38:51

L'événement oom-killer s'est produit le 3 juillet, là où on voit un changement brutal de l'utilisation de la mémoire.

/tmp est en ramdisque de même que /var/log/apache2 (cela limite les écritures sur le SSD) mais je ne vois rien de particulier à ce moment-là.

Là ce qu'on voit c'est un pic pour "Apps", et la taille de shmem (les fichiers de test dans /tmp, qu'on pourrait réduire un peu).
Ce qu'il faudrait regarder, ce sont les logs kernel (via journalctl probablement), l'oom-killer donne un certain nombre d'informations sur l'occupation mémoire, en détaillant le RSS pour chaque processus.