This section offers a comprehensive overview of hardware components and their influence on the 本节全面概述了硬件组件及其对mongot process. It provides sizing guidelines, essential monitoring recommendations, and practical scaling advice.mongot进程的影响。它提供了尺寸指南、基本的监控建议和实用的缩放建议。
CPU
Impact
Increasing the number and quality of CPUs generally has a positive impact on replication throughput and query throughput (QPS). CPU is especially leveraged for queries using concurrent segment search.增加CPU的数量和质量通常会对复制吞吐量和查询吞吐量（QPS）产生积极影响。CPU尤其适用于使用并发段搜索的查询。
Sizing Guideline尺寸指南
A useful estimate based on query throughput is 10 QPS per CPU core. This is a baseline, as actual QPS is influenced by query complexity and index mappings.基于查询吞吐量的一个有用估计是每个CPU核10 QPS。这是一个基线，因为实际的QPS受到查询复杂性和索引映射的影响。
Monitoring监控
Consistently seeing CPU usage above 80% suggests a need to scale up (add CPU cores), while consistently below 20% may indicate an opportunity to scale down (reduce CPU cores).CPU使用率持续高于80%表明需要扩大规模（增加CPU内核），而持续低于20%可能表明有机会缩小规模（减少CPU内核）。
Scaling扩展
Horizontal scaling (adding more 水平扩展（添加更多mongot nodes) increases total CPU to increase QPS.mongot节点）会增加总CPU以提高QPS。
Note
Horizontal scaling adds additional load to a replica set because each 水平扩展为副本集增加了额外的负载，因为每个mongot都需要从源集合复制索引数据。每个搜索或向量搜索索引都会为每个mongot创建一个新的更改流，如果副本集的大小不足以处理额外的复制负载，则可能会降低性能。mongot needs to replicate index data from a source collection. Each search or vector search index creates a new change stream per mongot which can degrade performance if the replica set is not sized to handle the additional replication load.
Vertical scaling primarily impacts query latency by being able to serve more queries in parallel and reducing query request queuing.垂直扩展主要通过并行处理更多查询和减少查询请求排队来影响查询延迟。
Memory内存 (RAM)
Impact
mongot uses system memory for JVM heap (for Lucene-related data structures and caches) and filesystem cache (for efficiently accessing indexed data).将系统内存用于JVM堆（用于Lucene相关的数据结构和缓存）和文件系统缓存（用于高效访问索引数据）。
Sizing Guideline尺寸指南
For co-located architectures, the default settings offer a good balance. However, for dedicated infrastructure, adjusting the default JVM heap size can be beneficial. The following sections provide guidance on optimizing this setting for your specific hardware and workload.对于共置架构，默认设置提供了良好的平衡。然而，对于专用基础架构，调整默认JVM堆大小可能是有益的。以下部分提供了针对特定硬件和工作负载优化此设置的指导。
JVM Heap SizingJVM堆大小
mongot uses the JVM heap primarily for Lucene-related data structures and caches. In general, heap usage of mongot roughly scales with the number of fields indexed. mongot主要将JVM堆用于Lucene相关的数据结构和缓存。一般来说，mongot的堆使用大致与索引的字段数量成比例。Heap usage is not largely affected by the number of documents or number of vectors. Effective data modeling for full-text search and vector search generally minimizes the number of indexed fields.堆的使用在很大程度上不受文档数量或向量数量的影响。用于全文搜索和矢量搜索的有效数据建模通常会最大限度地减少索引字段的数量。
As an estimate, allocate 50% of the total available system memory, without exceeding a maximum of approximately 30GB. This allows enough memory to be used for the OS filesystem cache, which plays a vital role in Lucene's performance by caching frequently accessed index segments from disk. 作为估计，分配总可用系统内存的50%，但不超过约30GB的最大值。这允许有足够的内存用于操作系统文件系统缓存，通过缓存磁盘上频繁访问的索引段，这在Lucene的性能中起着至关重要的作用。By default, 默认情况下，mongot allocates up to 25% of the total available system memory for the JVM heap, up to 32GB (with 128GB of system memory). These sizing guidelines are an increase from this default.mongot为JVM堆分配最多25%的可用系统内存，最多32GB（系统内存为128GB）。这些尺寸准则是此默认值的增加。
Additionally, keeping the heap sizes below about 30GB allows the JVM to use compressed object pointers, saving memory. If heap sizes are increased above this 30GB limit, it is recommended that the heap size is directly increased to 48GB or larger.此外，将堆大小保持在30GB以下允许JVM使用压缩的对象游标，从而节省内存。如果堆大小增加到30GB以上，建议将堆大小直接增加到48GB或更大。
To override the default heap size settings, specify the required size as arguments to the 要覆盖默认堆大小设置，请将所需大小指定为mongot start script. It is recommended to set minimum heap size (Xms) and maximum heap size (Xmx) to the same value. For example:mongot启动脚本的参数。建议将最小堆大小（Xms）和最大堆大小（Xmx）设置为相同的值。例如：
/etc/mongot/mongot --config /etc/mongot/mongot.conf --jvm-flags "-Xms4g -Xmx4g"Filesystem Cache文件系统缓存
Index segments are accessed through memory-mapped files, so query latency and throughput heavily depend on the OS's filesystem cache. You must reserve sufficient memory for the filesystem cache workload. Using isolated hardware for 索引段是通过内存映射文件访问的，因此查询延迟和吞吐量在很大程度上取决于操作系统的文件系统缓存。您必须为文件系统缓存工作负载保留足够的内存。为mongot can reduce cache contention.mongot使用隔离硬件可以减少缓存争用。
Note
Increasing the JVM Heap size beyond 50% of available memory may result in insufficient memory for filesystem cache usage.将JVM堆大小增加到可用内存的50%以上可能会导致文件系统缓存使用的内存不足。
Vector Search Guidance矢量搜索指南
For vector search, "Search Process Memory" is used for efficient storage of data structures like the HNSW graph. 对于向量搜索，“搜索过程内存”用于高效存储HNSW图等数据结构。If the Vector Index Size exceeds 3GB, use vector quantization. 如果矢量索引大小超过3GB，请使用矢量量化。When you quantize your vectors, only 4% of the index needs to be stored in memory, rather than the full index.当你量化向量时，只需要将4%的索引存储在内存中，而不是完整的索引。
Monitoring for Insufficient Memory监控内存不足
An increase in Search Page Faults and Disk IOPS indicates the operating system is frequently retrieving necessary pages from disk, suggesting low memory. Consistently seeing Page Faults over 1000/s is an indication to consider scaling up.搜索页面故障和磁盘IOPS的增加表明操作系统经常从磁盘检索必要的页面，这表明内存不足。持续看到页面错误率超过1000/s表明需要考虑扩大规模。
Scaling扩展
If the 如果mongot process terminates with an OutOfMemoryError, it means the JVM Heap is too small for your indexing and query workload. mongot进程以OutOfMemoryError终止，则意味着JVM堆对于索引和查询工作负载来说太小。This is often caused by storing too many source fields, or a "mapping explosion" from dynamic mappings on unstructured data. The primary recommendations for resolving this issue are:这通常是由于存储了太多的源字段，或者非结构化数据上的动态映射导致的“映射爆炸”。解决这一问题的主要建议是：
Increase the Java Heap Size (Vertical Scaling)增加Java堆大小（垂直缩放）The most direct solution is to allocate more RAM to the mongot process. If your host has available memory, you can increase the maximum Java heap size. This provides more headroom for your existing index and query patterns without changing your index definition.最直接的解决方案是为mongot进程分配更多的RAM。如果主机有可用内存，则可以增加最大Java堆大小。这为现有的索引和查询模式提供了更多的空间，而无需更改索引定义。Reduce the Index Memory Footprint减少索引内存占用If scaling hardware isn't an option, or if you want to optimize for efficiency, you can reduce the amount of memory your index requires.如果扩展硬件不是一种选择，或者如果你想优化效率，你可以减少索引所需的内存量。Review your index definition and reduce storedSource fields and remove all non-essential fields from the index to reduce heap pressure.检查索引定义，减少storedSource字段，并从索引中删除所有非必需字段，以减少堆压力。Use static mapping. A dynamic mapping will create an index field for every unique field in a collection's documents. Being more selective and only indexing essential fields will reduce heap consumption.使用静态映射。动态映射将为集合文档中的每个唯一字段创建一个索引字段。更具选择性并且只索引基本字段将减少堆消耗。
Disk Throughput and Storage磁盘吞吐量和存储
Impact
Both read and write IOPS are crucial for 读写IOPS对mongot performance, affecting replication, initial sync, and query throughput. For most use cases, we recommend general-purpose SSDs.mongot性能至关重要，会影响复制、初始同步和查询吞吐量。对于大多数用例，我们建议使用通用SSD。
Generally, both read and write IOPS are important for mongot performance. Replicating data involves not only writes to disk, but also reads, as old index segments are merged into larger segments. Thus, disk throughput has various effects on all aspects of mongot performance, from query throughput to initial sync indexing throughput.通常，读写IOPS对mongot性能都很重要。复制数据不仅涉及写入磁盘，还涉及读取，因为旧的索引段被合并到更大的段中。因此，磁盘吞吐量对mongot性能的各个方面都有不同的影响，从查询吞吐量到初始同步索引吞吐量。
Sizing Guideline尺寸指南
See Disk Sizing Guideline.请参阅磁盘大小指南。
Index Rebuilds索引重建
Creating or rebuilding an Atlas Search index is resource-intensive and can impact cluster performance. For no-downtime indexing, allocate free disk space equal to 125% of the disk space used by your old index. This headroom is important because the old index is kept on disk during a rebuild. As a general recommendation, you should double the disk allowance for 创建或重建Atlas搜索索引是资源密集型的，可能会影响集群性能。对于无停机索引，请分配相当于旧索引所用磁盘空间125%的可用磁盘空间。这个余量很重要，因为在重建过程中，旧索引会保留在磁盘上。作为一般建议，您应该将mongot的磁盘容量增加一倍，以适应索引重建。mongot to accommodate index rebuilds.
Monitoring监控
To track current index consumption, monitor Search Disk Space Used. Sustained IOPS usage over 1K warrants investigation.要跟踪当前索引消耗，请监视“搜索已用磁盘空间”。IOPS使用率持续超过1K值得调查。
Note
When the 当mongot host's storage utilization reaches 90%, mongot enters a read-only state. While in this state, mongot continues to serve queries using the indexes in their present state. Search results may be stale if changes are made to the source collection without mitigation.mongot主机的存储利用率达到90%时，mongot将进入只读状态。在此状态下，mongot继续使用当前状态的索引为查询提供服务。如果对源集合进行更改而不采取缓解措施，搜索结果可能会过时。
To resume index synchronization with source collections, reduce storage utilization to below 85% by either deleting index data or increasing storage capacity.要恢复与源集合的索引同步，请通过删除索引数据或增加存储容量将存储利用率降低到85%以下。
Scaling扩展
When increasing index sizes and with larger volumes of index data, especially with binary quantization, ensure that instances have sufficient memory to support larger working sets of index data. However, the exact amount of memory required varies depending on workload.当增加索引大小和索引数据量较大时，特别是在二进制量化时，请确保实例有足够的内存来支持更大的索引数据工作集。但是，所需的确切内存量因工作负载而异。
For example, large datasets that are rarely queried in their entirety may be able to service queries at a low latency with less memory than the same size dataset that is often queried in its entirety.例如，很少整体查询的大型数据集可能能够以较低的延迟为查询提供服务，内存比经常整体查询的相同大小的数据集少。
If you use 如果你使用具有高存储内存比的mongot with high storage-to-memory ratios, carefully monitor your memory usage. As an example, 64GB of memory might not be enough for 6400GB of storage.mongot，请仔细监控内存使用情况。例如，64GB的内存可能不足以容纳6400GB的存储空间。