VPS 上 Nextcloud 的真实限制有哪些？

Nextcloud 不擅长的方面，以及通常遇到它们的顺序

VPS 上 Nextcloud 的大多数限制来自文件数量和请求数量，而不是磁盘容量。一个包含 200 GB 视频文件的库在小型服务器上通常运行良好。同样是 200 GB，如果分散在 400,000 个小文件中，每次列出目录都会变慢，数据库也会成为服务器上最繁忙的进程。下面的顺序就是自托管用户通常遇到这些限制的顺序：先是 PHP 请求模型，然后是同步客户端，接着是数据库默认设置，再之后是后台任务，最后是内存。

有些人所说的“Nextcloud 很慢”，其实是因为某个默认设置从未被修改。其余问题则属于设计本身，调优无法消除。每个部分都会说明问题属于哪一种。

PHP 如何决定并发上限

Nextcloud 使用 PHP 编写，而 PHP 应用不是长期运行的服务器。每个请求由 PHP-FPM（FastCGI process manager）池中的一个工作进程处理，该工作进程从请求开始一直负责到请求结束。因此，服务器可同时处理的请求数为 pm.max_children，并且每个工作进程都有自己的内存。

这会带来两个结果。慢请求会在整个处理期间占用一个工作进程，因此一个用户组装 4 GB 上传内容时，会占用一个其他用户无法使用的槽位。当所有工作进程都处于忙碌状态时，新请求会在 socket backlog 中等待。池会在日志中记录这一点：

WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

用户通常会先在前端 Web 服务器处看到这一症状，表现为 504：

upstream timed out (110: Connection timed out) while reading response header from upstream

发行版提供的默认池通常配置为 pm.max_children = 5。对于共享服务器，这是合理的估值；但对于连接了十几个同步客户端的 Nextcloud 实例，这个值远远不够。应根据实际可用内存进行调整：测量繁忙工作进程的常驻内存大小，为数据库和缓存预留空间，然后进行计算。

pm = dynamic
pm.max_children = 12
pm.max_requests = 500
php_value[memory_limit] = 512M

memory_limit 是每个请求的上限，不是预先分配的内存。大多数请求只会使用其中很小一部分。预览生成和大文件上传组装会占用更多内存，因此必须同时选择内存上限和子进程数量。

不同请求之间也不会共享应用程序内存。每个请求都会再次启动框架：加载配置、启用的应用、路由和事件监听器。OPcache 会保留编译后的字节码，因此这里执行的是字节码，而不是重新解析源代码；APCu（alternative PHP cache）则会在共享内存中保存一个小型本地键值存储。因此，管理概览中的“未配置内存缓存”这一行很重要。没有内存缓存时，本可从内存中完成的查找，会在每个请求中都访问数据库。这部分属于配置。底层每个请求对应一个进程的模型则属于架构。

为什么小文件数量远在磁盘出现瓶颈前就会造成影响

Nextcloud 会在同一个数据库表中为每个文件和文件夹保存元数据，oc_filecache：路径、路径哈希、大小、修改时间、etag 和存储 ID。列出文件夹内容时，系统查询的是该表，而不是在磁盘上执行 readdir。写入文件时，系统会更新该文件的行，然后将新的大小和 etag 逐级更新到每个父文件夹，直到根目录。一次上传对应一个 HTTP 请求、若干条 SQL 语句，以及按目录深度对每一级执行一次更新。

传输同样以文件为单位。同步协议是 WebDAV（基于 Web 的分布式创作和版本控制），WebDAV 每个请求只传输一个文件。400,000 个文件意味着 400,000 个请求，每个请求都要执行身份验证、框架初始化、权限检查和数据库写入。按每个请求占用 25 ms 的服务器处理时间计算，仅这些开销就接近三个小时，还不包括任何有效负载字节。这里只是算术估算，不是基准测试。它说明了最重要的一点：成本取决于文件数量，而不是文件大小。

更快的存储可以改善其中一部分问题。随机小块读写正是 NVMe 和 SATA SSD VPS 存储差异最大的场景，因此大型实例使用 NVMe 是值得的。但它无法消除每个请求的固定成本，因为这部分成本来自 PHP 和 SQL，而不是磁盘。

