Performance
很多人知道 CPU 频率会影响 CPU 性能,也知道频率会动态变化,且知道 Linux 有 performance/powersave 两种频率控制策略。但很少人知道背后的软件原理,更少人知道如何调优策略,和监控实际 CPU 频率。
被误解的CPU利用率、超线程、动态调频 —— CPU 性能之迷 Part 1
· ☕ 17 分钟
CPU利用率,这个再常用,且看似简单不过的指标,在超线程、动态调频等技术影响下,其准确性、估算参考价值,均出现了大问题。
Java 容器化的历史坑(史坑) - 资源限制篇
· ☕ 5 分钟
由来
时间回到 2017 年,老东家要上 Kubernetes 了,有幸参与和学习(主要是学习)。当时遇到的一了所有 Java 容器化者都遇到的坑:JDK8 不为容器化设计综合症。最简单的例子是Runtime.getRuntime().availableProcessors()
返回了主机的 CPU 数,而非期望的容器自身的cpu share/quota
,或说 k8s 的 cpu request/limit
。
你的 Istio Mesh 性能及格吗?
· ☕ 4 分钟
前言
话说,一年前项目响应时代的号召,引入了 Istio,从此如刘备得卧龙、凤雏,走上了 Service Mesh 的光辉大道。现到准备益州之战(上线)之时。上线前,还得评估一下性能变化。
Benchmark Tools
· ☕ 1 分钟
CPU Benchmark
The SysBench system benchmark suite has a simple CPU benchmark tool that calculates prime numbers. For example:
# sysbench --num-threads=8 --test=cpu --cpu-max-prime=100000 run
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 8
Doing CPU performance benchmark
Threads started!
Done.
Maximum prime number checked in CPU test: 100000
Test execution summary:
total time: 30.4125s
total number of events: 10000
total time taken by event execution: 243.2310
per-request statistics:
min: 24.31ms
avg: 24.32ms
max: 32.44ms
approx. 95 percentile: 24.32ms
Threads fairness:
events (avg/stddev): 1250.0000/1.22
execution time (avg/stddev): 30.4039/0.01
This executed eight threads, with a maximum prime number of 100,000. The runtime was 30.4 s, which can be used for comparison with the results from other systems or configurations (assuming many things, such as that identical compiler options were used to build the software; see Chapter 12, Benchmarking).