排查: ● 出现问题后也不知原因,于是开启了 ossfs 的 debug 日志进行分析加上 -d -o f2 参数,ossfs 会把日志写入到系统 /var/log/message 。 ● 日志发现是 ossfs 在 listbucket listobject 申请内存过多,导致触发了系统的 oom 将进行 killer ,找到了元凶。 ● listobject 是要发起 http 请求到 oss 获取一个 meta 信息,如果客户的文件很 多,ls 会消耗系统的大量内存来获取文件的 meta,这是正常情况。 解决方案: ● 通过 -omax_stat_cache_size=xxx 参数增大 stat cache 的 size,这样 第一次 ls 会较慢,但是后续的 ls 就快了,因为文件的元数据都在本地 cache 中。默认这个值是 1000,大约消耗 4MB 内存,请根据您机器内存大小调整 为合适的值。 ● 使用 ls -f 命令,这个命令会消除与 OSS 的 n 次 http 请求。 ● ossfs 在读写时会占用磁盘写大量的 temp cache ,和 nginx 差不多,可能会 导致磁盘空间不满,最好能常清理一下。 ● 使用 osstuil 替代 ossfs ,非线上敏感业务可以用 ossfs ,要求可靠性、稳定 性的还是用 ossutil。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。