9
votes

Nombre de connexions Memcache ne tombe jamais, continue de croître

Nous avons configuré trois serveurs MEMCACHE pour notre application Web.

Deux vont bien, manipulant des dizaines de milliers de lectures et écrites, tout en maintenant plus de 12 connexions (selon memcache-top ).

Nous avons un troisième serveur MEMCACHACHE qui est responsable de la stockage de données de session de la clientèle administrative (à l'aide de PHP intégré au gestionnaire de session MEMCACHE ) et à certaines données d'application aléatoire. Pour une raison quelconque, le nombre de connexions sur cette case ne diminue jamais, ne augmentant que dans le temps. Par exemple, nous avons récemment redémarré le serveur et une heure plus tard les raccords de memcache-top ~ 300 connexions.

La base de code utilise un mélange de connexions persistantes et de connexions dynamiques, mais je n'ai pas pu proposer un exemple simple pour recréer la situation où les connexions ne meurent jamais. Ce troisième serveur MemCache héberge réellement la partie la moins active de notre application Web, comme vous pouvez le constater à partir de MemCache-top: xxx

donc ma question est la suivante: pourquoi les connexions pour cela L'instance Memcache ne meurt jamais?


1 commentaires

Q1. Est-ce que le 3ème serveur "gênant" est un * BSD, tandis que ces 2 "fins" serveurs - Linux? Q2. Quel est le% d'utilisation de la CPU pour les 3 memcaches?


3 Réponses :


4
votes

Les connexions persistantes dans PHP alloueront une connexion pour chaque processus de travailleur Apache. Est la configuration Apache pour autoriser ~ 354 processus de travail?


0 commentaires

1
votes

Quels sont vos sessions.gc_probabilité et session.gc_divisor défini sur? Certaines distributions Linux écrasent ces valeurs et ajoutent un cronjob aux sessions claires. Votre problème peut être causé par ce comportement.


0 commentaires

2
votes

Utilisez-vous php5? Très probablement oui. Voici un piège possible à partir du PHP Session_Se_Save_Handler Documentation :

comme de php 5.0.5 l'écriture et la fermeture Les gestionnaires sont appelés objet après l'objet destruction et donc ne peut pas utiliser objets ou lancer des exceptions. Les Les destructeurs d'objets peuvent cependant utiliser sessions.

Il est possible d'appeler session_write_close () de la destructeur de résoudre ce poulet et Problème d'oeufs.

Combien voulez-vous parier que le gestionnaire de session Memcache n'a pas été revisité depuis avant ce changement? En tant que solution ou au moins de diagnostic, je vous recommande de rédiger votre propre session MemCached Open / Fermer / Lecture / Lecture / Écrire des fonctions (pas d'objet), joignez-les avec session_set_save_handler et saute à l'aide de l'une. À tout le moins, vous pourrez enregistrer les internes alors.


1 commentaires

En tant que note latérale pour la journalisation / le débogage de votre gestionnaire de session personnalisé - vous devez utiliser quelque chose le long des lignes de File_Put_Contents () comme la méthode d'écriture () survient après que le contenu ait été rincé à la page.