一、问题
如下报告，60分钟dbtime时间居然是19647，数据库全面沦陷
等待top10
磁盘告警，磁盘写满了，除了硬件原因外，direct path read db file sequential read 难兄难弟。read by other session
执行sql也全面执行耗时
二、从整个表现来看，数据库压测有一个曲线图：
随着并发请求越来越多，数据库响应越来越慢，最后不堪重负，导致其他所有正常的请求都出现问题.由此我联想到，有一次物理机linux操作系统ssh 不响应，该台物理机上的虚拟机也部分不响应，其他虚拟机应用反应都很慢很卡，load是远远超过cpu核数。由此可以这样做一个假设:所有的软件，包括操作系统，数据库，中间件，都有一个负载最大值概念，超过这个，软件立马响应变慢，直到最后不响应
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/30393770/viewspace-2764055/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
数据库运维管理规范
请登录后发表评论
登录
全部评论
最新文章
- sysbench fileio 压测磁盘raid 5 raid 1 raid10 raid 50 情况
- oracle orion 压测磁盘性能raid10 raid5 raid50 数据
- tpcc-mysql 压测报告
- mysql benchmarksql 压测
- mysql ,tidb sysbench 测试结果记录
- pt-online-schema-change 错误集 Wide character
- mysql lock 大量会话锁住，快速定位，快速解锁
- tidb Error: Operation aborted by user answer '' (cliutil.operation_aborted)
- Oracle的OEM enterprise manager mail notificatio 邮件告警通知设置
- redis cluster 集群故障恢复操作思路
