Sin MIRA, el requisito de RAM para ejecutar un steemdnodo crecerá indefinidamente, lo que es claramente insostenible. Para extender nuestra pista hacia un futuro lejano, se utilizarán principalmente los nodos habilitados para MIRA. MIRA se basa en la tecnología RocksDB, que es altamente configurable y algo compleja. MIRA se comportará de manera diferente en diferentes piezas de hardware, por lo que es prácticamente imposible crear una configuración de "talla única"; por lo tanto, es importante proporcionar una manera para que los usuarios obtengan el máximo rendimiento de su hardware particular. Esta guía pretende hacer precisamente eso. Esta guía debe mantenerse actualizada y mejorarse dentro del steemdrepositorio para fines de documentación. Las mejoras se deben hacer en una solicitud de extracción contra MIRA Tuning Guide .

Prefacio

Después de los esfuerzos iniciales de desarrollo de MIRA, lanzamos la Guía de configuración básica de MIRA para ayudar a los usuarios de arranque que intentan usar MIRA habilitado steemd. En realidad, se puede hacer mucho más ajuste para mejorar el rendimiento de MIRA y me gustaría aprovechar el momento para compartirlo con la comunidad. Vamos a dividir este proceso en tres fases:

• Fase 1: Recopilación de estadísticas
• Fase 2: Análisis de estadísticas
• Fase 3: Aplicar recomendaciones de rendimiento.

Fase 1: Recopilación de estadísticas

Como habrá notado, dentro del database.cfgarchivo, hay una opción global llamada statistics. De forma predeterminada, esto se establece en false. Esto debe configurarse a trueantes de continuar! Aquí hay un ejemplo de una database.cfgestadística habilitada:

$ cat ~/.steemd/database.cfg 

{

  "global": {

    "shared_cache": {

      "capacity": "5368709120"

    },

    "write_buffer_manager": {

      "write_buffer_size": "1073741824"

    },

    "object_count": 62500,

    "statistics": true

  },

  "base": {

    "optimize_level_style_compaction": true,

    "increase_parallelism": true,

    "block_based_table_options": {

      "block_size": 8192,

      "cache_index_and_filter_blocks": true,

      "bloom_filter_policy": {

        "bits_per_key": 10,

        "use_block_based_builder": false

      }

    }

  }

}

Una vez que se hayan habilitado las estadísticas, simplemente realice la acción que desea optimizar. En mi ejemplo, estaré sincronizando el testnet. Comienza steemdcomo lo harías normalmente. Tenga en cuenta que habilitar las estadísticas causa un impacto drástico en el rendimiento; no querrá ejecutar esto en producción. De forma predeterminada, las estadísticas se vuelcan cada 10 minutos, por lo que querrá ejecutarlas durante un tiempo. Cuantos más datos recopile, más precisas serán las sugerencias de ajuste de rendimiento.

Fase 2: Análisis de estadísticas

Afortunadamente, no necesitará un conocimiento íntimo de RocksDB para analizar los datos estadísticos. Los desarrolladores que trabajan en RocksDB nos han proporcionado una herramienta que puede leer las estadísticas recopiladas y hacer recomendaciones de ajuste de rendimiento. Esta herramienta se puede encontrar dentro del steemdrepositorio en programs/util/rocksdb_advisor.sh. Desde el program/utildirectorio ejecuta la herramienta:

$ sh rocksdb_advisor.sh

Si todo va bien, debe obtener un resultado para cada objeto especificado en el rocksdb_advisor.sharchivo. Aquí hay un ejemplo de la salida posible:

Advisor for account_authority...

WARNING(TimeSeriesData) check_and_trigger: float division by zero



Rule: bloom-not-enabled

TimeSeriesCondition: bloom-not-enabled statistics: ['[]rocksdb.bloom.filter.useful.count', '[]rocksdb.bloom.filter.full.positive.count', '[]rocksdb.bloom.filter.full.true.positive.count'] behavior: evaluate_expression expression: keys[0]+keys[1]+keys[2]==0 aggregation_op: avg trigger: {'ENTITY_PLACEHOLDER': [0.0, 0.0, 0.0]}

