@NSDont
NextCloud 毕竟基于 PHP，通过上传或同步客户端处理大量文件到数据库和自身程序里是很吃力的（除非专门进行调优），官方也是知道自己的情况，所以服务端提供了一系列 occ 的指令操作，其中有一个 files:scan 是专门处理文件扫描的，你可以去服务端手册看一下

```
sudo -u www-data php occ files:scan --help
Usage:
files:scan [-p|--path="..."] [-q|--quiet] [-v|vv|vvv --verbose] [--all]
[user_id1] ... [user_idN]
Arguments:
user_id will rescan all files of the given user(s)
Options:
--path limit rescan to the user/path given
--all will rescan all files of all known users
--quiet suppress any output
--verbose files and directories being processed are shown
additionally during scanning
--unscanned scan only previously unscanned files
```

用其他手段传输好后直接扫描添加到数据库和 NextCloud 中，效率会高很多，最好的是物理手段，移动硬盘之类的。另外针对大量小文件，我建议在本地打包后放到 NextCloud 对应的路径后进行解压，再使用 occ files:scan 扫描添加

多半是跑满了路由器缓存或者 CPU

我家的 surface book 以及其他的移动设备通过 WNDR4300 5GHz WiFi 接入，读写 NAS 的 smb 共享文件夹的时候大文件读写会时不时断流，要等个 30s 左右才能恢复继续，其他有线接入的设备没出现这种情况

后来换了 R8000 后就没出现这个问题了

@ddup 快 5 个月了，在调试中发现这是 Windows Docker 和 MySQL for Windows 之间的互访问题，我将数据库转移到 Docker 内部的 MariaDB 容器后，NextCloud 一切功能正常，效率还挺不错的

@ddup
感谢分享，万万没想到这个大佬直接 debug NextCloud 的源码优化效率，牛啊

虽然我现在转用了 Seafile，但我发现可能是因为我没对 MySQL 调优，MySQL 的 windows 版默认只给 INNODB 引擎分配 512M 的内存，估计 NextCloud 是数据库爆了内存无法响应请求，导致的连接超时

@ddup 我意思是文件搜索会生成检索缓存文件_(:з」∠)_

@ddup
在非 Linux 系统上跑 NextCloud 确实太累人，多半是 NTFS 文件系统读写上权限什么的各种奇奇怪怪的问题。

我后来在 windows 里跑 seafile-Pro docker，里面用到的 elasticsearch 服务的缓存存储做了外置持久化，log 里一直弹检索错误，导致 log 文件占完了 Hyper-V 分配的硬盘空间。

最后还是把缓存扔回内部的 volume 才正常

广东电信，一样，怕是得了肺炎

@EvineDeng 抱歉，太久没逛 v2ex。

按道理来说，可以照搬复制进 NextCloud 的配置文件里，因为这是 NextCloud 自带的文件权限检查，只是针对自身在 PHP 环境下对自己的文件是否符合权限预设值（ 0770 ）

比如 Linux 上主用户为 A，组为 root ； php 程序用户为 php，组为 php ； nextcloud 如果不是以 php （ php 组内用户）运行，又或者越权以 A （ root 组内用户）运行都会提示这个问题

另外 Docker 的 Nextcloud 在我的运行环境下有严重效能问题，无论是上传大文件还是大量小文件都会出现 Nginx 或 NextCloud 自身访问超时导致上传、下载（包括客户端同步）频繁失败。NC 的官方论坛有人说是因为 Windows 版的 Nginx 有问题，具体我也不太清楚，反正弃用了。

听大佬说因为 NextCloud 基于 PHP 效率很低，所以目前我已经改用 Seafile docker，满足使用需求并且也有同步客户端，自带配置好的 Nginx，docker 本身各种配置都做了持久化，方便 windows 本地修改。我这边环境只需要反向代理改一改就能用

暂时放弃了，等待有缘人解决了_(:з」∠)_

目前改用 seafile，文件数据处理效能比 nextcloud 高不少

@GSGUA 在 compose 中用 volume 将 windows 文件夹路径挂载到 container 里，记得 Docker 客户端需要将对应磁盘共享给 Docker Host

@oovveeaarr
docker logs 观察了好久，当网页和同步都卡住的时候，日志里也是没有任何反馈也没有 error

我自己感觉也是某个地方碰到瓶颈，然后资源没有被释放出来，但我就是不知道应该监控哪些地方

摆乌龙了，改大了 Hyper-V 的内存，情况依然如此，只是 4G 的时候 12 分钟就不行，8G 的时候大概 20 分钟左右不行

通过数次观察，每次容器启动后效率开始降低超时的时机都是容器启动工作 20 分钟左右

@seers 我用 docker stats 看，4G 内存占用即使在正常运行的情况下都不超过 40%，倒是 CPU 能跑满，甚至超了 100%，很神奇

我在容器内部用 top 看，正常工作时内存 free 只剩 200MB+，没怎么负载的时候是 1.4G free

Nextcloud web 网页里的设置-系统监控内存固定的 1.7G 不变，没什么用

对了，网页有点奇怪的现象，长时间不访问后再访问要等个 45s 左右才成功，第二次往后就异常地顺畅

@oovveeaarr 改 timeout 没用，容器运行持续一段时间后效率就会变成描述的那样，我问过朋友他也说从资源监控入手，但我除了会 docker stats 和容器内 top 之外，就不知道有什么办法了

物理硬件性能应该是没有瓶颈的，毕竟是软路由的 N 倍； MySQL、Nginx 都在物理系统上跑，同理

剩下的只有可能是虚拟机里的 Docker，但排查起来没有头绪无从下手，Hyper-V 虚拟机本身、Docker for windows 自身、Nextcloud 容器内还有内置的 PHP 和 Apache

@locoz 慢还是小事，问题是超时失败

@ddup 我这 x86 的性能倒是不用考虑什么限制，但倒是不知道问题究竟出在哪里

Nextcloud 的容器启动初期同步效率一点问题都没有，但在运行一段时间后就各种超时 504 gateway timeout，Web 访问也是跟着卡

除了 windows 客户端同步之外就一点问题都没有

我个人是实在不知道为什么 Nextcloud Windows 客户端远程同步文件夹效率超级低下，甚至各种 Gateway time-out

除了 Nextcloud 的数据保留外，将其余所有文件转移到 SSD 后，将 Docker for windows 的 CPU 数拉到 4，内存拉到 4G 后，2G 的大量小文件总算能正常同步了

docker stats 里内存占用仅有 25%左右，但进到 Nextcloud 容器内 top 看到空闲内存仅剩 200MB，不太懂

upstream timed out (10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond) while reading response header from upstream

运行过程中 nginx 的 log 总是有上述 error，因为在外部网络通过域名访问 Nginx 监听反向代理使用 localhost 作为 host name 时所有网络请求都会走一遍本地 DNS 解析或走 hosts，而 Win10 和 Server 2019 默认开启 IPv6 地址，解析的时候总是会尝试一遍 IPv6 访问，也就是[::1]

解决方法是将 Proxy_pass 直接改成 127.0.0.1

根据相关解释，在 hosts 里加入 127.0.0.1 localhost 应该也是可行的