@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 应该也是可行的

@wq2016 我看了日志和 I/O 数据，感觉瓶颈是在 MySQL 那，我也翻到了一些用树莓派做 Nextcloud，他们大多都加大了 innodb cache 相关的参数。事实上我犯了个很弱智的错误，我初步搭建测试的时候 MySQL 的数据库放在了 5400 转的 HDD 里，过会我把数据库丢到 SSD 里再看看运行效率

#默认 128M
innodb_buffer_pool_size = 512M
#默认 1
innodb_buffer_pool_instance = 1
#默认 2
innodb_flush_log_at_trx_commit = 2
#默认 16M
innodb_log_buffer_size = 32M
#默认 90
innodb_max_dirty_pages_pct = 90

@wq2016 我这个问题出在大量的小文件同步，大概是 1 万 5 千多个 word、excel，用 windows 端的客户端同步的时候“检查远程变更”的效率很慢，不知道应该优化哪里才好

在实际使用过程中发现 Nextcloud 和 MySQL 对接的效率有点低，上网查了一下参数调优，胡乱一气都给调大了，想着 E3 1230 v3+32G ECC RAM 跑个 Nextcloud 效率应该不会太低吧

```
#
# 性能优化
#
# 允许最大连接数
max_connections = 500
# 响应的连接数,一般为最大连接数的 85%
max_used_connections= 425
# 索引块（ index blocks ）缓存的大小
key_buffer_size = 128M
# 允许服务器接受的数据包大小
max_allowed_packet = 32M
# 块数据插入缓存大小
bulk_insert_buffer_size = 32M
# 线程分配内存大小
thread_stack = 256K
# 线程缓存数量
thread_cache_size = 16
# 打开表格数量缓存
table_open_cache = 1024
```

大佬们如果有更好的优化参数请告诉我，秋梨膏

自查漏打一个细节问题，windows 系统下的 MySQL 8 默认密码认证插件为 caching_sha2_password，在上面所给的 MySQL for win64 + Nextcloud Container 环境下，给 Nextcloud 创建数据库用户的时候要留意主机名为 host.docker.internal，密码认证插件改为 mysql_native_password