Suggestion: inc-bloom-bits-per-key option : bloom_bits action : increase suggested_values : ['2']

scope: entities:

{'ENTITY_PLACEHOLDER'}

scope: col_fam:

{'boost\\:\\:mpl\\:\\:v_item<steem\\:\\:chain\\:\\:by_id, boost\\:\\:mpl\\:\\:vector0<mpl_\\:\\:na>, 0>', 'boost\\:\\:mpl\\:\\:v_item<steem\\:\\:chain\\:\\:by_last_owner_update, boost\\:\\:mpl\\:\\:vector0<mpl_\\:\\:na>, 0>', 'boost\\:\\:mpl\\:\\:v_item<steem\\:\\:chain\\:\\:by_account, boost\\:\\:mpl\\:\\:vector0<mpl_\\:\\:na>, 0>', 'default'}

En realidad, obtendrás significativamente más salida que la anterior. En aras de la simplicidad, trabajaremos con una sugerencia de rendimiento. Podemos ver aquí la rocksdb_advisor.shsugerencia para la account_authority_objectbase de datos.

Sugerencia: opción inc-bloom-bits-per-key: acción bloom_bits: aumentar el valor sugerido: ['2']

Pasemos a aplicar las sugerencias del asesor.

Fase 3: Aplicar recomendaciones de rendimiento.

Si desea aplicar las mismas opciones a todas las bases de datos, simplemente cambiaría la baseconfiguración, ya que esto se aplica a todas las bases de datos dentro de un steemdnodo habilitado para MIRA .Puede observar que obtendrá diferentes recomendaciones para diferentes objetos. En la implementación de MIRA, cada objeto es su propia base de datos RocksDB. ¿Cómo implementamos diferentes opciones para diferentes bases de datos?

Superposiciones de configuración

Una superposición de configuración es un conjunto de opciones que anulan la configuración base que se aplicará a una base de datos específica. En nuestra configuración predeterminada, puede observar que se llama a uno de los objetos base. Estas configuraciones se aplican a cada base de datos a menos que una superposición de configuración las anule. Una superposición de configuración toma las mismas opciones que base. Como ejemplo, anularemos bits_per_keypara el account_authority_object.

{

  "global": {

    "shared_cache": {

      "capacity": "5368709120"

    },

    "write_buffer_manager": {

      "write_buffer_size": "1073741824"

    },

    "object_count": 62500,

    "statistics": true

  },

  "base": {

    "optimize_level_style_compaction": true,

    "increase_parallelism": true,

    "block_based_table_options": {

      "block_size": 8192,

      "cache_index_and_filter_blocks": true,

      "bloom_filter_policy": {

        "bits_per_key": 10,

        "use_block_based_builder": false

      }

    }

  },

  "account_authority_object": {

    "block_based_table_options": {

      "block_size": 8192,

      "cache_index_and_filter_blocks": true,

      "bloom_filter_policy": {

        "bits_per_key": 12,

        "use_block_based_builder": false

      }

    }

  }

}

Nota: al anular un valor de configuración, debe anular la opción completa de primer nivel (como block_based_table_optionsen el ejemplo anterior).

A pesar de que no hemos especificado optimize_level_style_compactiony increase_parallelismpara la account_authority_objectconfiguración, se heredan de base.

Opciones Disponibles

No todas las opciones de RocksDB están disponibles para las configuraciones de MIRA. Es muy posible que la herramienta RocksDB pueda recomendar cambiar una opción que no esté disponible a través de MIRA. Siéntase libre de agregarlo y crear una solicitud de extracción, especialmente si está mejorando el rendimiento de sus nodos. Puede ver una lista completa de las opciones disponibles en el código base de las bibliotecas / mira / src / configuration.cpp . Ver las opciones recomendadas y revisar la lista; Intenté preservar las convenciones de nomenclatura durante la implementación para facilitar este proceso.

Conclusión

Es posible que deba repetir este proceso para lograr resultados óptimos. No hay garantía de que verá mejoras en el rendimiento, ya que esto es de naturaleza experimental. Cuando esté realizando una evaluación comparativa de su configuración o haya completado su ajuste de rendimiento, recuerde configurar statisticsa false.Feliz puesta a punto y buena suerte!