记录一下搞nextcloud的辛酸事吧
前段时间,利用centos7 + nginx + php8 + mysql8 部署了一个nextcloud,首选的是当时最新稳定版的NC22,根据官方文档一步步操作下来,遇到了很多问题
部署完成后,NC首次登录不上的、登录上去,无限循环 /remote.php/dav的,还有一个样式混乱的(重启web服务就好了,也不知道为什么)。
后面换了NC21版本,就没这些问题了。。。。。
部署完成之后,开始改代码,支持单点登录。不得不说,nextcloud的代码真不错,耦合性不强。
登录验证是通过 OC\Authentication\Login\Chain 构建的链条一步步验证下去的
(真不错,这代码,单点登录的验证也就是加在这链条上)
改完单点登录,又发现了新的问题。上传速度慢,最终的解决方法是,把PHP,nginx上传的参数配置调大,同时,不限制nextcloud文件分块大小。
后面通过挂载,扫描添加了几百上千万的文件,这时候,又出现了一个问题。。。
就是mysql的CPU占用很高(一直)。说说我处理的过程:
一开始,我以为是sql语句执行慢,导致的,跑去看了慢日志,结果没什么发现,后面又将fpm的日志,nginx的错误日志都看了,一样没什么发现。
通过SHOW FULL PROCESSLIST看到有几个线程执行一样的SQL语句,执行时间很长,一直都是executing的状态。但不知道是在哪触发的。
索性,我把nginx关闭,php-fpm关闭,但是MySQL的cpu负载还是下不来。这时候,可以想到应该是定时任务触发的SQL语句了。
后面通过nextcloud社区了解到,很多人都出现这个问题和文件扫描的定时任务每隔12个小时就会执行一次。在SHOW FULL PROCESSLIST中的Time可以验证这一点,说明是从文件扫描的定时任务触发的SQL查询。
想要解决这个问题,可以直接关闭文件扫描的后台任务,如果是通过web上传的文件,一般不会触发文件扫描的,我是通过挂载,而且挂载文件很多,文件和文件夹的大小都没有进行统计,才会触发的。
这里放一下SQL语句 (顺便提一下:oc_filecache的数据量在1300w左右,oc_mounts的数据量在500左右)
SELECT MAX(`user_id`) FROM `oc_filecache` `f` INNER JOIN `oc_mounts` `m` ON `storage_id` = `storage` WHERE `size` < 0 GROUP BY `storage_id` LIMIT 500; SELECT `path` FROM `oc_filecache` WHERE (`storage` = 18 ) AND (`size` < 0 ) ORDER BY `fileid` DESC LIMIT 1;
一共发现两条SQL语句会出现这样的问题。通过分析,发现 这两条语句执行时索引都没有用对(stroage,size 和 size都是有索引的)。这两条SQL语句可以执行很久很久。。。。。
一开始我还以为是产生了死锁,但是不是,其实就是一直在执行,没有尽头。
我还用strace -p 分析了php定时任务的进程,就一直在restart_syscall,应该是在等待SQL返回数据。
后面看了oc_filecache的数据发现,size < 0的情况就只有 size = -1 (等于查询肯定比范围查询要好啊),所以最后就把size < 0 改成了size = -1了。虽然sql查询还有有点慢,但至少能结束,返回数据,总比之前没有返回的执行好。
但是如果,size < 0 的情况有很多种,那就不适用了。。。。
按照上面的处理后,MySQL的负载就下来了,也没有定时任务一直在等待返回了。
如果有人知道关于nextcloud的其它问题和解决办法,请告诉我,不胜感激(因为后面还要对它进行二开)
算是告一段落吧。。。