有一个后果几乎所有人都会遇到。直接复制到服务器、但未通过 Nextcloud 写入的文件，对 Nextcloud 来说并不存在，因为数据库中从未写入对应的行。只有在 occ files:scan 遍历目录树并写入缺失的行后，这些文件才会出现；对于大型目录树，这次扫描会持续很长时间。如果你不确定容器安装中的这些文件位于哪里，请参阅 Nextcloud 在 Docker 中的数据目录结构，那是另一篇独立教程。本文讨论的是架构问题：文件列表由数据库提供。

大型目录树上桌面客户端变慢的原因

同步客户端的实际性能优于通常的评价。由于写入会将新的 etag 逐级传播到根目录，客户端可以先发起一个开销很低的请求，判断是否发生了任何变化，然后只进入 etag 不同的目录。仅在空闲时轮询本身并不昂贵。

仍然存在一些实际开销。首次同步会遍历每个目录，每个目录发送一个 PROPFIND 请求，并下载每个文件。目录树上层附近的重命名会改变其下所有内容的 etag，因此客户端会重新检查整个子树。客户端还会维护自己的本地数据库，并对本地文件执行 stat，因此，笔记本电脑磁盘速度较慢或防病毒扫描程序扫描过于频繁，也会增加延迟，这与服务器完全无关。

没有 Client Push 应用时，notify_push，每个已连接客户端都会按计时器轮询。30 个客户端会持续向同一个工作进程池发送后台请求，而该工作进程池还负责提供 Web 界面。notify_push 是一个独立的小型服务，为每个客户端保持一个 websocket，并在发生变化时通知客户端，从而消除大部分空闲流量。在繁忙实例上，这是最值得添加的功能之一。

不会执行合并。两个人在离线状态下编辑同一个文件时，会生成一个冲突副本，名称类似于 budget (conflicted copy 2026-08-22 141530).ods，然后由人工解决冲突。通过办公服务编辑可以避免这种情况，因为此时服务器上始终只有一个副本具有权威性。虚拟文件在打开前仅显示为占位符；该功能在 Windows 和 macOS 上较为稳定，但在 Linux 上经过了更长时间才趋于稳定，因此在围绕它规划工作流之前，请先检查客户端版本。轮询属于配置。每个文件发送一个请求属于架构设计。

默认安装未完成的配置

全新的 Nextcloud 可以正常运行。但在典型的手动安装中，仍有 4 项配置未完成，且都显示在“设置”中的“管理”→“概览”页面。

• 未配置内存缓存。概览页面显示“尚未配置内存缓存”。APCu 几乎不占用额外资源，并可减少大量重复的数据库查询。
• 在数据库中进行文件锁定。Nextcloud 在写入文件时会锁定该文件。未使用 Redis 时，锁会保存在数据库表中，从而增加写入负载；请求异常终止后还会留下过期锁。用户随后会看到文件已锁定的错误，只有手动清理才能移除这些锁。
• 缺少数据库索引。概览页面显示“数据库缺少部分索引”，并列出 occ db:add-missing-indices。对于包含数百万行的 filecache，这些索引决定了文件列表加载是快速还是缓慢。
• 使用 SQLite。手动安装最终可能会使用 SQLite，而文档仅建议将其用于单用户环境和测试。SQLite 会串行处理写入，因此同时活跃的第 2 个用户就已经超出适用范围。

'memcache.local' => '\\OC\\Memcache\\APCu',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' => [
  'host' => 'localhost',
  'port' => 6379,
],

这些问题都不复杂，全部属于配置问题。如果您希望从一开始就使用已完成这些配置的安装方式，可以使用包含 TLS 和备份的 Docker 安装，该方式会在同一套服务中启动缓存和 cron 容器。

未配置 cron 时后台作业为何会停滞

Nextcloud 将实际工作放入后台作业中：生成预览、删除过期的旧文件版本、按计划清空回收站、发送通知邮件以及清理共享。支持 3 种运行方式，但默认方式最不可靠。

AJAX 模式会在浏览器加载页面时运行一个作业。对于一周无人访问的个人实例，作业也会整整一周不运行。文件版本和回收站内容不会过期，因此磁盘会持续被用户以为已经删除的数据占满。系统不会预先生成预览，因此第一个打开照片文件夹的用户必须等待，由其请求生成预览。最终，概览页面会报告上次后台作业是在数小时前运行的，并显示“似乎出了问题”，而这就是你能得到的唯一警告。

