k8s 显示 mysql 占用了近 20 个 G 内存

[w3q29]

图上有几个离谱的 value 已经标出来了， 现在大概有几万条文件名的记录，需要随时取出来 修改某一字段的值。后期数据只增不少，请问该怎么优化

已经发现问题所在了，DJANGO 后端加了一个记录请求的插件，会把所有请求的 payload 和数据库响应时间等信息保存下来，恰好有一阵子上传了大量图片，所以数据库的内存就占的多了。最终把这个中间件删掉，把相关表删掉后解决问题，一下子只剩 1G 多一点了

[vibbow]

你标红的这几个都是 mysql 的默认值。

mysql 作为有状态应用，容器化没任何意义。

`select event_name,current_alloc from sys.memory_global_by_current_bytes limit 10;`
可以用这个语句查看内存用到哪里了

[wps353]

这些参数只是一些默认的最大值。并不表示你已经使用了这么多。

[2NUT]

@vibbow #1 那数据库 要独立于 微服务以外么？

还是有意义的，容器为了保存数据和状态不都用上文件系统挂载了么

[vibbow]

@2NUT 容器为了保存数据，都用上了文件挂载了，那不就失去了容器随意扩容迁移的属性了，和直接安装在本地没啥区别了。

[chendy]

@2NUT #3 最好还是独立的机器，数据库不需要滚动升级不需要动态阔缩，本身对资源的要求还高
用 k8s 部署的话，理想的画风可能是专门的节点每个节点上跑一个实例，其他什么都不跑，但是既然都这样了就不如直接部署到机器上了

[bthulu]

@chendy 这个就有点误导别人了. 数据库怎么就不需要动态扩容缩容了. 数据库除了 IO 操作, 还有很多 CPU 操作, 并不是所有应用场景都是 IO 先到达瓶颈的.

[w3q29]

感谢各位老哥的回复。
@vibbow：我看了一下最高的才占用才 13M ，我怀疑是不是短时间内有大量查询造成的缓存，而这个缓存会过期。
@2NUT ;@chendy :主要是考虑到放到 k8s 上资源、服务方便统一管理。现阶段同时开展好几个项目，都是分开的数据库，如果装在独立的机器上，数量可能会不够

[Aoang]

@bthulu #6 建议不要一本正经胡说八道

啥数据库能直接支持在 k8s 中动态扩缩？啥都是一张嘴就能实现的？

就算加只读节点，那也需要配置。数据库可没实现 raft 。

既然需要配置，那么这个自动扩缩的策略得多复杂？例如 Citus ，得配成啥样？就算配好了，一致性能保证吗？延迟能接受吗？性能顶得住吗？如果来个重分片，全挂还是…？

[Tinet]

@vibbow 有状态应用云原生化是现在的大趋势，很多中间件和数据库都在针对云原生化做存算分离的调整。
拿 mysql 来说，上到 k8s 之后，部署的一致性与便捷性对运维和开发人员来说都是好事。除开对运维人员的要求更高以外，也没什么其它弊端，当然没有必要为了上 k8s 而上 k8s ，上不上还是要根据自己的业务场景，能不能解决问题来权衡。

[documentzhangx66]

@vibbow

数据的安全性是分级的，比如一些跑日志的 mysql ，数据丢了就丢了，这种就可以用容器来方便管理。

[Cyshall]

@Aoang 老哥你这么冲干嘛？

[Tinet]

@documentzhangx66 谁告诉你放容器数据会丢的，现在都是通过 pvc 做数据持久化，在公有云上，一个 pv 其实就是一个云硬盘，性能跟虚拟机的硬盘是一样的，而且也几乎不存在丢的情况

[sky857412]

@Tinet 容器删掉，再启动一个新的容器，还有原来的数据？

[thomaspaine]

@sky857412 数据放 pv 里面了啊，类似用 iSCSI 协议挂了一块硬盘，容器删了，硬盘还在的

[maxbon]

不建议数据库这种跑容器或 K8S ，之前单位为了高可用和高度弹性想上 K8S ，研究了 1 年，发现不太合适，大容量的数据库还是单独会好点

[maxbon]

@sky857412 #13 挂持久化存储就行了，但是不太好使，性能和可靠性对于要求比较高的业务来说不太行

[adoal]

@bthulu 容器化语境的动态扩容缩容指的是无状态应用增加减少节点，是 scale out ，而 PaaS 语境里传统关系数据库的动态扩容缩容指的是占用硬件资源规格的升降，是 scale up ，两码事的。传统关系数据库并不天然具有 scale out 能力。

[vvhhaaattt]

容器化数据库之类的还是谨慎吧，容器生命周期是一个，网络磁盘等 io 是另外一个，容器化的好处对数据库意义不大，副作用可能是肉眼可见的。