Esta sección ofrece una descripción general completa de los componentes de hardware y su influencia en el mongot proceso. Proporciona pautas de dimensionamiento, recomendaciones esenciales de monitoreo y consejos prácticos de escalamiento.
CPU
impacto
Aumentar la cantidad y la calidad de las CPU generalmente tiene un impacto positivo en el rendimiento de replicación y el rendimiento de consultas (QPS). La CPU se aprovecha especialmente para consultas que utilizan búsqueda de segmentos concurrente.
Guía de tallas
Una estimación útil basada en el rendimiento de las query es de 10 QPS por núcleo de CPU. Este es un punto de referencia, ya que el QPS real está influenciado por la complejidad de las queries y los mapeos de índices.
Monitoring
Observar sistemáticamente un uso de CPU superior al 80% sugiere la necesidad de escalar (agregar núcleos de CPU), mientras que sistemáticamente por debajo del 20% podría indicar la oportunidad de escalar (reducir núcleos de CPU).
Escalado
El escalado horizontal (agregar más nodos mongot) incrementa el total de CPU para mejorar el QPS.
Nota
El escalado horizontal añade una carga adicional a un set de réplicas, ya que cada mongot necesita replicar datos de índices desde una colección fuente. Cada índice de búsqueda o de búsqueda vectorial crea un nuevo flujo de cambios por mongot, lo que puede degradar el rendimiento si el set de réplicas no tiene el tamaño adecuado para gestionar la carga adicional de replicación.
El escalamiento vertical impacta principalmente en la latencia de las consultas al poder atender más consultas en paralelo y reducir la puesta en cola de solicitudes de consultas.
Memoria (RAM)
impacto
mongot utiliza la memoria del sistema para la pila JVM (para estructuras de datos y cachés relacionadas con Lucene) y la caché del sistema de archivos (para acceder eficientemente a los datos indexados).
Guía de tallas
Para las arquitecturas colocalizadas, la configuración por defecto ofrece un buen equilibrio. Sin embargo, para una infraestructura dedicada, ajustar el tamaño por defecto de la pila JVM puede ser beneficioso. Las siguientes secciones proporcionan orientación sobre cómo optimizar esta configuración para tu hardware y carga de trabajo específicos.
Dimensionamiento del heap de JVM
mongot utiliza la JVM heap principalmente para las estructuras de datos relacionadas con Lucene y las cachés. En general, el uso de heap de mongot escala aproximadamente con el número de campos indexados. El uso de heap no se ve ampliamente afectado por el número de documentos o el número de vectores. La modelización de datos efectiva para búsquedas de texto completo y búsquedas vectoriales generalmente minimiza la cantidad de campos indexados.
Como estimación, asigna el 50% de la memoria total disponible del sistema, sin superar un máximo de aproximadamente 30GB. Esto permite que se use suficiente memoria para la caché del sistema de archivos del SO, que desempeña un rol vital en el rendimiento de Lucene al almacenar en caché los segmentos de índices a los que se accede con frecuencia desde el disco. Por defecto, mongot asigna hasta 25% de la memoria total disponible del sistema a la memoria heap de la JVM, hasta 32GB (con 128GB de memoria del sistema). Estas pautas de dimensionamiento son un incremento respecto al valor por defecto.
Además, mantener los tamaños de heap por debajo de aproximadamente 30GB permite que JVM use punteros de objetos comprimidos, ahorrando memoria. Si los tamaños del heap se incrementan por encima de este límite de 30GB, se recomienda que el tamaño del heap se incremente directamente a 48GB o más.
Para anular la configuración por defecto del tamaño de la pila, especifica el tamaño necesario como argumento al script de inicio mongot. Se recomienda establecer el tamaño mínimo de heap (Xms) y el tamaño máximo de heap (Xmx) al mismo valor. Por ejemplo:
/etc/mongot/mongot --config /etc/mongot/mongot.conf --jvm-flags "-Xms4g -Xmx4g"
Caché del sistema de archivos
Los segmentos de índices se acceden mediante archivos asignados por memoria, de manera que la latencia y el rendimiento de la query dependen en gran medida de la memoria caché del sistema de archivos del sistema operativo. Debes reservar suficiente memoria para la carga de trabajo de la caché del sistema de archivos. Utilizar hardware aislado para mongot puede reducir la contención de caché.
Nota
Aumentar el tamaño de JVM Heap más allá del 50% de la memoria disponible puede resultar en una memoria insuficiente para el uso de la caché del sistema de archivos.
Orientación para búsqueda vectorial
Para la búsqueda vectorial, se utiliza la "Memoria del Proceso de Búsqueda" para el almacenamiento eficiente de estructuras de datos como el grafo HNSW. Si el tamaño del índice vectorial supera 3los GB, utilice la cuantificación vectorial. Al cuantificar los vectores, solo 4se necesita almacenar en memoria el % del índice, en lugar del índice completo.
Monitoreo de memoria insuficiente
Un aumento en los fallos de página de búsqueda y en las IOPS de disco indica que el sistema operativo recupera páginas necesarias del disco con frecuencia, lo que sugiere poca memoria. Ver constantemente fallos de página superiores a 1000/s indica que se debe considerar ampliar la capacidad.
Escalado
Si el proceso mongot termina con un OutOfMemoryError, significa que el Heap de la JVM es demasiado pequeño para la carga de trabajo de indexación y query. Esto suele deberse a almacenar demasiados campos fuente, o una "explosión de mapeo" a partir de mapeos dinámicos en datos no estructurados. Las recomendaciones principales para resolver este problema son:
Aumenta el tamaño del heap de Java (escalado vertical)
La solución más directa es asignar más RAM al proceso mongot. Si el host tiene memoria disponible, se puede aumentar el tamaño máximo del heap de Java. Esto proporciona más margen para los patrones de índices y consultas existentes sin cambiar la definición del índice.
Reducir la huella de memoria del índice
Si escalar el hardware no es una opción, o si deseas optimizar la eficiencia, puedes reducir la cantidad de memoria que requiere tu índice.
Revisar la definición del índice y reducir los campos storedSource, remover todos los campos no esenciales del índice para disminuir la presión sobre el heap.
Utiliza el mapeo estático. Un mapeo dinámico creará un campo de índice para cada campo único en los documentos de una colección. Ser más selectivo e indexar solo los campos esenciales reducirá el consumo de heap.
Rendimiento del disco y almacenamiento
impacto
Tanto las IOPS de lectura como las de escritura son cruciales para el rendimiento de mongot, lo que afecta la replicación, la sincronización inicial y el rendimiento de las consultas. Para la mayoría de los casos de uso, recomendamos SSD de uso general.
En general, tanto las IOPS de lectura como las de guardado son importantes para el rendimiento de mongot. La replicación de datos implica no solo operaciones de guardar en disco, sino también lecturas, ya que los segmentos de índice antiguos se agrupan en segmentos más grandes. Así, el rendimiento del disco tiene diversos efectos en todos los aspectos del rendimiento de mongot, desde el rendimiento de query hasta el rendimiento de indexación de la sincronización inicial.
Guía de tallas
Reconstrucciones de índices
Crear o reconstruir un índice de Atlas Search consume muchos recursos y puede afectar el rendimiento del clúster. Para la indexación sin tiempo de inactividad, asigna espacio libre en disco igual al 125% del espacio en disco utilizado por tu índice antiguo. Este margen es importante porque el índice antiguo se mantiene en el disco durante una reconstrucción. Como recomendación general, deberías double el espacio en disco para mongot a fin de acomodar la reconstrucción de índices.
Monitoring
Para rastrear el consumo actual de índices, supervisá Search Disk Space Used. Un uso sostenido de IOPS por encima de 1K requiere investigación.
Nota
Cuando la utilización de almacenamiento del host mongot alcanza el 90%, mongot entra en estado de solo lectura. Mientras se encuentra en este estado, mongot sigue respondiendo a consultas utilizando los índices en su estado actual. Los resultados de búsqueda pueden estar desactualizados si se realizan cambios en la colección fuente sin mitigación.
Para reanudar la sincronización del índice con las colecciones de origen, se debe reducir el uso de almacenamiento por debajo del 85%, ya sea eliminando datos de índice o aumentando la capacidad de almacenamiento.
Escalado
Al aumentar los tamaños de los índices y con mayores volúmenes de datos de índices, especialmente con cuantización binaria, asegúrate de que las instancias tengan suficiente memoria para soportar conjuntos de trabajo más grandes de datos de índices. Sin embargo, la cantidad exacta de memoria requerida varía según la carga de trabajo.
Por ejemplo, los conjuntos de datos grandes que rara vez se *query* en su totalidad podrían atender *queries* con baja latencia y usando menos memoria que un conjunto de datos del mismo tamaño que sí se *query* en su totalidad con frecuencia.
Si usas mongot con una alta proporción de almacenamiento a memoria, supervisa cuidadosamente el uso de la memoria. Como ejemplo, 64GB de memoria pueden no ser suficientes para 6400GB de almacenamiento.