概述

本文介绍了在高负载情况下如何对 UniFi Network 网络应用程序进行调整,以获得最佳性能体验。

注意事项和要求:
  • 适用于已发布的最新 UniFi Network 网络版本。
  • 本文介绍了高级配置选项,但仅推荐具备相关知识的高级用户尝试。
  • 有关 system.properties 文件的更多信息,请参阅 UniFi - system.properties 文件解析一文。
  • 在阅读本文之前,请参阅知识库文章 UniFi - 如何创建和恢复备份,然后创建备份,将备份配置导出/保存到单独的设备。

目录



介绍


在管理大型 UniFi 部署项目时,因为上百个设备和数个站点都由一个 UniFi Network 网络应用程序进行管理,所以您需要多加考虑某些问题。在如此高负载的情况下运行 Network 网络应用,如果仍然使用轻负载相同的系统配置,可能会出现一些问题。对这些问题进行诊断并加以解决,以优化应用程序的性能。

下文介绍了改变或添加 system.properties 文件的参数,从而修改 UniFi Network 网络应用的配置。详情请参阅 UniFi - system.properties 文件解析

警告: 在进行下文概述的配置之前,请对服务器和应用程序进行备份。输入错误可能会损坏系统。详情请参阅 UniFi - 如何创建和恢复备份

症状:CPU 使用率高


监控的重要指标之一就是 UniFi OS 控制台(或其他主机架设的 UniFi Network 网络应用程序)上的 CPU 使用率。CPU 使用率高是问题的表象,故仅靠提高 CPU 性能并不能从根本上解决问题,它并不是完美的答案。

分配额外的内存

在增加机器上的 RAM 分配之前,首先尝试增加 XMX 和 XMS 选项的值。默认情况下,UniFi Network 网络应用程序将这些值设置为 1GB。 以下命令行可以将 xmxxms 的值设置为 2GB (2048MB) :

unifi.xmx=2048
unifi.xms=2048

以上操作将 UniFi Network 应用允许消耗的内存从 1 GB 增加到了 2 GB。没有足够的内存会导致 CPU 使用率过高,因为 Java 虚拟机将花费太多 CPU 周期来进行垃圾回收,以保持分配给应用程序的内存在 1 GB 以内。所以,在迁移到有更多 CPU 资源的设备之前,建议进行上述操作,最大化该设备上的可用内存。在完成操作后,可以观察 CPU 使用率是否下降。如果 2GB 不够,管理员可视网络规模将限制提高到 4-8GB。 在这种情况下,内存应以 1024 的增量递增,即 4 GB= 4096。

注意: jstat -gcutil Java 命令可用于检查您机器上的内存分配是否足够。 详情请参阅 Oracle 文档

增加 Mongo WiredTiger 引擎缓存

如果您已经将 UniFi Network 网络应用程序内存设置,增加到了 4GB (xmx)或以上,那么您可能还需要更改默认的 Mongo WiredTiger 引擎缓存。 默认情况下,UniFi Network 网络应用程序使用该命令行:

db.mongo.wt.cache_size=256

在 UniFi Network 6.5.13 及更高版本上,您可以更改此设置,或让 Mongo 使用以下方法选择默认值:

db.mongo.wt.cache_size_default=true

详情请参阅 Mongo 文档

启用高性能 Java 垃圾回收

如果增加内存没有解决问题,管理员也可以考虑将此命令行添加到System.properties文件(注意,这仅适用于非 Cloud Key 设备):

unifi.G1GC.enabled=true

该操作启用了有助于优化性能的新 Java 垃圾回收。但是,如果在更改后, CPU 使用率在内存增加后仍然很高,那么就需要一台具有更多 CPU 内核和更大内存的服务器来处理工作负荷。

更改 Mongo 版本/引擎

如果问题没有解决,管理员可以考虑将 MongoDB 版本更新到 3.2+。使用 WiredTiger 作为存储引擎,可以更好地扩展 UniFi Network 网络部署。详情请参阅:


症状:心跳(Heartbeat)丢失或参数同步缓慢


无论负载如何,所有的设备都会尝试反馈信息给 Network 网络应用程序。默认情况下,应用程序可以同时处理来自 200 个设备的连接,因此除非单个应用程序管理数千台设备,否则心跳丢失应该不是因为设备过多。如果只是管理几百个设备,可以按照本节中的步骤进行优化,但可能无法达到预期效果。可以在 system.properties 文件中进行设置,修改可以同时处理的反馈信息数量。请添加以下命令行调整数值,添加的位置并不重要:

inform.num_thread=200
inform.max_keep_alive_requests=100

默认值为 200,max_keep_alive_requests 值应始终低于 num_thread。调整后,应该可以看到设备稳定性的提高,控制器将配置同步给其他设备后,会更加稳定。


优化数据库连接


在进行大型 UniFi 部署项目时,可能需要运行外部 Mongo 集群,以便能够独立于 UniFi Network 网络应用程序,进行数据库扩展。您可以在我们社区的 Beta 版论坛上找到相关讨论(需要 Early Access 早鸟账户访问权限)。如果在 Mongo 进程上看到 CPU 使用率高,则可能表明需要更大的内存,或者需要如上所述分离 mongodb 进程。完成后,输入以下命令行进行调整,查看性能是否得到改善:

db.mongo.connections_per_host=100
db.mongo.threads_multiplier=5

以上调整会导致 500 个线程等待 Mongo 连接。但是请记住,更多的线程可能意味着更高的 CPU 使用率,因为 CPU 必须在线程之间进行切换。 它可能实现更高的数据库吞吐量,但前提是 Mongo 进程能够消耗更多的 CPU 资源,以更快地服务于请求。


结论


请确保您对系统资源进行监控,这是提高性能并为大型部署项目提供稳定管理的最佳方法。除此之外,还有降低数据库工作负载和增加内存等方式,这可以让 UniFi Network 网络为更多的客户端和设备提供服务,这会体现在 UniFi Network 网络应用的资源占用和性能上。


相关文章