Análisis del código fuente de Tsdb

Recientemente, el proyecto encontró el problema de la baja velocidad de consulta de openstsdb. No importa cuántos datos haya, la consulta siempre es muy lenta. Si la cantidad de datos devueltos por la consulta es demasiado grande, se producirá OOM.

Opentsdb se basa en Hbase y finalmente encontró una solución para aumentar el BucketCache de Hbase.

¿Cuál es el principio? De hecho, es para aumentar el caché al realizar consultas. Los datos de HBase se almacenan en bloques y el valor predeterminado es 64K. Hay dos implementaciones de BlockCache en HBase: LruBlockCache en el montón predeterminado y BucketCache (generalmente fuera del montón). En términos generales, el rendimiento de BucketCache es peor que el de LruBlockCache. Sin embargo, debido al impacto de GC, el retraso de LruBlockCache se volverá inestable, mientras que BucketCache suele ser estable porque administra BlockCache por sí solo sin necesidad de GC, razón por la cual a veces se necesita BucketCache. Vea esas cosas en HBase para más detalles.

Después de entender esto, todavía tengo algunas preguntas. ¿Qué son los que están dentro y fuera del montón? Puede hacer referencia a la memoria fuera del montón y a la memoria en el montón en JVM.

En cuanto a cómo modificar y una explicación más detallada, puede consultar la documentación oficial de hbase.

Hay un problema relacionado en github, que surgió en 2014 y aún está abierto. Los expertos resolvieron el problema modificando el tamaño de la pila JVM. El proceso de operación es el siguiente:

Este error también es repugnante. No encontré una buena manera. Vi un artículo que resolvió el problema modificando el código fuente de openstdb. El enfoque actual es agregar todos los datos y almacenarlos con una granularidad de tiempo mayor para reducir la cantidad de datos devueltos al realizar consultas. Si algún jefe puede resolver este problema, deje un mensaje o envíe un mensaje privado. Muchas gracias ~

Recientemente leí los documentos oficiales y encontré una solución adecuada para mi proyecto, que resolvió perfectamente todos los problemas. problemas anteriores. Si sus datos se pueden dividir en varios indicadores, puede probar este método para reducir la base de datos en cada indicador y, dado que Hbase se recupera en Rowkey, será más rápido.