腾讯云开发者社区-腾讯云

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

皮振伟的专栏

专栏作者

108

文章

298750

阅读量

78

订阅数

[x86][gcc]PAUSE指令在Skylake上引起的性能问题

前言： docker部署的相同的业务，Host OS也是相同的版本，但是一段代码跑在E5-2630 v4和Gold 5118上，性能却相差很多。业务在在Gold 5118上，QPS下降到了E5-2630 v4的三分之一左右，而且CPU使用率更高。 Gold 5118是Products formerly Skylake系列，E5-2630 v4是Products formerly Broadwell 系列。按理说，Skylake是更新的架构，性能应该更好才对，然而实际表现却并非如此。分析： 1,perf 在两台机器分别执行perf，发现在5118上，有些不同的地方，libgomp中出现了热点。先用md5sum确认两个so是否出现了差异，结果是相同的。因为libgomp被strip过，所以没有对应的symbol，perf只能拿到热点的IP：0xfc79。使用#objdump -D得到disassembly code，如下

2018-12-17

2K0

[linux][x86]LOCK指令的影响

前言：一般多线程并行操作，对个别的变量需要使用原子操作，经常用到__sync_fetch_and_add类似的函数，来避免CPU操作各自的cache没有同步内存而造成的数据数错。在x86平台上，反汇编__sync_fetch_and_add就可以看到，实际上是lock addq $0x1,(%rax)。如果多个CPU并行使用__sync_fetch_and_add，会不会造成性能问题呢？LOCK指令的影响范围是多少呢？同一个CORE的两个THREAD，同一个SOCKET的两个CORE，以及两个SOCKET之间呢？分析： 1，sample code 手写一段代码，两个thread分别可以绑定在两个CPU上，一起跑__sync_fetch_and_add，看看时间上是不是会受到影响。需要注意的是“long padding[100]; // avoid cache false-sharing”这行，加上padding用来避免CPU cache的false-sharing问题。 #include <sched.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <stdint.h> #include <sys/time.h> #include <pthread.h> void bench_atomic(long *l) { long loop; struct timeval start, end; suseconds_t eplased = 0; gettimeofday(&start, NULL); // benchmark for (loop = 0; loop < 0x20000000; loop++) { __sync_fetch_and_add(l, 1); } gettimeofday(&end, NULL); eplased = (end.tv_sec - start.tv_sec)*1000*1000 + end.tv_usec - start.tv_usec; printf("ATOMICC test %ld msec\n", eplased); } void *routine(void *p) { long *l = (long*)p; cpu_set_t my_set; CPU_ZERO(&my_set); CPU_SET(*l, &my_set); sched_setaffinity(0, sizeof(cpu_set_t), &my_set); *l = 0; bench_atomic(l); } int main(int argc, char **argv) { pthread_t p0, p1; long cpu0 = 4; long padding[100]; // avoid cache false-sharing long cpu1 = 8; if (argc != 3) { printf("%s CPU CPU\n", argv[0]); return 0; } cpu0 = atoi(argv[1]); cpu1 = atoi(argv[2]); padding[0] = cpu0; printf("main thread run on CPU %ld, worker thread run on CPU %ld and CPU %ld\n", padding[0], cpu0, cpu1); bench_atomic(&padding[0]); pthread_create(&p0, NULL, routine, &cpu0); pthread_create(&p1, NULL, routine, &cpu1); pthread_join(p0, NULL); pthread_join(p1, NULL); printf("result %ld and CPU %ld\n", cpu0, cpu1); return 0; } 2, cpu topology 使用lscpu判断cpu的分布

2018-11-30

2K0

[qemu][io]虚拟化IO latency监控

前言： Linux的很多监控组件，主要针对IOPS和IO带宽进行监控。很多业务场景下，希望对IO的延迟做监控。单纯的await并不能反映出来IO的延迟具体情况。例如，ETCD的QPS偏高的时候，latency发生了抖动，长尾效应比较明显。第一反映是IO抖动？还是GC导致？如果有监控组件，这段时间内，IO latency的抖动和QPS的抖动基本一致，那就比较容易判断是不是IO导致的问题。分析： 1，QEMU IO 图片选自前文《[linux][storage]Linux存储栈》

2018-11-08

2K0

[x86][linux]AVX512指令引起的进程crash

