16 votos

Número óptimo de por CPU unicornio procesos

Estamos ejecutando un Ruby on Rails web app en virtud de Unicornio. Nuestra aplicación no es estrictamente CPU (tenemos un dual Xeon E5645 sistema w/12 núcleos y un pico de carga promedio es de alrededor de 6). Empezamos con 40 Unicornio trabajadores inicialmente, pero la memoria de la aplicación de la huella de aumento a lo largo del tiempo. Por lo tanto, ahora tenemos que reducir el número de procesos de trabajo. Pensé que el estándar (número de núcleos de CPU + 1) fórmula se aplica a los Unicornio también, pero mi colega trató de convencer a mí nos debe de reserva de más de Unicornio instancias por la CPU y la proporcionada en este enlace. Sin embargo, no estoy exactamente seguro de por qué tenemos que gastar tanta memoria en ralentí Unicornio procesos.

Mi pregunta es: ¿cuál es la razón para tener más de un Unicornio instancia por cada núcleo de la CPU? Es debido a algún arquitectónico peculiaridad de Unicornio? Soy consciente de que ocupado Unicornio procesos no puede aceptar nuevas conexiones (estamos usando UNIX domain sockets para comunicarse a Unicornio instancias por CIERTO), pero pensé que el atraso se introdujo exactamente a la dirección de esta. Es posible superar esta de 2 a 8 Unicornio instancias por la CPU de la regla de todos modos?

17voto

Alex Puntos 5342

Bueno, he encontrado la respuesta definitiva. El número óptimo de Unicornio de los trabajadores no está conectado directamente con el número de núcleos de CPU, depende de su carga interna y la aplicación de la estructura de respuesta. Básicamente utilizamos el muestreo del analizador para determinar los trabajadores del estado, tratamos de mantener a los trabajadores en el 70% de inactividad y un 30% de hacer el trabajo real. Así, el 70% de las muestras se debe "a la espera en el select() llamada al recibir una solicitud de la interfaz del servidor". Nuestra investigación ha demostrado que sólo hay 3 estados eficaces de los trabajadores: 0-30% de las muestras están inactivos, el 30-50% de las muestras son de inactividad y el 50-70% de las muestras son de inactividad (si podemos conseguir más inactivo muestras, pero no hay ningún punto real en ella, porque la respuesta de la aplicación no cambia de forma significativa). Consideramos 0-30% situación como una "zona roja" y 30-50% de la situación de una "zona amarilla".

6voto

darkk Puntos 238

Tienes razón acerca de N+1 para la CPU-bound puestos de trabajo.

Por otro lado, el unicornio no usar los hilos, por lo que cada IO op. bloquea el proceso y otro proceso puede patear en y analizar los encabezados HTTP, concatenar cadenas y hacer cada uso intensivo de la CPU de tareas necesita para servir al usuario (haciendo anteriores para reducir la latencia de solicitudes).

Y puede que desee tener más hilos/procesos de núcleos. Imaginar la siguiente situación: req. Una toma diez veces más de req. B, tiene varios concurrentes Una de las solicitudes y rápido B solicitud es justo en cola de espera para Un-req para completar. Así que si usted puede predecir el número de pesadas las solicitudes, puede utilizar este número como otro de guía para ajustar el sistema.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: