如何定位Milvus性能瓶颈并优化

假设您拥有一台强大的盘算机体系或一个应用，用于快速实行各种任务。但是，体系中有一个组件的速度跟不上其他部分，这个性能不佳的组件拉低了体系的团体性能，成为了整个体系的瓶颈。在软件范畴中，瓶颈是指整个路径中吞吐量最低的部分。如果机器中的某个齿轮转得不敷快，整个体系的速度都会受到影响。因此，实时辨认息争决瓶颈标题的重要性不问可知，能显著提升盘算机体系和应用的效率。
在此前的文章中，我们已经先容了评估各种向量数据库时利用的关键指标和性能测试工具。本文将以 Milvus 向量数据库为例，特殊关注 Milvus 2.2 或以上版本，讲解如何监控搜刮性能、辨认瓶颈并优化向量数据库性能。
性能评估及监控指标

在向量数据库体系中，最常用且最重要的评估指标包括召回率（Recall）、耽误（Latency）和每秒查询数（QPS）。这些指标反映了体系的正确性、相应速度以及可以或许处理的请求量。
Recall

召回率是指在搜刮查询中成功检索到的相关内容的比例。但是，通常并不是所有接近的向量都能被正确辨认。这一不敷每每源于索引算法的近似性（除了暴搜以外）。这些算法牺牲召回率以调换速度的提升。这些索引算法的配置旨在为特定生产需求寻找一个合适的平衡。更多具体信息，请参阅milvus的文档页面：内存索引和磁盘索引。
盘算召回率大概会斲丧大量资源，通常由客户端完成。由于确立 Ground truth 需要大量盘算，因此通常不会表如今监控仪表板上。在接下来的指南中，我们假定已经达到了一个可接受的召回率水平，且已经为向量索引选定了适当的索引参数。
Latency

耽误指的是相应速度——即从发起查询到接收到结果所需的时间，就好比水从一端流到另一端所需要的时间。较低的耽误可以确保更快的相应速度，这对于实时应用来说非常关键。
QPS

QPS 是衡量体系吞吐量的一个重要指标，它表现了体系每秒能处理的查询数目，类似于水流通过管道的流速。更高的 QPS 值意味着体系可以或许更有用地处理大量并发请求，这是衡量体系性能的关键因素。
QPS 和耽误之间的关系通常较为复杂。在传统数据库体系中，当 QPS 接近体系的最大容量并耗尽所有资源时，耽误每每会增加。但在 Milvus 中，体系通过批量处理查询来优化性能。这种策略减小了网络数据包的巨细，并大概同时提高耽误和 QPS，从而提升体系的团体效率。
性能监控工具

我们将利用 Prometheus 来收集和分析 Milvus 性能。别的，我们还会利用 Grafana 的可视化界面来实时发现性能瓶颈标题。
如何发现性能瓶颈

以下游程图展示了如何利用 Grafana 来有用辨认性能瓶颈。图中的黄色菱形框代表需要评估的决策点，浅蓝框则提示具体操作或更多具体信息。在文章接下来的部分中，我们将指导您按照流程图所示的每一步调监控和诊断性能标题。

条件条件

在开始监控 Milvus 向量数据库的性能之前，请先在 Kubernetes 上部署监控服务，并通过 Grafana 仪表盘对收集的指标进行可视化处理。 更多具体信息，请查阅我们的相关文档页面：

• 在 Kubernetes 上部署监控服务
  
• 设置 Milvus 集群和 K8s
  
• 在 Grafana 中可视化 Milvus 指标
  

重要提示：Grafana 的最小间隔会影响性能监控结果

在开始利用 Grafana 监控 Milvus 前，需要先注意 Grafana 中的最小表现间隔（Minimum interval）大概与设定的间隔不同等。因此，颠末平均处理后，图表中的一些尖峰大概会变得更加平滑，或者甚至不再可见。
为了解决这个标题：

• 点击指标名称，选择 Edit （编辑）或按下 e 键。
  
  
  
• 点击 Query Options（查询选项）。
  
  
  
• 将最小间隔（Min interval）改为 15 秒。
  
  
  

重要提示：NUMA 硬件会影响 Milvus 性能

