Aumenta el uso de la CPU de unicornio durante las pruebas de carga, formas de optimizar

Question

Estoy interesado en formas de optimizar mi configuración de Unicornio para mi aplicación Ruby on Rails 3.1.3. Actualmente estoy generando 14 procesos de trabajo en Instancia Extra Grande de CPU Alta ya que mi aplicación parece estar unida a la CPU durante las pruebas de carga. Aproximadamente 20 solicitudes por segundo que reproducen solicitudes en una prueba de carga de simulación, los 8 núcleos en mi instancia alcanzan el máximo y la carga de la casilla aumenta a 7-8. Cada instancia de unicornio está utilizando alrededor del 56-60% de CPU.

Tengo curiosidad de qué maneras puedo optimizar esto? Me gustaría poder canalizar más solicitudes por segundo a una instancia de este tamaño. La memoria está completamente bien al igual que todas las demás E/S. La CPU se está hundiendo durante mis pruebas.

Answer 1

En primer lugar, es probable que no desee instancias al 45-60% de la CPU. En ese caso, si obtiene un pico de tráfico, todas sus instancias se ahogarán.

A continuación, 14 instancias de Unicornio parecen grandes. Unicornio no usa el enhebrado. Por el contrario, cada proceso se ejecuta con un solo hilo. El proceso maestro de Unicorn solo tendrá select un hilo si es capaz de manejarlo. Debido a esto, la cantidad de núcleos no es una medida que se debe usar para medir el rendimiento con Unicornio.

Una configuración más conservadora puede usar 4 o más procesos Unicorn por instancia, respondiendo a quizás 5-8 solicitudes por segundo. Luego, ajuste el número de instancias hasta que el uso de su CPU sea de alrededor del 35%. Esto garantizará la estabilidad en el estresante '20 solicitudes por segundo escenario '.

Por último, puede obtener estadísticas y detalles más valientes utilizando God.

Answer 2

Si está vinculado a la CPU no quiere usar más procesos de unicornio que sus núcleos, de lo contrario, sobrecargará el sistema y ralentizará el programador. Puedes probar esto en una caja de desarrollo usando ab. Notarás que 2 unicornios superarán 20 (el número depende de los núcleos, pero el concepto será verdadero).

La excepción a esta regla es si su IO está vinculado. En ese caso, agregue tantos unicornios como contenga la memoria.

Un buen truco de rendimiento es enrutar las solicitudes de IO vinculadas a un servidor de aplicaciones diferente que aloja muchos unicornios. Por ejemplo, si tiene una solicitud que usa una consulta SQL lenta, o su espera en una solicitud externa, como una transacción de tarjeta de crédito. Si utiliza nginx, defina un servidor en sentido ascendente para las solicitudes de límite de IO, reenvíe esas urls a un cuadro con 40 unicornios. CPU vinculada o solicitudes realmente rápidas, reenviar a un cuadro con 8 unicornios (declaraste que tienes 8 núcleos, pero en aws podrías querer probar 4-6 ya que sus programadores están hipervisionados y ya están muy ocupados).

Además, no estoy seguro de que pueda contar con aws que le brinde un uso confiable de la CPU, ya que obtendrá un porcentaje de un porcentaje oscuro.

Answer 3

Para una gran instancia de CPU extra grande, 20 solicitudes por segundo es muy bajo. Es probable que haya un problema con el código. Un problema específico de unicornio parece menos probable. Si tiene dudas, puede probar con un servidor de aplicaciones diferente y confirmar que todavía suceda.

En este escenario, las preguntas que estaría pensando ...

1 - ¿Estás haciendo algo intensivo de la CPU en el código - tal vez algo que realmente debe estar en la base de datos. Por ejemplo, si trae de vuelta un juego de registros grande y lo recorre en ruby ​​/ rails para ordenarlo o realizar alguna otra operación, eso explicaría un cuello de botella de CPU en este nivel en lugar de dentro de la base de datos. La recomendación en este caso es actualizar la consulta para hacer más y quitar la carga de los rieles.Por ejemplo, si está ordenando el conjunto de resultados en su controlador, en lugar de a través de sql, eso causaría un problema como este.

2 - ¿Estás haciendo algo inusual en comparación con una aplicación de puré de vainilla, como el acceso a un recurso compartido, o cualquier cosa donde la contención podría ser un problema?

3 - ¿Tiene algún bucle que pueda quemar la CPU, especialmente si existió una disputa por un recurso?

4 - Pruebe a desenganchar varias partes de la lógica del controlador en cuestión. Por ejemplo, ¿qué tan bien escala si piratea su código para devolver una respuesta estática hello world en su lugar? Apuesto a que el unicornio será increíblemente rápido. Luego intente agregar partes de su código hasta que descubra la fuente de la lentitud.