Comment les fuites de descripteurs de fichiers diffèrent-elles des pics légitimes de connexions sur un serveur domestique ?

Un pic légitime de descripteurs de fichiers augmente avec les connexions actives ou le travail ouvert et diminue après la fin de ce travail. Une fuite de descripteurs maintient les ressources ouvertes après que l’application n’en a plus besoin, donc le compteur développe une ligne de base croissante qui finit par atteindre la limite du processus, service, conteneur ou système.

La distinction est importante car les deux conditions peuvent produire la même erreur finale. Augmenter la limite de descripteurs peut être une planification correcte de la capacité pour un proxy inverse très sollicité, mais cela ne fait que retarder l’échec lorsque les sockets, fichiers, pipes ou observateurs ne sont jamais libérés.

Quel motif définit un pic légitime de descripteurs ?

Un pic normal suit la concurrence de la charge de travail. les pics légitimes suivent la charge active, puis diminuent à mesure que les requêtes se terminent, les sockets se ferment, les travailleurs quittent et les fichiers temporaires sont libérés.

La ligne de base avant et après l'événement reste similaire. Une fenêtre de sauvegarde, un pic de flux média ou de nombreux clients web concurrents peuvent produire un compteur élevé sans indiquer une mauvaise gestion des ressources.

Le pic devrait aussi correspondre au travail accompli. Si deux fois plus de clients créent environ deux fois plus de sockets actifs et que le compteur redescend ensuite, le système montre une demande de capacité finie plutôt qu'une perte persistante.

Quel motif révèle une fuite de descripteurs ?

Une fuite modifie la ligne de base au lieu de seulement le maximum. les fuites maintiennent les descripteurs ouverts après la fin du travail, donc chaque cycle de requête, reconnexion, rechargement ou opération échouée laisse des ressources derrière.

Le compteur peut croître assez lentement pour passer inaperçu lors de tests courts. Un service peut sembler sain pendant des heures ou des jours jusqu'à ce que la marge restante des descripteurs devienne trop faible pour la prochaine connexion ou ouverture de fichier.

Redémarrer le processus réinitialise le compteur parce que le noyau ferme ses descripteurs, mais cette récupération ne prouve pas que le problème sous-jacent est résolu. La même pente réapparaît une fois que le service recommence à traiter du travail.

Pourquoi les sockets, fichiers et observateurs produisent-ils des courbes différentes ?

Linux utilise des descripteurs pour plusieurs types de ressources d'E/S, et différents types de ressources créent différents schémas de croissance. Chaque type nécessite donc une explication de charge de travail différente.

Les sockets clients doivent suivre les sessions simultanées. Les fichiers journaux ou médias doivent suivre les poignées actives. Les pipes peuvent suivre les processus enfants, tandis que les descripteurs liés aux observateurs peuvent rester stables même si le nombre de chemins surveillés augmente via une limite noyau distincte.

Classer les descripteurs par cible est plus utile que de lire un total unique. Des centaines de sockets attendus lors d'un pic de trafic diffèrent de fichiers journaux supprimés en croissance constante ou de connexions répétées à une dépendance indisponible.

Pourquoi augmenter la limite retarde-t-il une fuite au lieu de la corriger ?

L'erreur « Trop de fichiers ouverts » ne se produit que lorsque la croissance atteint un plafond. des limites plus élevées ne font que retarder l'épuisement de la fuite.

Une limite plus élevée allonge le temps entre le redémarrage et l'échec. Cela peut faire apparaître le service comme réparé pendant une courte fenêtre d'observation tout en permettant à la fuite de consommer plus de mémoire noyau et plus d'état réseau ou de stockage.

Les changements de capacité doivent donc suivre la preuve que les descripteurs sont libérés normalement. Sinon, le nouveau plafond est une enveloppe d'échec plus grande plutôt qu'une amélioration de la stabilité.

Quelles mesures distinguent la capacité de l'échec du cycle de vie ?

Le nombre total n'est que le premier signal. l'âge et le type de descripteur révèlent la cause profonde. Suivez le nombre, le type cible, la durée d'ouverture, le taux de création, le taux de fermeture, le trafic et les requêtes complétées sur la même chronologie.

Pour un pic, le nombre de descripteurs doit évoluer avec la concurrence et finir par revenir. Pour une fuite, la durée d'ouverture et la ligne de base augmentent tandis que la quantité de travail utile actif n'augmente pas proportionnellement.

Comparez plusieurs cycles au lieu d'un seul instantané. Un seul nombre élevé ne peut pas montrer si le processus est proche du sommet d'une vague normale ou en cours d'une tendance persistante à la hausse.

Quand une limite de descripteurs plus élevée est-elle réellement justifiée ?

la réutilisation des connexions réduit la demande légitime de descripteurs. Avant d’augmenter les limites, éliminez le renouvellement évitable des connexions, limitez les pools et confirmez que les ressources se ferment à la fin du travail.

Une limite plus élevée est justifiée lorsque la concurrence légitime testée approche la limite effective actuelle du service, que les comptes de descripteurs reviennent à la ligne de base, et que la mémoire, les tampons de socket, les pools backend et le comportement de récupération peuvent supporter la demande accrue.

Définissez les alertes en dessous du point d’échec critique et conservez une marge administrative. L’objectif n’est pas de rendre la limite inaccessible, mais de maintenir les pics normaux dans une plage opérationnelle mesurée tout en détectant tôt une croissance anormale.

FAQ

Une fuite de descripteur de fichier peut-elle se produire avec une faible utilisation du CPU ?

Oui. Un processus peut conserver des sockets ou des fichiers en attente et consommer presque aucun CPU jusqu’à ce qu’une nouvelle allocation échoue.

TIME_WAIT prouve-t-il une fuite de descripteur ?

Non. TIME_WAIT est un état TCP du noyau après la fermeture d’une socket. Une fuite de descripteur signifie que l’application détient encore un descripteur ouvert.

Pourquoi le redémarrage du service semble-t-il le résoudre ?

La sortie du processus ferme ses descripteurs et restaure l’espace disponible. Si le cycle de vie de l’application reste défectueux, le nombre recommence à augmenter.

Les alertes doivent-elles utiliser un nombre fixe de descripteurs ?

Utilisez à la fois le pourcentage de la limite effective et le comportement de croissance. Un nombre élevé stable peut être normal, tandis qu’un nombre plus bas mais en augmentation constante peut être dangereux.

Conclusion finale

Les pics légitimes de descripteurs suivent un travail actif et reviennent à une ligne de base stable. Les fuites retiennent des ressources après la fin du travail, créant un plancher montant qui finit par dépasser une limite finie. Diagnostiquez la courbe, le type de ressource et l’âge du descripteur avant d’augmenter les limites, car un espace supplémentaire ne soutient la capacité réelle que lorsque le cycle de vie est déjà correct.