非统一内存访问（NUMA）模式是多处理器体系中采用的一种内存计划方式。在 NUMA 架构下，每个 CPU 焦点都直接链接到特定的内存块。访问与实行当前任务的处理器相连的本地内存要比访问连接到其他处理器的远程内存快。当处理器需要从没有直接连接的内存块中获取数据时，由于路径较长，将会产生额外的耽误。
在 NUMA 架构的机器上部署 Milvus 时，保举利用 numactl、cpuset 或类似的工具来分配 Milvus 组件，以保证处理器的亲和性（affinity）。比方，Sapphire Rapids 处理器通常每个 NUMA 节点包含 32 焦点，而传统的处理器通常每节点有 16 焦点。可以通过在实例上实行 lscpu 命令来确认这一点。
如今，我们可以开始监控 Milvus 的性能，并查找大概存在的性能瓶颈。
1.打开 Grafana 仪表盘

成功在 Kubernetes 上部署监控服务并通过 Grafana 可视化指标之后，请打开 Grafana 仪表盘，如下所示。

注意：本文中，我们采用 Grafana V2 来进行性能监控和瓶颈分析。如果你利用的是 Grafana V1，监控流程大概会有所差别。
2.查抄每个组件的 CPU 用量

我们需要查抄几个关键组件（Proxy、QueryNode、IndexNode 等）的 CPU 利用情况。要检察每个组件的 CPU 用量，先睁开“Overview”（概览）然后选择“CPU usage”（CPU 利用率）。

注意：

• 当利用 Milvus 监控 CPU 利用率时，监控数据是在 pod 级别获取的。运行 Standalone Milvus 会表现一条单独的线，代表该 pod 的 CPU 利用情况。运行分布式 Milvus 则可以检察多个 pod 的 CPU 利用情况。在图表中，可以通过一个明显的浅蓝色线条辨认 Proxy 的 CPU 利用率，该线条触及上限阈值时，表示已达到 CPU 上限。
  
• 如果面板丢失，且在“Service Quality”（服务质量）下找不到任何图表，您可以：
  

• 检察“Runtime”（运行时）下的 CPU Usage。这里表现的是 Kubernetes 的单元利用情况，而非百分比。
  
  
  
• 或添加 pod 用量面板。点击 “Add”（添加）按钮并选择“Visualization”（可视化）。
  

• 输入 PromQL 查询。
  
  1. sum(rate(container_cpu_usage_seconds_total{namespace="$namespace",pod=~"$instance-milvus.*",image!="",container!=""}[2m])) by (pod, namespace) / (sum(container_spec_cpu_quota{namespace="$namespace",pod=~"$instance-milvus.*",image!="",container!=""}/100000) by (pod, namespace))

  复制代码
  
  
  

• 选择“Unit”（单元）。
  
  
  

• 保存设置。
  

Proxy

当 QPS 较高并且实行网络密集型任务时，如搜刮 Top-K 较大、启用 Partition key 以及在输出字段返回向量等，Proxy 大概会成为瓶颈。
如何解决这个标题？

要解决这个标题，您可以：

• 垂直扩展 Proxy：增加主机的 CPU/内存
  
• 水平扩展：增加更多 Proxy pods，并在前端利用负载平衡器（Load balancer）
  

QueryNode

如果查询节点（QueryNode）的性能受到 CPU 利用率的限制，大概有几个原因，您可以根据以下游程图所示的指示进行操作。

如果某个查询节点的 CPU 利用率达到 100%，如图所示，它大概承担了分发器（Delegator）的角色。

在 Milvus 中，Delegator 的作用类似于军队的指挥官。当搜刮请求提交给 Proxy 时，Proxy 首先将请求发送至 Delegator，随后再将其分发到其他 QueryNode 并开始在各个 Segment 上实行搜刮。搜刮结果将按反向序次返回。您可以通过选择：QueryNode > DML virtual channel 来验证 QueryNode 是否承担了 Delegator 的角色。

要检察段 Segment 的团体分布情况，请在仪表盘上选择“Query（查询） > Segment Loaded Num（已加载 Segment 数目）”。

如何解决这个标题？