Webcron 和 system cron 都能解决这个问题。system cron 会以 Web 服务器用户身份每 5 分钟运行 cron.php，容器安装则会从专用 cron 容器中运行相同的命令。文档规定的运行间隔是 5 分钟，作业间隔也是围绕这一间隔调整的。

剩下的问题是，作业会串行执行。一个耗时较长的作业、预览批处理或文件扫描会延迟其后的所有排队作业；在单核 VPS 上，该进程还会与实时请求争用 CPU。在繁忙的主机上，嘈杂邻居造成的 CPU steal time 会使这些运行时间超出你根据自身数据做出的预测。配置是大多数被忽略实例上价值最高的单项修复。

添加 Office、Talk 或预览后所需的内存下限

纯 Nextcloud 的资源占用并不高：PHP 进程池、数据库、Redis 和 Web 服务器。小型实例使用 2 GB 内存即可正常运行。用户实际需要的每项功能，通常都是独立服务，并有各自的内存下限。

预览。 默认情况下，系统会在首次请求预览时生成它，因此用户必须在当前请求中等待。Preview Generator 应用会将这项工作转移到 cron，在 cron 运行期间消耗 CPU，以换取请求不再等待。无论采用哪种方式，每张源图像都会生成多个不同尺寸的预览文件，因此照片库会使文件数量成倍增加，并进一步加剧前文所述的小文件问题。大尺寸源图像也最容易触及内存限制，PHP 错误日志中会出现 Allowed memory size of 536870912 bytes exhausted。应使用 preview_max_x 和 preview_max_y 限制这项消耗，而不是无限提高内存限制。

Office。 Collabora Online 和 OnlyOffice Docs 都作为独立服务运行，通常位于单独的容器中，并各自需要运行时和内存。文档会话消耗的是这些服务的 CPU 和 RAM，而不是 PHP 的资源。在系统运行流畅前，应预留 1 到 2 GB 内存；确定服务器规格前，请阅读供应商截至 August 2026 的最新要求。两者的差异不只是资源占用，自托管时比较 OnlyOffice 与 Collabora对此有详细说明。

Talk。 少数参与者之间的通话会通过 WebRTC 进行点对点连接，服务器只传递信令消息。参与者超过约 4 人后，Nextcloud 官方建议使用 High Performance Backend，即独立的信令服务器。许多网络还需要 TURN（通过 NAT 周围的中继进行穿透）服务器，例如 coturn。中继媒体流会经过 VPS，因此带宽会成为一项实际成本。

全文搜索。 Elasticsearch 实例在建立任何索引前，通常就需要为自身预留 1 GB 或更多堆内存。

Nextcloud 需要多大规格的 VPS？

仅按用户数量估算容易产生误导，因为实际行为的影响更大。5 名同步 300,000 个文件的源代码树的开发者，其负载可能高于30 名只在浏览器中打开文档的用户。以下配置仅用于起步，应结合您自己的文件数量进行测试，不能视为实际测量结果。

• 1 vCPU 和 1 到 2 GB：适用于1到2名用户，仅使用文件和日历功能，严格限制预览生成，且不运行办公服务。在这台服务器上，升级和完整文件扫描将是最慢的操作。
• 2 vCPU 和 4 GB：适用于大约5到15名普通用户，并启用 APCu、Redis 锁、系统 cron，以及由 cron 生成预览。
• 4 vCPU 和 8 GB：适用于相同数量的用户并运行办公服务，或适用于15到40名不使用办公服务的轻量用户。这里的内存主要由办公会话消耗。
• 4 个或更多 vCPU 和 16 GB：适用于 Talk 配合 High Performance Backend、全文搜索，或对照片库批量生成预览。

磁盘容量需要单独计算。预览、文件版本和回收站数据都会叠加在实际数据之上，只有后台任务确实运行时，这些数据才会减少。整体成本是否低于订阅费用，取决于这些数据；自托管存储与 Dropbox 定价的对比会据此完成计算。

哪些 Nextcloud 限制可以通过配置解决，哪些属于架构限制

以下问题可以在一个下午内修复：内存缓存和 Redis 锁、缺失的数据库索引、后台作业模式、FPM 进程池大小和 PHP 内存限制、OPcache 大小、notify_push 以及预览范围。在相同硬件上完成这些调整后，该实例与默认安装相比，已经是不同的软件系统。

无论如何调优，以下限制都不会消失：

