Calibre-web 个人图书库搭建记 16:腾讯云cos对象存储挂载硬盘后 的读请求异常问题

Calibre-web图书库,使用了腾讯云的cos对象存储当作图书文件目录,这样可以无限扩容服务器空间,还可以在下载的时候使用对象存储的外网提供高速下载。

最近遇到几个对象存储当磁盘文件使用的问题总结一下。挂载对象存储在频繁操作calibre的数据库文件时读写性能跟不上,解决方式是单独改变了calibre数据库的位置,放在系统磁盘保证读写可以跟上,然后代码中修改calibre-web的数据读取位置。

之后发现下载速度跟上了,但通过1M带宽的主机发送附件的邮件出口带宽一样太慢,这样会有一些功能受到限制,在calibre-web上最明显的是发送到Kinlde功能体验不好,每次送要等待太长时间。

经过两个多月的测试和数据观察又发现了一个烧钱的动作,cos对象存储每天半夜2-4点的读请求会异常高,每天都会产生10万次左右的读请求,一个月要产生300多万次的读请求,腾讯云cos的每月读请求是免费100万次,剩余部分要自己付费。自己排查了很多个方面都没找到原因,怀疑网站备份频繁读取文件、搜索引擎爬虫大量抓取导致文件读取频繁,但发现主机上在这个时间点并没有备份任务,也没有太多的蜘蛛爬取。

每天3-4点腾讯云对象存储cos的读请求都异常高。0

0

排查发现大部分是文件HEAD类型的请求,基本可以确认并不是文件打包这些操作进行的对象存储文件读取。

0

排查发现3-4点的访问请求几乎可以忽略不计,不可能产生如此多的云存储cos的读请求。

0

觉得这个问题自己可能不好查找原因了,给腾讯云提交一个工单,具体确认一下问题到底出在哪个方面?

腾讯云提交了工单以后开始研发也没找到原因,只是问问具体的问题和困惑,自己也在想到底会是什么动作触发了这么多的对象存储的读请求。又怀疑是因为cosfs工具的自动缓存定时抓取一部分cos上文件到本地磁盘。来减轻实时读取接口的压力?但没找到这么做的原因和代码触发方式。另一个困惑,为什么cos挂载的本地缓存动目录几天就会缓存50%的存在对象存储中的内容,这样的话本地缓存要配备1:1的存储空间来缓存cos的实际使用数据?

毕竟这是一个还没有什么访问量的网站,如果需要跟对象存储cos使用空间配比1:1 的磁盘进行本地缓存,那还不如直接用云硬盘来的直接,下载加速功能做个cos的镜像回源就可以完成了。

前段时间因为本地50G的系统硬盘缓存cos文件内容都要满了,还单独采购了一块50G的云硬盘挂载到calibre-web书库服务器用来缓解系统磁盘空间紧张的问题。或许找到这个读请求频繁的原因,缓存数据的硬盘就是实际使用才缓存了。

考虑了很多,突然想到是不是有什么定时扫描的程序会遍历这个服务器的目录,导致需要频繁的请求对象存储cos数据,考虑了几种可能,计划任务(备份、目录扫描、网站安全检查)、病毒软件。最后看计划任务也找不到任何执行定时扫描cos挂载的目录的代码。

0

不知道什么原因,就想起来会不会是安全软件的扫描,一般云服务器都会装一个云厂商的云安全组件。腾讯云的安全服务是云镜(主机安全),云镜介绍里有条表示会扫描文件检查webshell木马。也许就是这安全软件扫描的问题,在夜深人静的时候默默的扫描文件并进行木马检查。

0

https://cloud.tencent.com/product/hs#userDefined9

但这个云镜除了有个介绍,提供疑似的安全威胁可以处理外,没有任何的设置选项,完全不能进行个性化定制,具体的扫描规则、扫描范围、扫描时间都不清楚。继续通过腾讯云的工单咨询,经过半天的排查腾讯云确认对象存储读请求突增的时间点(凌晨3:00-4:00)与云镜(主机安全)的文件扫描高峰时间点一致。

工单咨询腾讯云的技术,云镜不能设置忽略目录,所以我们只能是承担这个扫描费用?要么是卸载云镜?
安全和消费钱之间我们要选择那个呢?

