跳至主要內容

生产实践（一）

添码座原创大约 5 分钟数据库MySQL数据库MySQL

机器配置

对Java系统而言，耗时最多的基本上都是网络请求，同时等待执行返回的结果。

对大部分业务系统来说，其负载和压力主要都集中在数据库访问上，因为访问数据库需要执行大量的磁盘I/O操作。

  • 一般Java应用配置4C8G，每秒200~800之间的并发访问量。

  • 一般MySQL最低配置8C16G（标配16C32G），SSD固态硬盘。

问题

  • 假设Java系统部署在4C8G机器上，假设每个请求的处理时间只有0.01ms，那这台机器可以实现每秒几千的并发请求吗？

  • 可以扛住每秒几万的并发请求吗？


性能测试

MySQL生产环境中的一些高级参数的调优和配置，也是跟Java应用密切相关的。

专业的DBA会依据过往的经验，用MySQL生产调优模板去启动数据，通过压测工具模拟系统请求。

  • 每秒发出若干个请求到数据库，观察CPU、I/O、网络及内存的负载情况。

  • 逐步提升请求数量，看看数据库的性能表现。

  • 数据库压测和Java业务系统压测不是一回事。

  • 如果先知道数据库能扛多少压力，再来开发Java业务系统就会心里有数。


常用测试指标

  • 数据库相关指标。

    • QPS：Query Per Second，每秒查询请求数。

    • TPS：Transaction Per Second，每秒事务处理数。

  • I/O相关指标。

    • IOPS：机器的随机I/O并发处理能力（后台I/O刷盘能力）。

    • 吞吐量：机器的磁盘每秒可以（顺序）读写多少字节数据。

    • Latency：往机器的磁盘里写入一条数据的延迟。

  • 其他指标。

    • CPU负载、内存负载、网络负载

问题

  • QPS和TPS是一回事吗？

  • 假设一个交易系统拆分为很多服务，一笔交易的完成需要多个服务协作完成，那对于每个服务而言，处理的请求数量是QPS还是TPS？

  • 对于整个交易系统而言，处理的请求数量是QPS还是TPS？


测试工具

在Linux上安装SysBench。

> curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash
> sudo yum -y install sysbench
> sysbench --version

创建测试库，基于SysBench构造测试表和测试数据。

> sysbench --db-driver=mysql \
    --time=300 --threads=10 --report-interval=1 \
    --mysql-host=127.0.0.1 --mysql-port=3306 \
    --mysql-user=test_user --mysql-password=test_user \
    --mysql-db=test_db --tables=20 --table_size=1000000 \
    oltp_read_write --db-ps-mode=disable prepare/run/cleanup

压测结果说明如下。

  • thds: 10，表示有10个线程在压测。
  • tps: 380.99，表示每秒执行了380.99个事务。
  • qps: 7610.20(r/w/o: 5132.99/1155.86/1321.35)，表示每秒可执行7610.20个请求，其中，有5132.99个读请求，1155.86个写请求，1321.35个其他请求。
  • lat (ms, 95%): 21.33，表示95%的请求的延迟都在21.33毫秒以下。
  • err/s: 0.00 reconn/s: 0.00，表示每秒有0个请求是失败的，发生了0次网络重连。
  • SQL statistics:
    • queries performed:
      • read: 1480084 // 在300s的压测期间执行了148万多次的读请求
      • write: 298457 // 在压测期间执行了29万多次的写请求
      • other: 325436 // 在压测期间执行了30万多次的其他请求
      • total: 2103977 // 一共执行了210万多次的请求
    • transactions: 105180( 350.6 per sec. ) // 一共执行了10万多个事务，每秒执行350多个事务
    • queries: 2103977 ( 7013.26 per sec. ) // 一共执行了210万多次的请求，每秒执行7000+请求
    • ignored errors: 0 (0.00 per sec.)
    • reconnects: 0 (0.00 per sec.)
  • General staticstics: // 一共执行了300s的压测，执行了10万+的事务
    • total time: 300.0052s
    • total number of events: 105180
  • Latency (ms):
    • min: 4.32 // 请求中延迟最小的是4.32ms
    • avg: 13.42 // 所有请求平均延迟是13.42ms
    • max: 45.56 // 延迟最大的请求是45.56ms
    • 95th percentile: 21.33 // 95%的请求延迟都在21.33ms以内

性能观测

通过SysBench实验，如果得到以下结果。

  • A：QPS = 2000，CPU、内存、I/O、网络在正常范围内。

  • B：QPS = 5000，CPU100%、内存100%、I/O、网络都很高。

那么这说明条件B很可能会宕机，而条件A则可能是负载峰值。

通过top指令观察CPU负载。

  • load average: 0.15, 0.05, 0.01

  • 说明CPU在1分钟、5分钟、15分钟内的负载情况，具体数值与CPU核数有关。

  • 若4C8G机器负载值=1.5，说明1核使用率100%，另1核50%，另2核是空闲的。

  • 若负载值=6，说明当前4核使用率已经全部100%，且更多的任务正在排队中。

通过top指令观察内存负载。

  • Mem: 33554432k total, 20971520k used, 12268339 free, 307200k buffers

  • 说明总内存大概32G，已经使用20G，12G空闲，大概有300M内存作为OS缓冲。

观察磁盘I/O负载的命令。

  • dstat -d

  • dstat -r

观察网络负载的命令。

  • dstat -n

  • netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'


部署监控



感谢支持

更多内容，请移步《超级个体》。