基于您所插入的数据量，维护云云之多的 QueryNode 是否必要？过多的 QueryNode 大概导致 Delegator 需要处理更多的消息，从而低落团体性能。因此，缩减 QueryNode 的数目大概有助于减轻 Delegator 的负担。
别的，还可以考虑垂直扩展 QueryNode——这包括增加托管 QueryNode 的单个 pod 或实例的盘算资源，比方 CPU 和内存。这样的调整可以或许显著提升处理本领，而不增加 Delegator 承担的消息负载。
如果您的数据库是静态的，可以通过手动将数据 Segment 平衡到其他查询节点来解决这个标题，这样 Delegator 就不进行 Segment 搜刮，只专注于请求的分发和结果的简化。实施步调包括：

• 在 Milvus 的 YAML 文件中关闭 autoBalance 功能。
  
• 通过 SDK 调用 LoadBalance API。参见：平衡查询负载。
  

如果您关闭了 autoBalance 并且向数据库中添加了新的向量，您大概需要重新触发 LoadBalance。
注意：如果您已经按照上述步调操作，但 Delegator 仍是性能瓶颈，那么请通过 GitHub 提交标题或直接与我们接洽。
IndexNode

当 IndexNote 的 CPU 利用率达到 100% 时，通常是由于 IndexNodes 正在创建索引。如果搜刮请求不紧急且新数据的输入暂时停止，发起让 IndexNode 完成索引创建的过程。这样做可以确保在开始任何搜刮操作之前，所有的索引都已创建成功。在数据插入的同时进行搜刮查询大概会显著低落搜刮性能。性能下降的程度受到多种因素的影响，包括您插入向量的方式以及您是否盼望在插入后立刻返回这些新插入的向量。
如何解决这个标题？

我们提供一些策略可以最小化影响：

• 如果条件允许，发起采用批量插入而不是单个插入向量。这可以减少网络传输并绕过“Growing segment”，从而加速数据插入和搜刮。更多相关信息，请参考 Bulk insert 文档。
  
• 如果不要求数据即时可见，可以考虑以下发起：
  
  
  
  • 忽略 Growing segments；在搜刮参数中利用 ignore_growing，具体方法请参考 https://milvus.io/docs/search.md。
    
  • 在 API 调用是将搜刮的同等性品级（Consistency level）设置为 Eventually。更多详情，请参考 https://milvus.io/docs/consistency.md。
    
  
  

其他组件

在 Milvus 的架构中，MixCoord、DataNode 等组件用于高效实行各自的任务，通常不会成为搜刮性能的瓶颈。但是，如果监控结果表明这些组件的 CPU 利用率接近或达到满载，暗示大概出现瓶颈，那么请立刻扩展这些组件。
3.查抄利用的 Milvus 版本

如果您利用的是 Milvus 2.3.x 或以上版本，请跳过此步调。
Milvus 2.2.x 及以下版本允许用户估算其 CPU 资源斲丧，但这一功能在 Milvus 2.3.x 及后续版本中已被删除，由于它大概导致性能标题。
下方图表的 y 轴表示 CPU 数目与百分比的乘积，比方，12个 CPU 的完全利用率在 y 轴上的表现值为1200。

阐明：这种估算偶然大概会错误地表现为 CPU 的忙碌程度，导致实际 CPU 利用率较低时仍发生任务排队。
如何解决这个标题？

发起将 queryNode.scheduler.cpuRatio 的值调低，其默认值为10.0。
4.查抄磁盘性能

如果您在创建索引时选择利用 DiskANN，请查抄磁盘性能。
对于 DiskANN 索引类型，保举利用 NVMe SSD。在 SATA SSD 或 HDD 上创建和搜刮磁盘索引大概会由于 I/O 操作受限而导致较大的 Latency 和较低的 QPS。
如需检测磁盘性能，您可以利用 fio 或其他类似的 I/O 性能测试工具来评估 IOPS。一个 NVMe SSD 的 IOPS 应接近 500k。

2. # Write Test
4. fio -direct=1-iodepth=128 -rw=randwrite -ioengine=libaio -bs=4K -size=10G -numjobs=10 -runtime=600 -group_reporting -filename=/fiotest/test -name=Rand_Write_IOPS_Test
6. # Read Test
8. fio --filename=/fiotest/test --direct=1 --rw=randread --bs=4k --ioengine=libaio --iodepth=64 --runtime=120 --numjobs=128 --time_based --group_reporting --name=iops-test-job --eta-newline=1  --readonly

复制代码

在 Grafana 中检察 pod 级别的 IOPS：

