2011-07-21 10 views
9

Estoy ejecutando memcached en mi servidor y cuando llega a más de 600 req/s se vuelve inestable y causa una gran cantidad de problemas. Parece que cuando la tasa de solicitud es tan alta, mis aplicaciones PHP en momentos aleatorios no pueden conectarse al servidor Memcache, lo que causa lentos tiempos de carga, lo que hace que nginx y php-fpm se vuelvan locos y reciba 104: Restablecimiento de la conexión por pares errores en mis registros de nginx600+ problemas de memcache req/s - ¡ayuda!

Me gustaría señalar que en mi servidor de Memcache tengo 'objetos calientes' - objetos que a veces reciben el 90% de las solicitudes de Memcache. También noté que cuando tantas solicitudes golpean un solo objeto, agrega un poco más de tiempo de carga a la página general (cuando se las arregla para cargar).

Agradecería mucho cualquier ayuda para este problema. ¡Muchas gracias!

+1

suena como una pregunta que debe poner en serverfault. – Matt

Respuesta

7

interruptor lejos de usar sockets TCP y yendo a los sockets UNIX (suponiendo que se encuentre en un servidor basado en UNIX)

inicio memcached con una toma habilitados: Añadir -s /tmp/memcached.socket a su línea de inicio memcached (soporte Nota, tomas de corriente, se inutiliza la creación de redes)

Luego, en PHP, conectarse a través de conexiones persistentes, y para el nuevo socket Memcache:

$memcache_obj = new Memcache; 
$memcache_obj->pconnect('unix:///tmp/memcached.socket', 0); 

Otra recomendación, si usted tiene múltiples "tipos" de objetos almacenados en caché, inicie una instancia de memcached para cada "tipo" y distribuya los elementos más importantes entre ellos.

Drupal hace esto, se puede ver cómo su archivo de configuración y memcached init está configurado here.

Además, me parece que su tiempo de espera de memcached está configurado de manera MUY alta. Si es algo superior a 1 o 2 segundos, puede bloquear las secuencias de comandos. El tiempo de espera debe alcanzarse y la secuencia de comandos debe recuperar el objeto por defecto a través de otro método (SQL, archivo, etc.)

La otra cosa es verificar que su memcache no se ponga en un archivo de intercambio, si su caché es más pequeño que tu RAM libre promedio, prueba a iniciar Memcache con la opción -k, esto obligará a su caché a permanecer siempre en ram y no puede intercambiarse.

Si tiene un servidor de varios núcleos, también asegurarse de memcached se compila con soporte de hilos, y habilitarlo mediante -t <numcores>

+0

Por alguna razón, cuando utilicé enchufes, el servidor funcionó bien durante unos minutos y luego se ralentizó. No estoy seguro de por qué ... – Aco

1

600 solicitudes por segundo son muy bajas para memcached.

Si está estableciendo una conexión para cada solicitud, pasará más tiempo conectando que solicitando y quemando sus puertos efímeros muy rápidamente, que podría ser el problema que está viendo.

+1

¿Qué sugieres? – Aco

+1

No sé muy bien qué es lo que está haciendo lo suficiente para sugerir algo. Parece que estás estableciendo una conexión para cada solicitud. Si es así, entonces sugeriría no hacerlo por los motivos anteriores. – Dustin

0

Hay un par de cosas que podría intentar:

  • Si ha memcached ejecutándose de forma local, puede utilizar el zócalo llamado 'localhost' en lugar de '127.0.0.1'
  • Use conexiones persisntent
+0

No esperaría forzar el uso de un resolver para reducir los problemas. – Dustin

+0

El uso de 127.0.0.1 en realidad abre un socket, mientras que el localhost es un alias para el socket del localhost (y por lo tanto no abre uno nuevo) –

+1

Linux no hace eso. Hay un controlador MySQL particular para PHP que hace eso. Sin embargo, esa es una decisión de diseño bastante mala. Si alguien quiere un socket de dominio Unix en lugar de un socket TCP/IP, entonces debe pedir lo que quiere. – Dustin