¿Se necesita experiencia en el rendimiento de la base de datos de Heroku?

Question

Estamos experimentando algunos desafíos de escalamiento graves para nuestro motor de búsqueda inteligente/agregador. Nuestra base de datos contiene alrededor de 200k objetos. Desde perfiles y newrelic parece que la mayoría de nuestros problemas pueden provenir de la base de datos. Estamos utilizando la base de datos dedicada más pequeña que ofrece Heroku (Ronin).

Hemos estado investigando la indexación y el almacenamiento en caché. Hasta ahora logramos resolver nuestros problemas reduciendo las llamadas a la base de datos y el almacenamiento en caché del contenido de forma inteligente, pero ahora incluso esto parece llegar a su fin. Constantemente nos preguntamos si nuestro código/configuración es lo suficientemente bueno o si simplemente no estamos usando suficiente "hardware".

Sospechamos que la solución de base de datos que compramos en Heroku puede estar funcionando de manera insuficiente. Por ejemplo, solo haciendo un conteo simple (sin uniones, sin nada) en los artículos de 200k toma alrededor de 250ms. Esto parece un tiempo largo, aunque postgres es conocido por su mal rendimiento en los conteos?

También hemos empezado a usar las búsquedas de geolocalización basadas en la latitud/longitud. Ambas columnas son flotantes indexados. Hacer un cálculo de distancia implica matemática bastante complicada, pero estamos usando la muy recomendada geocoder gema que se sospecha que ejecuta muy consultas optimizadas. Incluso el geocodificador tarda entre 4 y 10 segundos en realizar una búsqueda en, digamos, 40,000 objetos, devolviendo solo un límite de los primeros 10. Suena de nuevo como mucho tiempo, y todas las personas con experiencia que consultamos dicen que suena muy extraño, de nuevo insinuando el rendimiento de la base de datos.

Así que, básicamente, nos preguntamos: ¿Qué podemos esperar de la base de datos? ¿Podría haber un problema? ¿Y qué podemos esperar si decidimos actualizar?

Una pregunta adicional que tengo es: Leo here que podemos mejorar el rendimiento al cargar toda la base de datos en la memoria. ¿Se supone que debemos configurar esto y, si es así, cómo?

ACTUALIZACIÓN SOBRE LA ÚLTIMA PREGUNTA: tengo esto desde el pueblo votos en apoyo Heroku:

"Lo que esto significa es tener suficiente memoria (una lo suficientemente grande dedicada base de datos) para almacenar el calor conjunto de datos en la memoria. Esto no es algo que tiene que hacer manualmente, Postgres se configura automáticamente utilizar todos memoria disponible en nuestras bases de datos dedicados.

me tomó un vistazo a su base de datos y parece que eres actualmente usando aproximadamente 1.25 GB de RAM, por lo que aún no ha maximizado su uso de memoria ".

ACTUALIZACIÓN SOBRE LAS números y figuras

Bueno por lo que ahora que he tenido tiempo para mirar en los números y las figuras, y voy a tratar de contestar las siguientes preguntas de la siguiente manera:

• En primer lugar, el db consta de alrededor de 29 tablas con muchas relaciones. Pero en realidad, la mayoría de las consultas se realizan en una sola tabla (se unen algunos recursos adicionales para proporcionar toda la información necesaria para las vistas).
• La tabla tiene 130 columnas.
• Actualmente contiene alrededor de 200k registros, pero solo 70k están activos, por lo tanto, todos los índices se realizan como índices parciales en este "estado".
• Todas las columnas que buscamos están indexadas correctamente y ninguna es de tipo texto, y muchas son solo booleanas.

Las respuestas a las preguntas:

1. Hmm el rendimiento de referencia que es un poco difícil de decir, que tienen tan muchas selecciona diferentes. El tiempo que toma varía típicamente de 90ms a 250ms seleccionando un límite de 20 filas. Tenemos MUCHOS conteos en la misma mesa, todos varían de 250ms a 800ms.
2. Hmm, eso es difícil de decir porque no lo intentarán.
3. Tenemos alrededor de 8-10 usuarios/clientes ejecutando solicitudes al mismo tiempo.
4. Nuestra carga de consulta: En los informes de base de datos nueva de reliquias que dice esto acerca de las últimas 24 horas: throughput: 9.0 cpm, total time: 0.234 s, avg time: 25.9 ms
5. Sí se han examinado los planes de consulta de nuestras consultas de larga duración. Las consultas de recuento son especialmente lenta, a menudo más de 500 ms para una bastante simple recuento de los 70k registros realizado en columnas indizadas con un resultado alrededor de 300

