CPU sys值很高
背景描述
使用10个线程,50个并发压测的时候,通过监控发现cpu的sys值很高,导致qps上不去。
监控结果
top命令结果
top - 21:08:25 up 7 days, 4:28, 1 user, load average: 23.72, 20.95, 17.89
Tasks: 319 total, 1 running, 318 sleeping, 0 stopped, 0 zombie
%Cpu0 : 35.6 us, 27.3 sy, 0.0 ni, 31.8 id, 0.7 wa, 0.0 hi, 4.5 si, 0.0 st
%Cpu1 : 26.3 us, 22.5 sy, 0.0 ni, 46.3 id, 0.4 wa, 0.0 hi, 4.6 si, 0.0 st
%Cpu2 : 35.8 us, 28.4 sy, 0.0 ni, 31.6 id, 0.4 wa, 0.0 hi, 3.9 si, 0.0 st
%Cpu3 : 27.8 us, 19.8 sy, 0.0 ni, 45.4 id, 0.0 wa, 0.0 hi, 7.0 si, 0.0 st
%Cpu4 : 36.6 us, 27.2 sy, 0.0 ni, 31.9 id, 0.4 wa, 0.0 hi, 3.9 si, 0.0 st
%Cpu5 : 26.4 us, 20.8 sy, 0.0 ni, 46.1 id, 0.4 wa, 0.0 hi, 6.3 si, 0.0 st
%Cpu6 : 36.1 us, 27.0 sy, 0.0 ni, 32.1 id, 0.7 wa, 0.0 hi, 4.0 si, 0.0 st
%Cpu7 : 26.7 us, 20.6 sy, 0.0 ni, 44.0 id, 0.4 wa, 0.0 hi, 8.3 si, 0.0 st
%Cpu8 : 38.1 us, 26.3 sy, 0.0 ni, 31.7 id, 0.7 wa, 0.0 hi, 3.2 si, 0.0 st
%Cpu9 : 30.2 us, 20.6 sy, 0.0 ni, 45.9 id, 1.1 wa, 0.0 hi, 2.1 si, 0.0 st
%Cpu10 : 36.6 us, 23.3 sy, 0.0 ni, 29.7 id, 1.1 wa, 0.0 hi, 9.3 si, 0.0 st
%Cpu11 : 33.7 us, 20.6 sy, 0.0 ni, 36.5 id, 6.7 wa, 0.0 hi, 2.5 si, 0.0 st
%Cpu12 : 37.9 us, 26.7 sy, 0.0 ni, 30.3 id, 0.7 wa, 0.0 hi, 4.3 si, 0.0 st
%Cpu13 : 25.8 us, 21.2 sy, 0.0 ni, 47.7 id, 0.4 wa, 0.0 hi, 4.9 si, 0.0 st
%Cpu14 : 37.6 us, 27.7 sy, 0.0 ni, 30.9 id, 0.7 wa, 0.0 hi, 3.2 si, 0.0 st
%Cpu15 : 26.5 us, 20.2 sy, 0.0 ni, 44.9 id, 0.4 wa, 0.0 hi, 8.1 si, 0.0 st
%Cpu16 : 36.4 us, 26.2 sy, 0.0 ni, 29.5 id, 0.4 wa, 0.0 hi, 7.6 si, 0.0 st
%Cpu17 : 26.8 us, 19.1 sy, 0.0 ni, 46.7 id, 0.4 wa, 0.0 hi, 7.0 si, 0.0 st
%Cpu18 : 37.5 us, 26.7 sy, 0.0 ni, 31.8 id, 0.4 wa, 0.0 hi, 3.6 si, 0.0 st
%Cpu19 : 28.1 us, 19.7 sy, 0.0 ni, 45.6 id, 0.4 wa, 0.0 hi, 6.2 si, 0.0 st
%Cpu20 : 40.8 us, 24.5 sy, 0.0 ni, 30.5 id, 0.4 wa, 0.0 hi, 3.9 si, 0.0 st
%Cpu21 : 27.4 us, 18.9 sy, 0.0 ni, 48.1 id, 0.0 wa, 0.0 hi, 5.6 si, 0.0 st
%Cpu22 : 37.3 us, 27.2 sy, 0.0 ni, 31.5 id, 0.4 wa, 0.0 hi, 3.6 si, 0.0 st
%Cpu23 : 26.7 us, 20.9 sy, 0.0 ni, 45.1 id, 0.0 wa, 0.0 hi, 7.3 si, 0.0 st
%Cpu24 : 37.5 us, 26.8 sy, 0.0 ni, 31.4 id, 0.4 wa, 0.0 hi, 3.9 si, 0.0 st
%Cpu25 : 27.0 us, 19.7 sy, 0.0 ni, 47.1 id, 0.4 wa, 0.0 hi, 5.8 si, 0.0 st
%Cpu26 : 37.1 us, 26.3 sy, 0.0 ni, 31.7 id, 0.4 wa, 0.0 hi, 4.7 si, 0.0 st
%Cpu27 : 28.0 us, 20.7 sy, 0.0 ni, 46.2 id, 0.0 wa, 0.0 hi, 5.1 si, 0.0 st
%Cpu28 : 36.7 us, 27.0 sy, 0.0 ni, 31.7 id, 0.7 wa, 0.0 hi, 3.9 si, 0.0 st
%Cpu29 : 25.2 us, 21.9 sy, 0.0 ni, 47.4 id, 0.4 wa, 0.0 hi, 5.1 si, 0.0 st
%Cpu30 : 35.2 us, 27.5 sy, 0.0 ni, 32.7 id, 0.4 wa, 0.0 hi, 4.2 si, 0.0 st
%Cpu31 : 27.5 us, 21.8 sy, 0.0 ni, 45.8 id, 0.0 wa, 0.0 hi, 4.9 si, 0.0 st
KiB Mem : 13185980+total, 664156 free, 59399296 used, 71796360 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 71647072 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
32499 root 20 0 65.0g 54.8g 6656 S 2100 43.6 890:58.82 tendisplus
strace捕获结果
strace: Process 32499 attached
^Cstrace: Process 32499 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 116.290086 4472695 26 13 futex
0.00 0.000530 530 1 1 restart_syscall
------ ----------- ----------- --------- --------- ----------------
100.00 116.290616 27 14 total
info Dataset结果
# Dataset
rocksdb.kvstore-count:10
rocksdb.total-sst-files-size:5750242685
rocksdb.binlogcf-sst-files-size:40459830825
rocksdb.live-sst-files-size:5750242685
rocksdb.estimate-live-data-size:5422018263
rocksdb.estimate-num-keys:18874852
rocksdb.total-memory:45147367667
rocksdb.cur-size-all-mem-tables:121624216
rocksdb.estimate-table-readers-mem:19264859
rocksdb.blockcache.capacity:45006979072
rocksdb.blockcache.usage:45006478592
rocksdb.blockcache.pinnedusage:16384
rocksdb.mem-table-flush-pending:0
rocksdb.estimate-pending-compaction-bytes:0
rocksdb.compaction-pending:0
rocksdb.number.iter.skip:10
rocksdb.compaction-filter-count:441145883
rocksdb.compaction-kv-expired-count:0
perf top结果
Samples: 1M of event 'cpu-clock', 4000 Hz, Event count (approx.): 240901711755 lost: 0/0 drop: 0/0
Overhead Shared Object Symbol
10.77% [kernel] [k] __do_softirq
10.02% [kernel] [k] _raw_spin_unlock_irqrestore
5.12% [kernel] [k] finish_task_switch
2.08% libpthread-2.17.so [.] pthread_mutex_lock
1.79% libc-2.17.so [.] __memcpy_ssse3_back
1.68% [kernel] [k] __x2apic_send_IPI_mask
1.30% libpthread-2.17.so [.] pthread_mutex_unlock
1.26% tendisplus [.] free
1.25% [kernel] [k] sys_epoll_ctl
1.15% tendisplus [.] malloc
1.08% tendisplus [.] rocksdb::InlineSkipList<rocksdb::MemTableRep::KeyComparator const&>::RecomputeSpliceLevels
1.08% [kernel] [k] tick_nohz_idle_enter
1.06% libpthread-2.17.so [.] pthread_cond_wait@@GLIBC_2.3.2
1.05% tendisplus [.] rocksdb::InlineSkipList<rocksdb::MemTableRep::KeyComparator const&>::FindGreaterOrEqual
0.86% [kernel] [k] tick_nohz_idle_exit
0.84% [kernel] [k] run_timer_softirq
0.83% libpthread-2.17.so [.] __lll_unlock_wake
0.65% libc-2.17.so [.] __memcmp_sse4_1
0.62% [vdso] [.] __vdso_clock_gettime
0.60% [kernel] [k] fget_light
0.55% [kernel] [k] copy_user_enhanced_fast_string
0.53% libpthread-2.17.so [.] pthread_cond_signal@@GLIBC_2.3.2
0.51% tendisplus [.] std::_Hashtable<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits
0.50% tendisplus [.] asio::detail::executor_op<asio::detail::work_dispatcher<void tendisplus::WorkerPool::schedule<tendisplus::NetSession::schedule()::{lambda()#1}>(tendisplus::
0.48% [kernel] [k] __audit_syscall_exit
0.47% [kernel] [k] _raw_qspin_lock
0.41% libpthread-2.17.so [.] 0x000000000000ebad
0.40% [kernel] [k] system_call_after_swapgs
0.38% libpthread-2.17.so [.] __lll_lock_wait
0.37% tendisplus [.] tendisplus::NetSession::schedule
0.37% tendisplus [.] je_tcache_bin_flush_small
0.37% tendisplus [.] tendisplus::WorkerPool::consumeTasks
0.36% [kernel] [k] virtqueue_get_buf
0.35% [kernel] [k] futex_wake_op
0.34% tendisplus [.] asio::detail::write_op<asio::basic_stream_socket<asio::ip::tcp>, asio::mutable_buffers_1, asio::mutable_buffer const*, asio::detail::transfer_all_t, tendisp
0.34% [kernel] [k] __raw_callee_save___pv_queued_spin_unlock
0.33% tendisplus [.] tendisplus::NetSession::setResponse
0.31% tendisplus [.] std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release
0.31% libc-2.17.so [.] vfprintf
0.31% [kernel] [k] tcp_ack
0.30% [kernel] [k] sys_futex
0.29% tendisplus [.] asio::detail::scheduler::post_immediate_completion
0.29% tendisplus [.] std::_Hash_bytes
0.29% libc-2.17.so [.] __memmove_ssse3_back
0.27% tendisplus [.] asio::detail::epoll_reactor::start_op
版本环境信息
节点版本: redis_version:2.4.3-rocksdb-v5.13.4 压测命令: memtier_benchmark -t 10 -c 50 -s xxxx -p 6100 -a xxxx --cluster-mode --ratio=1:1 --key-minimum=1 --key-maximum=500000000 --random-data --data-size=128 --test-time=1800 机器配置: CPU: Intel(R) Xeon(R) Gold 6266C CPU @ 3.00GHz. 32核 MEM:128G DISK:500G SYytem: CentOS Linux release 7.9.2009 (Core)
你这个qps大概多少,cpu利用了多少。 另外,配置可以参考:http://tendis.cn/#/Tendisplus/运维/conf_templ
你这个qps大概多少,cpu利用了多少。 另外,配置可以参考:http://tendis.cn/#/Tendisplus/运维/conf_templ
QPS在52万左右,三个节点,set/get比例1:1
memtier_benchmark -t 10 -c 50 -s xxx -p 6100 -a xxxxx --cluster-mode --ratio=1:1 --key-minimum=1 --key-maximum=500000000 --random-data --data-size=128 --test-time=1800 --out-file=cluster_mode_1_1.log
Writing results to cluster_mode_1_1.log...
[RUN #1] Preparing benchmark client...
[RUN #1] Launching threads now...
^CUN #1 21%, 370 secs] 10 threads: 202823585 ops, 530019 (avg: 547994) ops/sec, 88.60MB/sec (avg: 91.60MB/sec), 2.83 (avg: 2.74) msec latencyy
CPU利用率在50%左右
配置文件
port 6100
daemon no
cluster-enabled yes
loglevel notice
bind 0.0.0.0
logdir /disk/ssd/tendis/cluster-tendis_sre/6100/log
dumpdir /disk/ssd/tendis/cluster-tendis_sre/6100/dump
dir /disk/ssd/tendis/cluster-tendis_sre/6100/db
pidfile /disk/ssd/tendis/cluster-tendis_sre/6100/tendisplus.pid
slowlog /disk/ssd/tendis/cluster-tendis_sre/6100/log/slowlog
#rocksdb的blockcache大小,建议每个节点使用30%系统内存
rocks.blockcachemb 42922
# rocksdb相关配置
rocks.cache_index_and_filter_blocks 0
rocks.max_open_files -1
rocks.compress_type lz4
rocks.level_compaction_dynamic_level_bytes 1
# [n >= 4, n <= 64, n ~= cpu_cores]
rocks.max_background_compactions 64
rocks.write_buffer_size 67108864
rocks.target_file_size_base 67108864
rocks.max_bytes_for_level_base 536870912
# 网络线程池数量,建议cpu数量/4,
netiothreadnum 7
# 工作线程池数量,建议略多于cpu数量
executorThreadNum 56
# binlog清理相关参数
truncateBinlogIntervalMs 100
truncateBinlogNum 500000
binlogDelRange 500000
maxbinlogkeepnum 100
binlogFileSizeMB 128
slowlog-log-slower-than 500000
slowlog-flush-interval 1000
masterauth xxx
requirepass xxx
一定要用memtier_benchmark这个工具吗?
用了源码自带的redis-benchmark
有从网上下载新的redis-benchmark --cluster
效果都很一般, qps才几万, 配置也都差不多。 40core 30%的mem
get: throughput summary: 44424.70 requests per second latency summary (msec): avg min p50 p95 p99 max 0.961 0.088 0.967 1.111 1.255 10.231
set: throughput summary: 44424.70 requests per second latency summary (msec): avg min p50 p95 p99 max 0.999 0.304 0.967 1.127 1.959 27.967
hset: Summary: throughput summary: 36218.76 requests per second latency summary (msec): avg min p50 p95 p99 max 1.297 0.288 0.991 2.039 2.983 6.535
@MollyBa 40核单节点的qps应该在50万的级别哦,你这个应该是配置不好,或者压测命令不对。
@MollyBa 40核qps应该在50万的级别哦,你这个应该是配置不好,或者压测命令不对。
50万是整个集群,还是单个节点的?如果是整个集群的,增加节点QPS会不会也是线性增加?
好问题, 同问。另外 每个节点应该存储多少的业务数据为合适呢? 或者说我拿我的业务数据 怎么确定用3主3从 还是N主N从 效果最好
确实如此
源码自带的redis-benchmark(不支持--cluster,应该是单点) 和 下载redis新版本的redis-benchmark(支持--cluster) 都不及官网提供的压测奏效
/memtier_benchmark -t 12 -c 50 -s xxxx -p yyyy --cluster-mode --key-minimum=1 --key-maximum=500000000 --random-data --data-size=128 --test-time=1800
ops:44w+

期间tendis集群节点的cpu idle在75%左右 io性能也不是瓶颈, 感觉还能调整下参数。往上压
40核单节点一般在50万以上,调整好参数可以更高,不过具体多少还得要看使用场景。 节点数越多,qps越高,一般来说是线性关系。但节点数不宜太多,比如100个以内。 另外,腾讯内部一般都是采用docker隔离小机型,比如8核16g内存500GB磁盘,这样的好处是资源利用率更高,备份,回档等运维起来更方便。当然使用32核128GB这样的大机型也是支持的,具体要看业务情况和运维情况。
40核单节点一般在50万以上,调整好参数可以更高,不过具体多少还得要看使用场景。 节点数越多,qps越高,一般来说是线性关系。但节点数不宜太多,比如100个以内。 另外,腾讯内部一般都是采用docker隔离小机型,比如8核16g内存500GB磁盘,这样的好处是资源利用率更高,备份,回档等运维起来更方便。当然使用32核128GB这样的大机型也是支持的,具体要看业务情况和运维情况。
能帮忙分析一下我的那个问题,3个节点的集群,memtier_benchmark -t 10 -c 50 压测set/get比例1:1,整个集群QPS在52万左右,算下来单机只有20万左右,CPU利用率在50%左右(其中sys占了25%,io不存在瓶颈)。调大并发线程数能到80万,但是CPU利用率也会达到80%,不知道到还有啥优化空间没有。
40核单节点一般在50万以上,调整好参数可以更高,不过具体多少还得要看使用场景。 节点数越多,qps越高,一般来说是线性关系。但节点数不宜太多,比如100个以内。 另外,腾讯内部一般都是采用docker隔离小机型,比如8核16g内存500GB磁盘,这样的好处是资源利用率更高,备份,回档等运维起来更方便。当然使用32核128GB这样的大机型也是支持的,具体要看业务情况和运维情况。
能帮忙分析一下我的那个问题,3个节点的集群,memtier_benchmark -t 10 -c 50 压测set/get比例1:1,整个集群QPS在52万左右,算下来单机只有20万左右,CPU利用率在50%左右(其中sys占了25%,io不存在瓶颈)。调大并发线程数能到80万,但是CPU利用率也会达到80%,不知道到还有啥优化空间没有。
数据差不多,我也存在这个点,单点在十几w 参数里有个maxclient 压的并发太多 直接就timeout reset peer了。 无法把cpu跑满