问题背景：在开发机上编译ovs，在目标机器上运行，出现来ovs-vswitchd崩溃，dmesg得到如下信息： [ 2807.148361] traps: ovs-vswitchd[10511] trap invalid opcode ip:55d4eed2fb51 sp:7ffe19a29700 error:0 in ovs-vswitchd[55d4eecb2000+721000] [ 2807.401581] traps: [11296] trap invalid opcode ip:55d4eed2fb51 sp:7ffe19a29700 error:0 in ovs-vswitchd[55d4eecb2000+721000] [ 2817.557260] traps: [11324] trap invalid opcode ip:55d4eed2fb51 sp:7ffe19a29700 error:0 in ovs-vswitchd[55d4eecb2000+721000] [ 2822.415470] traps: ovs-vswitchd[11437] trap invalid opcode ip:55aed509cb51 sp:7fffbaf19260 error:0 in ovs-vswitchd[55aed501f000+721000] [ 2827.713594] traps: [11471] trap invalid opcode ip:55d4eed2fb51 sp:7ffe19a29700 error:0 in ovs-vswitchd[55d4eecb2000+721000] [ 2837.869480] traps: [11529] trap invalid opcode ip:55d4eed2fb51 sp:7ffe19a29700 error:0 in ovs-vswitchd[55d4eecb2000+721000] [ 2870.048788] traps: [11587] trap invalid opcode ip:55d4eed2fb51 sp:7ffe19a29700 error:0 in ovs-vswitchd (deleted)[55d4eecb2000+721000] [ 2870.199582] traps: [12442] trap invalid opcode ip:55d4eed2fb51 sp:7ffe19a29700 error:0 in ovs-vswitchd (deleted)[55d4eecb2000+721000] [ 2880.330830] traps: [12459] trap invalid opcode ip:55d4eed2fb51 sp:7ffe19a29700 error:0 in ovs-vswitchd (deleted)[55d4eecb2000+721000] [ 2890.462325] traps: [12484] trap invalid opcode ip:55d4eed2fb51 sp:7ffe19a29700 error:0 in ovs-vswitchd (deleted)[55d4eecb2000+721000] 问题分析： 1，指令错误分析 log的内容是一致的，随便截取一行来看： [ 2807.401581] traps: [11296] trap invalid opcode ip:55d4eed2fb51 sp:7ffe19a29700 error:0 in ovs-vswitchd[55d4eecb2000+721000] 可以看到，是因为执行了invalid opcode导致的。很可能是指令集的原因导致的。 2，定位根据ip:55d4eed2fb51和map信息ovs-vswitchd[55d4eecb2000+721000]，可以推算出来，出错的地址是0x55d4eed2fb51 - 0x55d4eecb2000 = 0x7db51 反汇编，执行命令objdump -D /root/openvswitch-dpdk/openvswitch-2.9.2/vswitchd/ovs-vswitchd > obj，截取0x7db51偏移的代码片段： 000000000007db50 <rte_vfio_enable>: 7db50: 55 push %rbp 7db51: 62 f1 fd 48 6f 15 25 vmovdqa64 0x4ab325(%rip),%zmm2 # 528e80 <__func__.8528+0x950> 7db58: b3 4a 00

2018-10-23

4.8K0

[linux][intel]linux对intel c-state和p-state的支持分析

前言：前文《[qemu][acpi]从虚拟化看ACPI》中，介绍了ACPI的大概逻辑，以及ACPI sleep的S1,S2,S3（STR）,S4（STD），S5状态。关于节电，intel提供了c-state和p-state的CPU级别的控制，linux也对其进行了支持。分析： 1,c-state 关于c-state的详细解释，参考intel的文档https://software.intel.com/en-us/articles/power-management-states-p-states-c-states-and-package-c-states

2018-08-13

3.3K0

[qemu][iSCSI]一种基于权重自动选择最优iSCSI访问路径的方法

前言： qemu和后端存储设备之间，使用iSCSI协议的情况下，为了防止后端出现崩溃，一般会使用iSCSI redirect功能做高可用。在两条iSCSI路径的情况下，iSCSI redirect确实能做到一部分高可用的能力。然而，实际情况下，iSCSI redirect需要额外的管理工作，而且只支持两条。组件的数量变多，也导致了连接数量变多，作者认为并不是最好的解决方案。于是，作者设计并实现了另外的一个方案。这个方案并不是业界的通用方案，目前作者把这个方案命名为“iSCSI priority path”。分析： 1，iSCSI redirect 先来分析iSCSI redirect方案的实现原理：

2018-07-23

1.2K0

[linux][fuse]fuse技术分析以及遇到的问题

前言：简单看了一下glusterfs，使用单节点构造glusterfs环境，导出的路径是是本地SSD在分区上。用qemu挂载glusterfs上的卷，用FIO测试IOPS，测试结果不理想。大致分析了一下，怀疑fuse会导致性能下降。分析： 1，libfuse & fuse 为了方便测试和便于分析问题，使用了libfuse。代码地址https://github.com/libfuse/libfuse 编译libfuse比较麻烦，不支持Makefile，需要用meson编译，而且meson的版本要求比较高，不能用apt-get直接安装。操作方法就是下载高版本的meson包，在meson包里面执行python3 setup.py install。除了用户态的libfuse之外，还需要kernel支持。作者在Ubuntu1804上测试，fuse已经被编译到kernel中。在config文件（内核配置文件即ls /boot/config-`uname -r`）中CONFIG_FUSE_FS。如果是kmod的方式编译，执行modprobe fuse。

