ab 简单使用 并发100, 请求数为1000次.
ab -c 100 -n 1000 http://localhost/test.html ab post json使用 -p 数据 -T 请求内容格式, 如json: application/json ab -c 100 -n 1000 -p data.json -T application/json http://localhost/1.html data.json
{"username":"sgfoot.com"} 解读报告 ab压力测试报错 Benchmarking 192.168.1.10 (be patient)
apr_socket_recv: Connection reset by peer (104) 以上错误, 说明192.168.1.10机器重设连接. 因为apr_socket_recv是操作系统内核的一个参数, 如果系统感应到大量的请求时,会降慢速度,对连接进行重置. 这是一种面对SYN flood攻击保护. 但是我们压测时需要关闭这个保护.
关闭保护
# vim /etc/sysctl.conf net.ipv4.tcp_syncookies = 0
# sysctl -p1. 文件类 1.1. 查看文件大小 # 加 h 查看可读性的文件大小 ll -h # 查看文件夹大小 # --max-depth=1 表示查看文件夹的一层 du -h --max-depth=1 /usr 1.2. 压缩 ZIP
-r 递归处理，将指定目录下的所有文件和子目录一并处理。 -y 直接保存符号连接，而非该连接所指向的文件，本参数仅在UNIX之类的系统下有效。 -v 显示指令执行过程或显示版本信息。 -j 只保存文件名称及其内容，而不存放任何目录名称。 -b 添加注释 -u 更新文件 # 压缩 # target.zip 是压缩后的文件名 # source-dir 要压缩的文件夹名 zip -r target.zip source-dir # 压缩保留软链, 只对类 unix 系统有效 # -y 保留软链 zip -ry target.zip source-dir # 压缩带注释 zip -ryb target.zip source-dir # 解压 unzip target.zip # 查看压缩文件, 不压缩 unzip -v target.分析过程 使用 pprof top分析 可见 json.Marshal占第一内存. 为什么呢? 我们进一步分析
使用 tree 分析 查看到 zerolog AppendInterface 方法占用 73.32%的内存量. 而 zerolog 是一个很优秀的日志库, 比 zap 还优秀. 为什么呢?我们需要查看源码
822.70MB 73.32% | github.com/rs/zerolog/internal/json.Encoder.AppendInterface 分析源码 找到 github.com/rs/zerolog/internal/json.Encoder.AppendInterface` 366 行
// AppendInterface marshals the input interface to a string and
// appends the encoded string to the input byte slice.
func (e Encoder) AppendInterface(dst []byte, i interface{}) []byte {
marshaled, err := json.Marshal(i)
if err != nil {
return e.查看 Clients 属性 127.0.0.1:6379>info clients # Clients
connected_clients:1 # 已连接客户端的数量（不包括通过从属服务器连接的客户端）
client_recent_max_input_buffer:2 # 当前连接的客户端当中，最长的输出列表
client_recent_max_output_buffer:0 # 当前连接的客户端当中，最大输入缓存
blocked_clients:0 # 正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客户端的数量 查看 Memeory 属性 127.0.0.1:6379>info memory used_memory_human:1.92G # 用户数据所占用的内存，就是你缓存的数据的大小。
used_memory_rss_human:30.73M # 常驻内存, 与top占用内存一致
used_memory_peak_human:1.93G # 内存使用峰值
total_system_memory_human:1.78G # 整个系统的内存
mem_fragmentation_ratio:0.02 # 内存碎片比率. used_memory_rss/used_memory求的值. 如果小于1时,需要优化内存碎片. mem_fragmentation_ratio 查看内存碎片比率,
小于<1时,Redis实例可能会把部分数据交换到硬盘上，内存交换会严重影响Redis的性能，所以应该增加可用物理内存 大于>1时, 说明碎片占用 更多的内存, 需要整理, 在1~1.5 之间比较健康. 重启Redis服务；也能达到碎片整理目的
查看是否开启自动碎片整理: config get activedefrag
设置自动碎片整理: config set activedefrag yes
直接手动整理碎片: memory purge
redis.conf配置设置自动整理碎片
redis 4.0
# Enabled active defragmentation
# 碎片整理总开关
# activedefrag yes
# Minimum amount of fragmentation waste to start active defrag
# 当碎片达到 100mb 时，开启内存碎片整理
active-defrag-ignore-bytes 100mb
# Minimum percentage of fragmentation to start active defrag
# 当碎片超过 10% 时，开启内存碎片整理
active-defrag-threshold-lower 10
# Maximum percentage of fragmentation at which we use maximum effort
# #内存碎片超过 100%，则尽最大努力整理
active-defrag-threshold-upper 100
# Minimal effort for defrag in CPU percentage
# 内存自动整理占用资源最小百分比
active-defrag-cycle-min 25
# Maximal effort for defrag in CPU percentage
# 内存自动整理占用资源最大百分比
active-defrag-cycle-max 75 查看 Stats 属性 只列出部分属性.参考 Go 单元测试/性能测试
性能测试 go test -test.bench=. -test.benchmem 指定方法 go test -test.bench=MyFunc -test.benchmem cpu 性能分析 go test -test.bench=MyFunc -test.cpuprofile cpu.out 内存分析 go test -test.bench=MyFunc -test.memprofile mem.out goroutine 阻塞分析 go test -test.bench=MyFunc -test.blockprofile block.out ### 指定几个cpu分析
go test -test.bench=MyFunc -test.benchmem -test.cpu 1,2,4解析方案 // 替换 ioutil.ReadAll
func ReadAll(data io.ReadCloser) (body []byte) {
buffer := bytes.NewBuffer(make([]byte, 0, 65536))
io.Copy(buffer, data)
temp := buffer.Bytes()
length := len(temp)
if cap(temp) > (length + length/10) {
body = make([]byte, length)
copy(body, temp)
} else {
body = temp
}
return
} 参考 [golang]内存不断增长bytes.makeSlice
Golang Slices And The Case Of The Missing Memorytop 是 linux 最常用的命令, 包括很多少直观的信息, 有利于我们对系统运行状态的把握.
top 使用 top 系统自带命令,可以直接使用.
top top 详情 a. 如图编号(1)
top - 10:34:07 up 16 min, 1 user, load average: 0.00, 0.01, 0.05 10:34:07 当前时间 up 16 min 系统运行时间, 如 16 分钟 1 user 当前登陆用户数 load average: 0.00, 0.01, 0.05 系统负载. 三个数值分别为 1分钟、5分钟、15分钟前到现在的平均值。 b. 如图编号(2)
Tasks: 206 total, 1 running, 205 sleeping, 0 stopped, 0 zombie Tasks: 206 total 进程总数 1 running 正在运行的进程数 205 sleeping 睡眠进程数 0 stopped 停止进程数 0 zombie 僵尸进程数 c.1. MySQL 并发参数调整 1.1. max_connections 参数 该参数设置mysql连接最大数量. max_connections 默认151个连接.
show variables like 'max_connections' 服务器性能优时可以调节这个参数, 范围: 500~1000
注 当连接过大时, 查看 Connection_errors_max_connections 参数是否大于0 , 表示连接过多, 错误连接
show status like 'Connection_errors_max_connections'; 2. back_log 参数 积压栈的大小.
也就是说当 mysql 连接超过 max_connections 连接数时, 如果back_log大小为0时, mysql将授予连接资源. 如果back_log大于零时,则接受多余的请求, 以等待某一连接释放.而等待的连接数大于back_log数时则也将不授予连接资源.
back_log默认大小: 50 + (max_connections/5), 最大可设置为900
show variables like 'back_log' 3. table_open_cache 该参数用来控制所有SQL语句执行线程可打开表缓存的数量.
最大数量设定: max_connections * N
show variables like 'table_open_cache' 4. thread_cache_size 该参数可控制 mysql缓存客户服务线程的数量, 相当于mysql的线程池, 也备重用.
show variables like 'thread_cache_size' 5.