@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

根据 wegame 的代理的几款 steam 游戏的套路，我猜是游戏本体免费+装饰收费或轻度游戏本体收费+装饰收费

老马也不傻，充值变得更强这种套路在自家手游上都没弄，pc 端不太可能会搞了

不过我最关心的还是腾讯是像完美那样支持 steam 参数登入，还是自己搞一套登录器+反作弊，多半是后者。

这样的话多半游戏本体要收费了

乖乖用银联或者 visa 不好么。。。

对操作延迟要求比较高的游戏还是别想了，比如动作、赛车、格斗之类的

另外 720P 30FPS 就算是局域网都用线连接，有的时候还是会莫名卡顿画面模糊，维持 1-3 秒不等

孤、儿、仔，匹配到 30 级的渣渣，从未排过位，不打野，擅长中单、 ADC