本节将全面概述硬件组件及其对 mongot进程的影响。它提供了大小调整指南、基本监控建议和实用的扩展建议。
CPU
影响
增加 CPU 的数量和质量通常会对复制吞吐量和查询吞吐量(QPS) 产生积极影响。使用并发分段搜索的查询尤其会充分利用 CPU。
大小调整指南
基于查询吞吐量的有用估计值是每个 CPU 核心 10 QPS。这是基线，因为实际 QPS 受查询复杂性和索引映射的影响。
监控
CPU 使用率持续高于 80% 表明需要扩展（添加 CPU 核心），而持续低于 20% 则可能表明需要扩展（减少 CPU 核心）。
扩展(Scaling)
水平扩展（添加更多 mongot 节点）会增加 CPU 总量以提高 QPS。
注意
水平扩展会增加副本集的额外负载，因为每个 mongot 都需要从源集合复制索引数据。每个搜索或向量搜索索引每次 mongot 创建一个新的变更流，如果副本集的大小不足以处理额外的复制负载，则可能会降低性能。
垂直扩展主要通过并行提供服务更多查询并减少查询请求队列来影响查询延迟。
内存 (RAM)
影响
mongot 将系统内存用于Java虚拟机（JVM）堆（用于 Lucene 相关的数据结构和缓存）和文件系统缓存（用于高效访问索引数据）。
大小调整指南
对于并置架构，默认设置可以实现良好的平衡。但是，对于专用基础架构，调整默认Java虚拟机（JVM）堆大小可能有益。以下部分提供了有关针对特定硬件和工作负载优化此设置的指导。
Java虚拟机（JVM）堆大小调整
mongot 主要将Java虚拟机（JVM）堆用于 Lucene 相关的数据结构和缓存。一般来说，mongot 的堆使用量大致与索引字段的数量成正比。堆使用量在很大程度上受文档数量或向量数量的影响。全文搜索和向量搜索的有效数据建模通常会最大限度地减少索引字段的数量。
作为估计，分配总可用系统内存的 50%，但不超过约 30 GB的最大值。这样就可以为操作系统文件系统缓存使用足够的内存，通过缓存磁盘中经常访问的索引段，对 Lucene 的性能发挥着至关重要的角色。默认下，mongot 会为Java虚拟机（JVM）堆分配最多可用系统总内存的 25%，即 32 GB （其中包括 128 GB的系统内存）。这些大小调整指南是在此默认上增加的。
此外，通过将堆大小保持在约 30 GB以下， Java虚拟机（JVM）可以使用压缩的对象指针，从而节省内存。如果堆大小增加到超过此 30 GB限制，建议直接将堆大小增加到 48 GB或更大。
要覆盖默认堆大小设置，请将所需的大小指定为 mongot 启动脚本的参数。建议将最小堆大小 (Xms) 和最大堆大小 (Xmx)设立为相同的值。示例：
/etc/mongot/mongot --config /etc/mongot/mongot.conf --jvm-flags "-Xms4g -Xmx4g"
文件系统缓存
索引段是通过内存映射文件访问的，因此查询延迟和吞吐量在很大程度上取决于操作系统的文件系统缓存。您必须为文件系统缓存工作负载保留足够的内存。对 mongot 使用隔离的硬件可以减少缓存争用。
注意
将Java虚拟机（JVM）堆大小增加到超过可用内存的 50%，可能会导致内存不足，无法用于文件系统缓存。
向量搜索指南
For vector search, "Search Process Memory" is used for efficient storage of data structures like the HNSW graph. If the Vector Index Size exceeds 3GB, use vector quantization. When you quantize your vectors, only 4% of the index needs to be stored in memory, rather than the full index.
监控内存是否不足
搜索页面错误和磁盘 IOPS 的增加表明操作系统频繁地从磁盘检索必要的页面，从而表明内存不足。如果页面错误持续超过 1000/s，则表明需要考虑向上扩展。
扩展(Scaling)
如果 mongot进程以 OutOfMemoryError 终止，则表示Java虚拟机（JVM）堆对于索引和查询工作负载而言太小。这通常是由于存储了太多源字段或非结构化数据上的动态映射导致的“映射爆炸”造成的。解决此问题的主节点 (primary node in the replica set)建议是：
增加Java堆大小（垂直扩展）
最直接的解决方案是为mongot进程分配更多RAM 。如果托管有可用内存，则可以增加最大Java堆大小。这为现有索引和查询模式提供了更多空间，而无需更改索引定义。
减少索引内存占用
如果无法扩展硬件，或者想要优化效率，则可以减少索引所需的内存量。
查看索引定义，减少 StoredSource 字段，并从索引中删除所有非必需字段，以降低堆压力。
使用静态映射。动态映射将为集合文档中的每个唯一字段创建一个索引字段。更具选择性并仅对关键字段索引将减少堆消耗。
磁盘吞吐量和存储
影响
读取和写入IOPS 对于 mongot 性能至关重要，会影响复制、初始同步和查询吞吐量。对于大多数使用案例，我们建议使用通用固态硬盘。
一般来说，读取和写入IOPS 对于mongot性能都很重要。复制数据不仅涉及写入磁盘，还涉及读取，因为旧索引段会合并成更大的段。因此，磁盘吞吐量对mongot性能的各个方面都有不同的影响，从查询吞吐量到初始同步索引吞吐量。
大小调整指南
请参阅磁盘大小调整指南。
索引重建
创建或重建Atlas Search索引会占用大量资源，可能会影响集群性能。对于不停机索引，分配的可用磁盘空间等于旧索引所用磁盘空间的 125%。这个空间很重要，因为在重建过程中旧索引保留在磁盘上。作为一般建议，您应将 mongot 的磁盘容量增加一倍，以适应索引重建。
监控
要追踪当前索引消耗，监控Search Disk Space Used。IOPS 使用率持续超过 1K 值得进行调查。
注意
当 mongot 主机的存储利用率达到 90% 时，mongot 进入只读状态。在此状态下，mongot 会继续使用处于当前状态的索引提供查询提供服务。如果在没有缓解措施的情况下对源集合进行更改，搜索结果可能会过时。
要恢复索引与源集合的同步，请删除索引数据或增加存储容量，将存储利用率降低到 85% 以下。
扩展(Scaling)
增加索引大小和使用更大的索引数据时，尤其是使用二进制量化时，请确保实例有足够的内存来支持更大的索引数据工作集。但是，所需的确切内存量因工作负载而异。
示例，与经常进行整体查询的相同大小数据集相比，很少进行整体查询的大型数据集可能需要更少的延迟，以低延迟提供查询服务。
如果您使用具有较高存储与内存比率的 mongot，请仔细监控内存使用情况。示例，64 GB内存可能不足以用于 6400 GB存储。