V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  wyxls  ›  全部回复第 8 页 / 共 9 页
回复总数  167
1  2  3  4  5  6  7  8  9  
@ddup 我意思是文件搜索会生成检索缓存文件_(:з」∠)_
@ddup
在非 Linux 系统上跑 NextCloud 确实太累人,多半是 NTFS 文件系统读写上权限什么的各种奇奇怪怪的问题。

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

最后还是把缓存扔回内部的 volume 才正常
2020 年 1 月 31 日
回复了 shom 创建的主题 Steam steam 平台这会儿挂了?
广东电信,一样,怕是得了肺炎
@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
2017 年 12 月 18 日
回复了 gclove 创建的主题 PUBG 腾讯代理了 PUBG 的话, 游戏是不要钱的吧 ?
根据 wegame 的代理的几款 steam 游戏的套路,我猜是游戏本体免费+装饰收费或轻度游戏本体收费+装饰收费

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

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

这样的话多半游戏本体要收费了
1  2  3  4  5  6  7  8  9  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   2421 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 20ms · UTC 10:58 · PVG 18:58 · LAX 03:58 · JFK 06:58
♥ Do have faith in what you're doing.