概述

本文介绍了在高负载情况下如何对 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。以下命令行可以将 xmx 和 xms 的值设置为 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 网络应用的资源占用和性能上。

UniFi - 在高负载情况下优化 Network 网络应用程序

概述

目录

介绍