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
Ver constantemente un uso de CPU por encima del 80% sugiere una necesidad de aumentar la escala (agregar núcleos de CPU), mientras que ver constantemente un uso por debajo del 20% puede indicar una oportunidad de reducir la escala (reducir los núcleos de CPU).
Escalado
El escalamiento horizontal (agregar más mongot nodos) aumenta la CPU total para aumentar el QPS.
Nota
El escalado horizontal añade carga adicional a un conjunto de réplicas, ya que cada mongot necesita replicar los datos del índice de una colección de origen. Cada índice de búsqueda o búsqueda vectorial crea un nuevo flujo de cambios por cada mongot, lo que puede reducir el rendimiento si el conjunto de réplicas no está dimensionado para gestionar la carga de replicación adicional.
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 arquitecturas coubicadas, la configuración predeterminada ofrece un buen equilibrio. Sin embargo, para infraestructuras dedicadas, ajustar el tamaño predeterminado del montón de la JVM puede ser beneficioso. Las siguientes secciones ofrecen orientación para optimizar esta configuración según su hardware y carga de trabajo específicos.
Dimensionamiento del montón de JVM
mongot Utiliza el montón de la JVM principalmente para las estructuras de datos y cachés relacionadas con Lucene. En general, el uso del montón de mongot aumenta aproximadamente con el número de campos indexados. El uso del montón no se ve afectado en gran medida por el número de documentos ni el número de vectores. Un modelado de datos eficaz para la búsqueda de texto completo y la búsqueda vectorial generalmente minimiza el número de campos indexados.
Como estimación, asigne el 50% de la memoria total disponible del sistema, sin exceder un máximo aproximado de 30GB. Esto permite utilizar suficiente memoria para la caché del sistema de archivos del sistema operativo, que desempeña un papel fundamental en el rendimiento de Lucene al almacenar en caché los segmentos de índice del disco a los que se accede con frecuencia. De forma predeterminada, mongot asigna hasta el 25% de la memoria total disponible del sistema para el montón de la JVM, hasta 32GB (con 128GB de memoria del sistema). Estas directrices de tamaño representan un aumento con respecto a la configuración predeterminada.
Además, mantener el tamaño del montón por debajo de aproximadamente 30GB permite que la JVM utilice punteros a objetos comprimidos, ahorrando memoria. Si el tamaño del montón supera este límite de 30GB, se recomienda aumentarlo directamente a 48GB o más.
Para anular la configuración predeterminada del tamaño del montón, especifique el tamaño requerido como argumento del script de inicio mongot. Se recomienda establecer el tamaño mínimo del montón (Xms) y el tamaño máximo del montón (Xmx) con el mismo valor. Por ejemplo:
/etc/mongot/mongot --config /etc/mongot/mongot.conf --jvm-flags "-Xms4g -Xmx4g"
Caché del sistema de archivos
Se accede a los segmentos de índice mediante archivos asignados a memoria, por lo que la latencia y el rendimiento de las consultas dependen en gran medida de la caché del sistema de archivos del sistema operativo. Debe reservar suficiente memoria para la carga de trabajo de la caché del sistema de archivos. El uso de hardware aislado para mongot puede reducir la contención de la caché.
Nota
Aumentar el tamaño del montón de JVM más allá del 50% de la memoria disponible puede generar memoria insuficiente para el uso del caché del sistema de archivos.
Guía de búsqueda de vectores
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 montón de la JVM es demasiado pequeño para la carga de trabajo de indexación y consultas. Esto suele deberse a que se almacenan demasiados campos de origen o a una explosión de mapeo debido a mapeos dinámicos en datos no estructurados. Las principales recomendaciones para resolver este problema son:
Aumentar el tamaño del montón de Java (escalamiento vertical)
La solución más directa es asignar más RAM al proceso mongot. Si su host tiene memoria disponible, puede aumentar el tamaño máximo del montón de Java. Esto proporciona más espacio para sus patrones de índice y consulta 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 desea optimizar la eficiencia, puede reducir la cantidad de memoria que requiere su índice.
Revise la definición de su índice y reduzca los campos storageSource y elimine todos los campos no esenciales del índice para reducir la presión del montón.
Utilice la asignación estática. Una asignación dinámica creará un campo de índice para cada campo único en los documentos de una colección. Al ser más selectivo e indexar únicamente los campos esenciales, se reducirá el consumo del montón.
Rendimiento y almacenamiento del disco
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.
Generalmente, tanto las IOPS de lectura como las de escritura son importantes para el rendimiento de mongot. La replicación de datos implica no solo escrituras en disco, sino también lecturas, ya que los segmentos de índice antiguos se fusionan en segmentos más grandes. Por lo tanto, el rendimiento del disco tiene diversos efectos en todos los aspectos del rendimiento de mongot, desde el rendimiento de las consultas hasta el rendimiento de la indexación de sincronización inicial.
Guía de tallas
Reconstrucciones de índice
Crear o reconstruir un índice de Atlas Search consume muchos recursos y puede afectar el rendimiento del clúster. Para una indexación sin interrupciones, asigne un espacio libre en disco equivalente al 125% del espacio utilizado por su índice anterior. Este margen es importante porque el índice anterior se conserva en disco durante la reconstrucción. Como recomendación general, debería duplicar la asignación de disco para mongot para permitir la reconstrucción del índice.
Monitoring
Para realizar un seguimiento del consumo del índice actual, monitoree Search Disk Space UsedEl uso sostenido de IOPS por encima de 1K justifica una investigación.
Nota
Cuando la utilización del almacenamiento del host mongot alcanza el 90%, mongot entra en estado de solo lectura. Mientras está en este estado, mongot continúa atendiendo consultas utilizando los índices en su estado actual. Los resultados de búsqueda pueden quedar obsoletos si se realizan cambios en la colección de origen sin mitigación.
Para reanudar la sincronización del índice con las colecciones de origen, reduzca la utilización del almacenamiento a menos del 85% eliminando los datos del índice o aumentando la capacidad de almacenamiento.
Escalado
Al aumentar el tamaño de los índices y con volúmenes mayores de datos de índice, especialmente con cuantificación binaria, asegúrese de que las instancias tengan suficiente memoria para admitir conjuntos de trabajo más grandes de datos de índice. 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 consultan en su totalidad pueden ser capaces de atender consultas a baja latencia con menos memoria que el conjunto de datos del mismo tamaño que a menudo se consulta en su totalidad.
Si usa mongot con una alta proporción de almacenamiento a memoria, supervise cuidadosamente el uso de memoria. Por ejemplo, 64GB de memoria podrían no ser suficientes para 6400GB de almacenamiento.