• 在右上角，点击“Pod”，然后选择“Kubernetes / Compute Resources / Pod”。如果您在利用 V2 仪表盘，请点击“Milvus2.0”。
  
  
  
• 选择您想要查抄的 pod：
  
  
  
• 向下滚动并找到“Storage IO”。
  
  
  

如何解决这个标题？

• 考虑将 SATA SSD 或 HDD 升级到 NVMe SSD，以低落您当前体系的 Latency。多数云服务提供商，比方 AWS，提供 NVMe SSD 的存储选项。比如，AWS 的 m6id 实例在 m6 系列中就配备了基于 NVMe 的本地 SSD。但需要注意的是，虽然 EBS 采用 NVMe 驱动，但其提供的低耽误优势并不及本地 NVMe SSD。
  
• 在磁盘索引方面，我们强烈发起选择 NVMe SSD。如果您现在利用的是 SATA SSD 或 HDD，将它们配置为 RAID（独立磁盘冗余阵列）可以帮助减少耽误。
  

5.查抄带宽

带宽限制每每会在体系中形成关键瓶颈，但这种挑战大概每每不会立刻显现——大概会出现体系性能提升但 QPS 仍然不变的情况，或者像 gRPC 操作实行时间意外延伸这样的间接效果。
理解带宽在这些场景中的角色对于诊断息争决性能限制是至关重要的。比方，在查询维度为 1024 且 TopK 设为 100 的 KNN 搜刮请求中，每个请求大概斲丧大约 4.8 KB，用于客户端与代理之间的双向通信。1000 的 QPS 意味着大约 4.7 MB的数据通过通道传输。因此，带宽至少应能支持 37 Mbps，以避免拉低 QPS。

虽然初看大概不以为重要，但提高每秒查询数（QPS）或在输出字段中参加向量会大幅增加所需带宽。举个例子，如果输出字段需要包含向量，上述例子中需要的带宽会上升至至少 3 Gbps。
尽管进行这些盘算大概比较繁琐，但利用 Grafana 这类监控工具可以帮助查抄进出带宽，有用评估体系性能。

注意:如果您以集群模式部署Milvus，请不要忘记查抄Milvus pods之间的带宽。
下图仅表现proxy的网络利用情况:

如何解决这个标题？

• 增加带宽
    为了应对带宽限制，您可以考虑通过云平台控制台增加带宽，或接洽云服务提供商或 DevOps 团队以得到支持。
  
• 启用压缩
    我们正在 Milvus 中开发一项新功能，该功能将支持在 Milvus 各组件间以及 Milvus 与 SDK 客户端间实施 gRPC 压缩。通过压缩数据，可以或许显著低落数据量，虽然这大概因编解码过程而增加 CPU 利用率。预计该功能将在 Milvus 2.4.x 版本中推出，敬请期待！
  

6.查抄性能测试客户端

设想这样一个场景：一个水龙头徐徐地向一根大水管滴水。如果水龙头的出水量很小，那么它将永世无法达到水管的最大容量。同理，当一个客户端每秒只发送少数几个请求时，它无法充分发挥 Milvus 处理大量数据的本领。为了验证客户端是否是性能瓶颈，您可以尝试以下方法：

• 增加并发数，检察是否有差别。
  
• 在差别的盘算机或主机上部署多个客户端进行测试。
  

如何解决这个标题？

如果发现客户端是性能瓶颈，请考虑增加请求的数目。

• 查抄并调整大概限制数据流的网络限制器。
  
• 如果您利用 PyMilvus：
  

a.在多进程操作中，选择利用 spawn 方法而非 fork。
b.在每一个进程中，实行以下操作：导入 from pymilvus import connections，然后运行 connections.connect(args)。
      3.进行水平扩展——增加客户端数目，直至 QPS 值稳固。
接洽我们

我们盼望这份指南可以或许帮助您充分提升 Milvus 性能！但如果您无法定位性能瓶颈或在解决性能标题时需要帮助，欢迎随时接洽我们。我们随时准备帮助您突破这些挑战！
欢迎通过以下方式接洽我们：

• 提交 GitHub issue
  
• 参加 GitHub Discussions
  
• 参加 Milvus Discord 社区
  

点击下方链接，立刻体验Zilliz Cloud：
Zilliz Cloud 向量数据库?utm_source=csdn

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。