0

0

最后问题找到了,是腾讯对象存储cos fs工具挂载到云主机后被云镜服务频繁扫描导致文件 Head读请求异常的坑。

解决方案应该是卸载云镜?

还是让这个云镜木马扫描服务继续消耗费钱呢?

—更新—
可是在卸载了云镜以后还是没有减少COS的读取请求。经过不断的追踪和审计文件读取情况,在不断的测试和腾讯云的技术沟通中发现了问题是linux updatedb 程序每天定时扫描磁盘上的改动文件导致的文件读取数过多。
问题找到了,可是在沟通中发现了跟腾讯云技术沟通真的好心累,沟通来沟通去都不能解决问题,而且排查思路都看着让人着急。让他们协助检测凌晨3-4点钟的读取异常。一次一次的拿着9点钟的设计日志给我说是因为Python读取导致的。然后让我要么取消挂载cos文件夹,要么关闭python 程序。任何一个方案都不能解决问题,也找不到问题点上去。
最后没办法自己一点点扣那个时间点的日志才怀疑是 updatedb 程序的问题。然后顺带着就根据搜索找到了解决方案。查找了一下资料,怀疑是linux locate 和 updatedb 程序需要每天定时扫描更新的磁盘文件,而cosfs 的挂载目录不在禁止扫描的目录,造成了每晚都会对cosfs 挂载的 /home/calibrelib文件夹进行扫描,目录扫描是linux 系统自己扫描机制造成的。
避免updatedb扫描文件。可以在/etc/updatedb.conf 增加禁止扫描目录,也可以把cosfs 的挂载目录放到预制的禁止扫描的目录里(比如常见的 mnt 目录)。
总之在相互的学习中找到了问题的解决方法,但其中对于沟通中不顺畅和技术支持对于客户关注问题和在实际业务场景中解决问题的能力让人怀疑。不上心,不思考客户真正的业务诉求也是这种工单技术支持最主要的问题。
在与国内的cdn厂商,云服务厂商沟通中都发现了这不彻底理解业务关键问题点而去用力或者敷衍答非所问的解释。如同是劫持问题的排查就会出现很多种中间环节,而每一个环节都想着把责任推给其他不可控的环节,而不是在自己能实现的范围里推动问题解决。当然在自己客户服务中我们的团队也是存在这种问题,对于自己不相关的问题点不去思考或者解决,直到客户爆发了才真正去研究和解决问题。有时候是技术支持人员能力的问题,但有些也许就是心态和对事情是否有真正解决决心的问题。
通过一次一次客服服务的对比,感觉国外厂商对于客户支持的解决上的支持力度还是很专业的,对于任何客户的疑问和问题都会亲自尝试并给出代表产品的解决方案,我们在做服务的时候是代表一个公司的专业能力的。有些问题的解决需要综合各个内部外部部门和一些外扩的知识体系才能解决,如果客户支持不能解决这种问题,有时候真的会被客户认为整个公司和产品的不专业。自己公司的管理和服务上也是经常出现这种问题,一个人只代表自己的工作范围,或者只代表一个部门去处理客户问题,而让客户自己去协调一些公司内部需要解决问题,这个时候真的会被人认为不专业的服务。一次次的不专业服务会对整个公司或产品的商誉产生很大的伤害,甚至被客户放弃

如果有些行业难题因为一个客户诉求和配合得到解决,有时候就会形成一个产品独有的竞争力。如同最近遇到的cdn加速在https和http回源上使用一份内容的问题导致的工单问题,也是没有解决,让我对腾讯云的服务能力也产生了一些质疑,这次cos问题的排查又产生了一次伤害。
前段时间用0ffice365和亚马逊的服务让我对合理利用客户服务产生了新的理解,但如果遇到舒服的客户服务又让我对这些服务感到悲观。有时候这种服务水平倒逼这我们去适应他们的产品,去适应他们的流程,成为比他们自己还要专业的专家。这只是因为我们没有选择,如果出现真正的好的服务,也许我们就会放弃这种糟糕的体验服务。现在也终于了解 微软云服务的技术支持服务需要收费了,好的服务也许是需要收费的,成本高。

发表评论

电子邮件地址不会被公开。 必填项已用*标注