2018-07-23

3.4K0

[qemu][seccomp]虚拟化安全sandbox技术分析

前言： libvirt-4.3搭配qemu-2.12使用，如果使用默认的编译选项，可能会让qemu无法正常启动虚拟机。会报出来“qemu-system-x86_64: -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: seccomp support is disabled”的错误。好吧，老习惯，分析代码。分析： 1， seccomp support is disabled

2018-07-23

3K0

[THP][redis]THP对redis的影响

前言：前文《[linux][redis]bgsave引起的latency突刺问题分析》分析了redis-server执行bgsave因为fork引起的latency突刺问题。而在http://antirez.com/news/84中也提到了“However this is definitely not the full story”，剩下的story则是Linux的THP对redis的影响。分析： 1，THP vs Normal page 配置了THP策略分别是always和never，redis-server和redis-benchmark配置相同的参数，执行bgsave的latency对比：

2018-07-23

1.6K0

[linux][redis]bgsave引起的latency突刺问题分析

前言： redis启动的时候，可能会提示“WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.” redis的作者antirez的解释：http://ntireza.com/news/84 在stackoverflow上也能找到类似的问题，在执行bgsave的时候，redis的latency监控能看到明显的突刺。作者看到这个问题后，比较担心THP对虚拟化产生影响，于是做了对比实验，以及分析了这个突刺问题发生的原因。分析： 1，THP 前文《[linux][memory]hugetlb和hugepage技术分析》中提到了透明大页，在复现bgsave引起的latency突刺问题的时候，关闭THP的情况下，依然可以复现到突刺现象。鉴于这种情况，先来关闭THP，分析一下bgsave对redis的影响。 2，复现现象关闭THP：echo never > /sys/kernel/mm/transparent_hugepage/enabled 启动redis-server：redis-server /etc/redis.conf 启动压测：redis-benchmark -t set -n 1000000 -r 1000000 -d 1024 -l 抓取latency数据：while (true); do redis-cli --latency >> latency.log; done 抓取redis的major和minor fault数据：while (true); do ps -o majflt,minflt -p 16321 >>flt.log ; sleep 1; done 启动bgsave：redis-cli bgsave 停止抓取数据，处理 latency.log 执行：cat latency.log | awk '{print $3}' | tr "\n" "," 处理后的数据画图分析：

2018-07-23

1.6K0

[golang][image]golang的cloud image编辑工具库cloudimageeditor开源

虚拟机镜像的方式很多种，包括qcow2类型的文件，或者raw格式的文件，再或者远端的iscsi裸LUN等等。很多时候，我们需要提前编辑修改或者注入一些文件到镜像中，通过敲命令的方式固然可以做到，相对麻烦并容易出错。

2018-07-23

6810

[linux][memory]hugetlb和hugepage技术分析

前言：乍一看，hugetlb和hugepage还挺像的，好像都是所谓的“大页”。然而，却很难说出来它们的差异。作者也是花了写时间翻翻代码，写了几个测试的例子，加上用工具据实测了几个关键参数，才明白。分析： 1，page fault 用户大多数情况下申请内存的方法： a，使用malloc函数族，其实是glibc封装了brk/mmap。这种情况下分配的是虚拟内存，并没有直接分配物理内存。 b，调用brk分配，这种情况很少见，并只分配虚拟内存。 c，使用mmap，分配出来虚拟内存。如果flags带有MAP

2018-04-09

7.4K0

[network][wenbench]一款不错的HTTP压力测试工具

前言：作者曾经接到一个需求，会在一个相对较短的时间内，会有大量的http请求。代码写完之后，需要压力测试一下。在网上无意间看到过webbench这个工具，于是就使用了一下。原生代码并不支持cookie和http回包的内容校验，作者就自己发挥了一下，完成了这个功能。 cookie一般用来测试有登录态等信息的情况下使用。 http回报用来校验http返回的信息，是否有逻辑错误等，http回包成功，不代表业务处理正常，毕竟要保证的是业务处理正常。代码： https://github.com/pacepi

2018-04-09

1.1K0

[libvirt][nginx]libvirt文档访问速度提高的小技巧

前言：熟悉上图的朋友，应该都是libvirt的开发者或者使用者。 http://libvirt.org/提供了libvirt的开发文档，但是有时候，它的访问速度真的很慢很慢。下面，介绍一种小技巧

2018-04-09

9120

没有更多了

社区活动

RAG七天入门训练营

鹅厂大牛手把手带你上手实战

Python精品学习库

代码在线跑，知识轻松学

博客搬家 | 分享价值百万资源包

自行/邀约他人一键搬运博客，速成社区影响力并领取好礼

技术创作特训营·精选知识专栏

往期视频·千货材料·成员作品最新动态