写点什么

生产环境全链路压测建设历程 26:FAQ 之 压测结束阶段的相关问题

发布于: 2021 年 01 月 10 日

数据清理采用的手段?全链路各个环节的数据通过后台清理还是业务触发删除?影响和表现哪种更好?

1.只要有影子表、影子库的用户名、密码,就可以编写对应的 shell 脚本来进行相关操作。

  1. 一般是通过脚本来后台删除是最好的,脚本经过编写、测试、review。

  2. 业务触发删除不太推荐使用。 占用业务服务器的运行资源,效率也低。

如 Cassandra 等 nosql 数据库的数据清理如何解决墓碑问题?

Java 的系统,基本上都是通过 JDBC 的协议来访问 Cassandra 等 NoSQL 的数据库,JDBC 的协议,探针都支持流量隔离写入到影子区域。

所以本身压测数据的影子表和真实数据是隔离开的。

不需要用 delete(upsert)的形式去删除压测数据,而是直接 drop table,然后重建。

表空间及数据文件大小,以及对索引的影响,需要重建吗?


本身压测数据的影子表和真实数据是隔离开的。基本不需要做这块事情了。 但如果是 MySQL,建议在清理数据的时候,尽管是使用 truncate 或者 drop table,也要 sleep 2-3 秒左右,不要对 innodb buffer 有太大的冲击。 Oracle、Linux OS 和其他存储也是同理。

执行和清理阶段,遇到的准备阶段未考虑到的问题?

1.在生产压测期间,一般会关闭数据库的自动切换配置。避免因为流量对数据库的压力太大,或者是自动切换的阈值过低,或者是网络容量等等瓶颈点,触发了数据库的主备自动切换。

2.数据库如 MySQL 的一些临时预案的提前执行, 如 syncbinlog, innodbflushlogat_trx_commit 从双 1 改成双 0(刷盘变成刷内存)等

3.一般会是先做好单链路、入口的生产压测,确保服务本身的 SLA,然后再来做全链路的压测验证。(D 快递、S 快递都是这样玩了,各个业务线自己先玩好,然后每个月底组织一波全链路压测验收,根据压测结果进行对应的优化)。


发布于: 2021 年 01 月 10 日阅读数: 45
用户头像

还未添加个人签名 2017.12.21 加入

还未添加个人简介

评论

发布
暂无评论
生产环境全链路压测建设历程 26:FAQ之 压测结束阶段的相关问题