Tâche #35303
Scénario #35651: Problème squid en version EOLE 2.8
Plantage récurent squid sur Amon 2.8.1
100%
Description
Bonjour,
Notre établissement de test rencontre des plantages récurent sur squid (au moins 4 fois par jour).
Le fichier cache.log contient les lignes suivantes à répétitions:
2023/03/15 10:58:09 kid1| suspending ICAP service for too many failures
2023/03/15 10:58:09 kid1| optional ICAP service is suspended: icap://127.0.0.1:1340/request [down,susp,fail2]
2023/03/15 10:58:10 kid1| suspending ICAP service for too many failures
2023/03/15 10:58:10 kid1| optional ICAP service is suspended: icap://127.0.0.1:1340/response [down,susp,fail2]
2023/03/15 10:58:10| Pinger exiting.
2023/03/15 10:58:16| suspending ICAP service for too many failures
2023/03/15 10:58:16| optional ICAP service is suspended: icap://127.0.0.1:1342/request [down,susp,fail2]
2023/03/15 10:58:24| optional ICAP service is down after an options fetch failure: icap://127.0.0.1:1342/response [down,!opt]
2023/03/15 10:58:31 kid1| ipcacheParse No Address records in response to 'ipv6.msftconnecttest.com'
2023/03/15 10:58:31 kid1| ipcacheParse No Address records in response to 'ipv6.msftconnecttest.com'
2023/03/15 10:59:24| optional ICAP service is up: icap://127.0.0.1:1342/response [up]
2023/03/15 10:59:26| optional ICAP service is up: icap://127.0.0.1:1342/request [up]
2023/03/15 10:59:31 kid1| optional ICAP service is up: icap://127.0.0.1:1340/request [up]
2023/03/15 10:59:32 kid1| optional ICAP service is up: icap://127.0.0.1:1340/response [up]
2023/03/15 10:59:34 kid1| kick abandoning local=10.18.0.1:3128 remote=10.18.18.3:56678 FD 927 flags=1
2023/03/15 10:59:38 kid1| kick abandoning local=10.18.0.1:3128 remote=10.18.5.40:49590 FD 416 flags=1
2023/03/15 10:59:38 kid1| kick abandoning local=10.18.0.1:3128 remote=10.18.15.12:56448 FD 474 flags=1
2023/03/15 10:59:39 kid1| kick abandoning local=10.18.0.1:3128 remote=10.18.21.4:55683 FD 827 flags=1
2023/03/15 10:59:40 kid1| kick abandoning local=10.18.0.1:3128 remote=10.18.21.4:55684 FD 835 flags=1
2023/03/15 10:59:40 kid1| kick abandoning local=10.18.0.1:3128 remote=10.18.21.4:55688 FD 842 flags=1
2023/03/15 10:59:41 kid1| kick abandoning local=10.18.0.1:3128 remote=10.18.21.4:55690 FD 845 flags=1
Avez-vous une solution à me proposer?
Cordialement,
Historique
#1 Mis à jour par Joël Cuissinat il y a environ 3 ans
- Lié à Tâche #35009: EOLE 2.8.1.1 : squid crash ajouté
#2 Mis à jour par Joël Cuissinat il y a plus de 2 ans
- Lié à Scénario #35651: Problème squid en version EOLE 2.8 ajouté
#3 Mis à jour par Joël Cuissinat il y a plus de 2 ans
- Lié à Scénario #35651: Problème squid en version EOLE 2.8 supprimé
#4 Mis à jour par Joël Cuissinat il y a plus de 2 ans
- Tâche parente mis à #35651
#5 Mis à jour par Joël Cuissinat il y a plus de 2 ans
- Lié à Tâche #35009: EOLE 2.8.1.1 : squid crash supprimé
#6 Mis à jour par Benjamin Bohard il y a plus de 2 ans
Le message d’erreur implique potentiellement e2guardian (qui fournit le service ICAP que Squid ne parvient pas à contacter).
Est-ce que e2guardian remonte des erreurs lorsque le service ICAP est vu comme suspendu par Squid ?
#7 Mis à jour par James HORLEY il y a plus de 2 ans
Je viens de revenir de congé et nos établissements sont fermés.
On vous remonte l'information dans la semaine du 15 janvier.
#8 Mis à jour par James HORLEY il y a environ 2 ans
- Fichier log_amon.7z ajouté
Il n'y a pas d'erreur dans les logs e2guardian lorsque le service ICAP est suspendu.
Je vous joins 3 fichiers de log (cache.log, squid1.info.log, e2guardian0.info.log) pour info.
#9 Mis à jour par Joël Cuissinat il y a plus d'un an
Bonjour,
Avez-vous essayé d'augmenter les ressources disponibles pour Squid ?
Dans l'onglet "Filtrage web" en mode expert moi je passe "Nombre de processus disponibles pour traiter les connexions" à 10000.
Éventuellement on peut également augmenter le "Nombre de processus associés au module d'authentification NTLM" dans l'onglet "Squid".
Cordialement,
#10 Mis à jour par James HORLEY il y a plus d'un an
Bonjour,
J'ai recontacté l'établissement aujourd'hui et il semblerait que le problème ne soit plus aussi récurent.
Soit le problème s'est résolu, soit il est visible surtout dans les périodes d'évaluations (Pix, Ev@lang).
Est-ce qu'il serait possible de me confirmer le format du fichier dstats.log? Cela me permettra d'évaluer si le problème vient de là s'il se reproduit.
Voici ce que j'ai trouvé:
The first column is time in Unix format.
The second column is the maximum number of httpworkers that you have available. This is what you set in e2guardian.conf.
The third column - busy - is how many httpworkers you have in use.
The next column httpwQ is http workers queue and is telling you how many workers are waiting for an httpworker thread to be released. As you have maxed out all your httpworkers, you have a queue.
Cordialement,
#11 Mis à jour par Joël Cuissinat il y a plus d'un an
À partir d'EOLE 2.8.1, nous avons activé la génération des fichiers dstats par e2guardian (#33352) mais n'avons fait aucun tuning ni exploitation spécifique.
Ils doivent donc respecter le format par défaut ;)
#12 Mis à jour par Joël Cuissinat il y a plus d'un an
- Statut changé de Nouveau à Fermé
- % réalisé changé de 0 à 100
- Restant à faire (heures) mis à 0.0
Pour fermeture du scénario.
@james : n’hésite pas à nous recontacter si tu as du nouveau.