Answer 1

He sintonizado unos rieles aplicaciones alojadas en Heroku, y también alojado en otras plataformas, y por lo general los problemas de caída en unas pocas categorías básicas:

1. hacer demasiado en Ruby que se podrían hacer en el nivel de dB (clasificación, filtrado, se unen a los datos, etc.)
2. consultas lentas
3. uso ineficiente de los índices (no lo suficiente, o demasiados)
4. tratando demasiado duro para hacerlo todo en el PP (esto no es como es común en los rieles, pero sucede)
5. No es la optimización de los datos cacheables
6. No eficazmente usando procesamiento en segundo plano

En este momento es difícil para ayudarle a su pregunta porque no contiene ningún detalle. Creo que obtendrás una mejor respuesta si identificas el problema más importante con el que necesitas ayuda y luego preguntas.

Algo de información que le ayudará a ayudarle:

1. ¿Cuál es el tiempo medio de respuesta de sus acciones? (De nueva reliquia, petición-log-analizador de logs),
2. ¿Cuál es la solicitud más lento que el que necesita ayuda?
3. ¿Cuáles son las consultas y el código en esa solicitud?
4. ¿El rendimiento del sitio es diferente cuando lo ejecuta localmente frente a heroku?

Al final creo que usted encontrará que no es un problema específico de Heroku, y si se había desplegado su aplicación en Amazon, EngineYard, etc Usted tendría el mismo rendimiento. La buena noticia es que creo que sus problemas son comunes, y no deberían ser demasiado difíciles de corregir una vez que haya realizado una evaluación comparativa y un perfil.

-John McCaffrey

Answer 2

monitoreo NewRelic puede ser incluido como un add-on para heroku (http://devcenter.heroku.com/articles/newrelic). Por lo menos, esto debería darle una gran idea de lo que está sucediendo detrás de escena, y puede ayudarlo a identificar algunos problemas.

Answer 3

Estamos constantemente pidiendo ...

... esto parece mucho ...

... que se sospecha ...

... ¿Qué podemos hacer espera ...

¡Buenas noticias! ¡Usted puede poner y terminar con la apariencia, sospechando que se está preguntando y esperando a través de la magia de la medición!

Hablando en serio, no se ha mencionado cualquiera de los puntos básicos que había necesidad de obtener una respuesta útil:

1. ¿Cuál es el rendimiento de referencia de la base de datos de ejecutar un análisis secuencial y recuperaciones de índice de una sola fila ? Usted dice que Heroku dice que su base de datos cabe en la memoria RAM, por lo que no debería ver problemas de E/S del disco cuando mida.
2. ¿Este rendimiento coincide con lo que Heroku dice que debería ser?
3. ¿Cuántos clientes concurrentes?
4. ¿Cuál es su carga de consultas? ¿Qué preguntas y con qué frecuencia?
5. ¿Ha comprobado los planes de consulta para cualquiera de sus consultas sospechosamente de larga ejecución?

Una vez que tenga este tipo de información, tal vez alguien pueda decir algo útil. Tal como está, cualquier cosa que leas aquí es solo conjeturas.

Answer 4

Primero: usted debe comprobar la configuración de postgres. (mostrar todo desde psql u otro cliente, o simplemente mirar postgres.conf en el directorio de datos) El parámetro con el mayor impacto en el rendimiento es effective_cache_size, que debe establecerse en about (total_physical_ram - memory_in_use_by_kernel_and_all_processes). Para una máquina de 4 GB, esto a menudo es de alrededor de 3 GB (4-1). (Esto es muy afinado, pero dará los mejores resultados para un primer paso)

Segundo: ¿por qué quieres todas las cuentas? Es mejor utilizar una consulta típica: solo pregunte qué se necesita, no qué está disponible. (razón: no hay optimización posible para un COUNT (*): ya sea que se escanee toda la tabla o un índice completo)

Tercero: comience a reunir y analizar algunos planes de consulta (para consultas típicas que funcionan mal). Puede obtener un plan de consulta poniendo EXPLAIN ANALYZE antes de la consulta real. (Otra forma es aumentar el nivel de registro y obtenerlos del archivo de registro). Un plan de consulta incorrecto puede indicarle que faltan estadísticas o índices, o incluso con un mal modelado de datos.