压测时「数据库指标」不会看,没关系

在进行压力测试时,关注数据库的CPU和内存使用率是关键,对于MySQL、Elasticsearch和Redis各有侧重。Redis还应关注缓存命中率。了解数据库类型和公司内部使用场景,以及监控这些核心指标,有助于确保系统的稳定性和性能。
    
          测试:我压测的时候,主要要关注哪些日志或者指标信息?
          开发:服务资源、数据库、es、redis 
          长期沉迷于业务逻辑测试的我,突然就蒙圈了,数据库、es、redis虽然日常有大概知道那是「what」,但是现在要进行压测的时候,具体要观察数据库的“what”,还真是一头雾水~
    于是我开始了一顿「知识恶补」和「耻下问」的道路,以下为个人工作过程实践总结,仅供分享学习~
NO1:了解数据库类型
数据库
类型
特点
Mysql
关系型数据库管理系统
作为数据的主数据库存储,存放持久化数据,读取速度慢
Elasticsearch
(简称ES)
非关系型数据库
是一个实时的搜索引擎,使用场景:大数据量下的检索,数据分析,日志分析,实时、高并发低延迟的场景应用较多
Redis
非关系型的数据库
读取速度快,但不支持事务,关系复杂的场景不适用redis,可以用来配合关系型数据库做缓存,以及一些持久化数据,适用于一些高并发读写
NO2:了解公司内部数据库使用场景
了解负责的系统在不同场景下使用的数据库类型。
  • 查询频率高且存在数据变动,主要存储在Elasticsearch(ES)内
  • 查询频率高但是数据基本不变,主要存储在redis内
  • mysql是主数据库
三者的数据关系如下:

 

NO3. 数据库核心关注指标
  • CPU、内存使用率、磁盘占用空间
    CPU、内存、磁盘这三项是能够看到的最直观的性能指标,也是数据库运行状态的整体体现。一旦数据库服务器这三项出现不正常的波动,必然会影响项目的稳定与性能。所以在进行性能压测时,首要关注的指标数据有这三个。
    在个人近期的性能专项实践中,由于性能相关知识不够深和广,所以提前跟开发「确认」压测过程中重点「关注」并「记录」数据库的CPU、内存使用率2个指标,其中Redis 除了关注CPU、内存使用率还需要关注并记录缓存命中率

图为阿里云提供的Redis的性能基础数据

压测时记录:

1. MySQL:CPU使用率、内存使用率

2. ES:CPU使用率、内存使用率

3. Redis:CPU使用率、内存使用率、缓存命中率

    将上面数据的截图记录下来,最后将多轮的压测数据量化,观察数据库的指标变化是否存在异常。

    数据库的性能指标还有很多,例如连接池的使用、慢请求、key监控等等,这个就后续慢慢学习进步~

努力的意义

当好运降临在自己身上时

你会觉得“我配”

而不是看着好事落在别人身上

然后愤愤地说“我呸”

<think>嗯,用户这次的问题是关于数据库性能试中监控CPU和内存资源消耗的方法。从用户提供的引用来看,用户已经接触过一些基础的系统监控命令(如top、free),但需要更专业的数据库性能监控方案。 用户可能是个中级运维工程师或DBA,正在搭建数据库监控体系。ta特意强调"性能试"场景,说明需要的是测时的动态监控,而非日常运维监控。深层需求可能是想建立性能基线或定位瓶颈。 上次对话中用户关注过FaunaDB的监控,这次虽然没提具体数据库类型,但引用中出现了MySQL案例,说明需要跨数据库的通用方案。用户跳过基础命令直接问方法论,可能已经掌握基础监控但缺乏系统化实践。 专业层面需要拆解三个维度:监控对象(OS/DB进程)、采集方式(工具链)、分析方法(关联指标)。重点要区分容器化/物理机环境差异,比如cAdvisor对容器就很重要。还要提醒用户注意监控粒度——性能试需要秒级采样,和日常监控分钟级不同。 安全方面要强调权限最小化原则,特别是生产环境采集时的sudo配置。用户没提云环境,但AWS CloudWatch这类工具也得覆盖,毕竟现在多数数据库上云。 准备推荐的方案要形成闭环:采集(工具链)→ 存储(时序数据库)→ 可视化(Grafana)→ 告警。特别强调Prometheus生态,这是当前主流方案。对于传统企业用户,补充Zabbix这种传统方案也很必要。 用户可能后续会问具体指标阈值设置,提前在"关键指标分析"部分埋下伏笔。示例命令特意展示pg_stat_database视图,引导用户关注数据库内部统计值,这比单纯看OS指标更有价值。 </think>在数据库性能试中,监控CPU和内存资源消耗需结合操作系统级工具与数据库内置指标,以下是系统化的方法: ### 一、操作系统级监控工具 1. **实时监控** - `top` / `htop`:动态查看CPU使用率、内存占用及进程详情 ```bash top -p $(pgrep -f "数据库进程名") # 过滤数据库进程 ``` - `vmstat`:监控系统进程、内存、分页、块IO和CPU活动 ```bash vmstat 2 10 # 每2秒采样1次,共10次 ``` 2. **历史数据分析** - `sar`(sysstat工具包): ```bash sar -u 1 5 # CPU使用率(1秒间隔,5次) sar -r 1 5 # 内存利用率 ``` ### 二、数据库内置监控 1. **MySQL** - 开启Performance Schema: ```sql SHOW ENGINE PERFORMANCE_SCHEMA STATUS; SELECT * FROM performance_schema.threads; ``` - 关键视图: ```sql SELECT * FROM sys.memory_global_total; -- 内存总量 ``` 2. **PostgreSQL** - `pg_stat_statements`扩展: ```sql CREATE EXTENSION pg_stat_statements; SELECT * FROM pg_stat_statements ORDER BY total_time DESC; ``` - 内置视图: ```sql SELECT * FROM pg_stat_database; -- 数据库级资源消耗 ``` ### 三、专业监控平台集成 | 工具 | 功能 | 数据库支持 | |---------------|----------------------------------|---------------------------| | **Prometheus** | 时序数据收集+告警 | 通过exporter(如mysqld_exporter)| | **Grafana** | 可视化仪表盘 | 兼容主流数据库监控数据源 | | **Percona Monitoring and Management** | 开源数据库专属监控 | MySQL/MongoDB/PostgreSQL | ### 四、关键指标分析 - **CPU瓶颈**:持续>80%使用率 + 高`%sys`(内核态占用)→ 需优化查询或扩容 - **内存瓶颈**: - `Swap`使用激增 → 物理内存不足 - 缓存命中率下降(如InnoDB Buffer Pool Hit Rate < 95%)→ 需调整缓存大小 ### 五、关联监控(示例) ```bash # 使用sysbench测时同步监控 sysbench oltp_read_write --threads=32 run & sar -u -r -P ALL 1 > resource.log # 记录所有CPU核心及内存 ``` > **最佳实践**:性能试中需同时采集操作系统指标(如`vmstat`输出)和数据库内部指标(如InnoDB状态),通过时间戳对齐分析资源消耗与SQL执行的因果关系[^1][^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Miss糖豆

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值