• 每个请求使用一个进程。并发能力受 RAM 限制，一个慢请求会在整个处理期间占用一个 worker。
• 每个文件对应一行数据库记录，文件大小和 etag 会沿每级父目录向上汇总。开销随文件数量增长。
• 网络上每个文件对应一个请求。同步大量小文件时，瓶颈通常是请求开销，而不是带宽。
• 这是一个内置文件应用的协作平台。其基础开销包含纯同步工具不会加载的组件。
• 升级按顺序执行。主版本必须逐个升级，并在维护模式下运行；每一步都必须先解决应用兼容性问题。

这些都不是 bug，而是共享链接、外部协作者、移动客户端以及统一账户系统所带来的代价。购买企业版可以获得支持和一些额外应用，但不会改变上文所述的请求模型。这也是免费版 Nextcloud 实际包含的内容所说明的事项之一。

不应在 VPS 上运行 Nextcloud 的情况

• 您只想在几台机器之间快速同步大型目录树，不需要其他功能。点对点工具不会在 Web 应用数据库中为每个文件保存一行记录，因此小文件带来的开销完全不同：Syncthing 与 Nextcloud 的纯同步对比。
• 您需要共享功能和 Web 界面，但数据由数百万个小文件组成。Seafile 将内容存储在块存储中，而不是为每个文件保存一个独立文件，因此资源开销的计算方式不同。代价是，数据不再以普通文件形式存放在磁盘上：Seafile 与 Nextcloud 的对比。
• 您只想通过浏览器查看服务器上已有的文件，不需要同步客户端，也不希望在这些文件前面增加每文件一条的数据库记录。这正是更轻量的自托管文件管理器适用的场景。
• 您真正需要的是供 4 个人使用的共享盘。先从更轻量的方案开始，之后再扩展：Nextcloud 的自托管替代方案。
• 您只有 1 个 vCPU 和 1 GB 内存，却想进行基于浏览器的办公文档编辑。这种配置无法满足需求，任何调优都无法改变这一点。

当您需要完整的协作套件时，运行 Nextcloud：与组织外人员共享文件，在每部手机上同步日历和联系人，在浏览器中编辑文档，并通过一次登录使用所有功能。问题通常不是突然发生，而是逐渐恶化。文件数量不断增加，实例仍未配置缓存和 cron，最终某天打开一个文件夹需要 8 秒。所有这些情况都可以度量，而且大多数都能在问题出现前修复。

FAQ

一台 Nextcloud VPS 可以承载多少用户？

这主要取决于使用方式，而不是用户数量。经过调优的 2 vCPU、4 GB 服务器，通常可稳定支持约 5 到 15 名进行文件、日历和联系人操作的普通用户。增加办公服务后，通常需要 8 GB。最先遇到的限制通常是 PHP worker 数量与可用 RAM，或是 oc_filecache 较大时的数据库性能。因此，在确定方案规格前，应使用自己的文件数量进行测试。

为什么文件数量很多时 Nextcloud 会变慢？

因为每个文件都是一行数据库记录，并对应一个独立的 WebDAV 请求。列出目录需要执行 SQL 查询；写入文件会更新该文件的记录，然后更新每个父目录的大小和 etag；传输文件时，每个文件都要单独发送一个 HTTP 请求，并且每次都要进行身份验证和框架初始化。因此，开销主要取决于文件数量，而不是总容量。更快的存储设备可以减少磁盘操作部分的耗时，但无法消除每个请求本身的开销。

Nextcloud 是否需要 Redis？

单用户使用时不需要。多用户使用时需要。没有 Redis 时，事务性文件锁会通过数据库表处理，这会增加写入负载；请求异常终止后还会留下过期锁，用户会看到文件已被锁定的错误。通常使用 APCu 作为本地缓存，使用 Redis 处理锁定，并在 config.php 中同时配置两者。

如果始终不配置 Nextcloud 的后台任务，会发生什么？

默认的 AJAX 模式会在每次页面加载时运行一个任务，因此没有用户登录时不会运行任何任务。预览图不会预先生成，文件版本和回收站内容也不会过期，磁盘占用会持续增长。通知邮件也会停止发送。管理员概览最终会报告上次后台任务已在数小时前运行，并提示可能存在问题。解决方法是改用每 5 分钟运行一次的 system cron；容器安装则通过专用的 cron 容器执行该任务。