皮振伟的专栏-腾讯云开发者社区

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

皮振伟的专栏

专栏成员

108

文章

317314

阅读量

80

订阅数

Redis网络连接层的过去、现状和展望

unix socket编程云数据库 Redis®打包编程算法

Redis取自Remote Dictionary Server，顾名思义，Redis是运行在网络环境之上的。Redis目前支持3种网络连接类型：

2022-12-03

1K0

[linux][irq]irqtop支持-C/--cpu-list

linux 云计算

在前文《[linux][irq]中断性能监控工具irqtop和lsirq》中介绍了irqtop和lsirq两条命令，用来观察系统的中断信息和增量变化。

2022-04-27

8770

[linux][bcc]使用runqslower发现调度延迟问题

前言在高性能网络模型下，使用polling模式，依然遇到了长尾20ms+的情况，远高于平均的1ms左右。怀疑是调度的延迟导致的。那么如何量化是不是内核的调度导致的呢？以及如何发现是什么原因导致的呢？分析调度延迟在前文《[Linux][kernel]sched delay和steal time的原理分析以及atop的监控改进》中分析过Linux中如何计算一个task的run delay：即一个task希望运行，但是得不到运行的时间统计，即run delay，也就是调度延迟。那么问题来了，如果通过atop监控到某一个进程的run delay是2%，能说明那20ms的长尾延迟是因为调度延迟导致的吗？答案是不能。我们看下面的两种情况： 1，例如说，Run 19ms, Delay 1ms,Run 19ms, Delay 1ms,Run 19ms, Delay 1ms。在这个模型下，统计出来的run delay是2%。 2，另外一种模型下，例如 Run 980ms, Delay 20ms, Run 980ms, Delay 20ms，这个模型下，就会遇到20ms+的长尾延迟。所以atop可以统计出来宏观的run delay延迟占比，但是不能统计出来具体的调度延迟极端情况。 runqslower工具在bcc中提供了runqslower工具，可以通过参数控制，打印出来哪些进程的调度延迟超过了特定的阈值，例如希望知道哪些进程的run delay超过10ms，可以使用这样的命令：

2021-09-02

2.1K0

[linux][bcc]使用virtiostat查看virtio设备的IOPS和吞吐

ios linux node.js html 编程算法

前言在linux平台上，我们经常需要使用各种各样的工具查看设备的使用情况。例如使用iostat查看块设备的IO情况，使用iftop查看网卡设备的流量情况。但是virtio family的设备这种越来越多，virtiofs、virtio gpu、virtio console等设备却缺少相应的工具。基于以上原因，作者开发了virtiostat工具，作为bcc工具集的一部分，提供了virtio设备的stat监控能力。分析原理在Linux上，virtio设备进行IO的时候，会先生成scatterlist这样的数据结构，然后使用如下几个API，把数据加入到virt queue中：

2021-03-18

3.4K0

[linux][redis]redis支持disable-thp了

云数据库 Redis®https github 网络安全 git

前言前文《[linux][redis]bgsave引起的latency突刺问题分析》中记录了在执行bgsave的时候，因为fork子进程之后，会出现page fault导致了redis的延迟受到了影响。前文《[THP][redis]THP对redis的影响》中分析了THP（transparent hugepage）对redis的延迟突刺的影响。大约两年半以前，作者给redis提了PR(https://github.com/redis/redis/pull/5124)，但是maintainer并没有回复，一段时间后关闭。几个月前，第二次提PR（https://github.com/redis/redis/pull/7381）希望解决这个问题，新任的maintainer Oran对THP问题比较感兴趣，同时也把三年多以前的另外一个PR（https://github.com/redis/redis/pull/4001）翻了出来。大约经过一周的讨论和修改，两个PR都已经合入了upstream。分析 THP的内核逻辑内核提供了THP开关可以控制，/sys/kernel/mm/transparent_hugepage/enabled，这个开关需要root权限，且是系统级别的影响。 always表示所有的进程都会被khugepaged扫描，尝试使用2M的透明大页。 madvise表示如果有进程调用了THP开关，则打开/关闭。 never表示khugepaged不会对任何进程生效，包括使用madvise的进程。 warning判断 redis的原有的逻辑是在启动阶段检查系统的THP配置，如果不是never，就会产生一个warning。redis自身并没有使用过madvise进行THP操作，即使使用了jemalloc，也不会对主要的内存进行THP操作。所以改成不是always就应该是安全的，所以，Oran接受了这个改动（https://github.com/redis/redis/pull/4001）。关闭redis的进程THP 更加理想的做法是不管系统配置如何，redis都可以把自己进程的THP开关禁用掉，这样子不需要root权限控制，且不会影响其他的进程。Linux恰好提供了这样了一个syscall，所以在（https://github.com/redis/redis/pull/7381）中，会关闭掉。同时，根据Oran的意见，增加了配置项，在多数情况下，默认都是会自动关闭掉THP，除非用户强制指定了不关闭的配置。这样下来，在大多数情况下，用户都可以避免THP引起的fork之后的剧烈抖动问题。关于conf的描述在redis.conf中增加了一个新的配置项“disable-thp”，作者最初的描述是

2020-11-09

2K0

[linux][tcp]tcprtt在server端监控多个client延迟

https github 网络安全 git 开源

前言前文《[linux][tcp]使用tcprtt排查网络延迟问题》介绍了tcprtt的基本用法，可以监控特定的连接的TCP的rtt情况。后来，Branden Gregg大神上阵，也提出了一些改进意见。分析 Branden Gregg的意见讨论链接 https://github.com/iovisor/bcc/pull/3068

2020-10-27

1K0

[linux][tcp]使用tcprtt排查网络延迟问题

前言网络后端业务，经常会遇到延迟抖动的问题。那么问题来了，如何排除出来是网络的问题呢，还是业务的逻辑问题呢，或者是其他的调度问题呢？分析 SRTT 在TCP的连接中，有一个指标叫做SRTT（smoothed round trip time），关于SRTT的计算方法，可以参考linux/net/ipv4/tcp_probe.c，具体的计算逻辑可以参考代码，以及注释中的论文，不在这里展开（主要是作者看不懂）。所以，能够dump出来的TCP连接的srtt，生成柱状图观察出来延迟的区间变化，我们就可以知道网络连接的srtt是否抖动。如果业务延迟发生了抖动，srtt很稳定，就可以说明大概率不是网络的问题，可能是业务的问题，或者调度的问题等等; 反之，如果srtt页发生了抖动，那么可以先检查一下网络连接。和tcp probe的关系 tcp probe是内核提供的debug模块，也可以完成类似的功能，不过在高版本的内核上，已经移除掉了。从原理上来看，都是基于kprobe原理，hook住tcp_rcv_established函数，来dump出来必要的数据。但是，在使用性上没有bcc方便。需要说明的是，基于kprobe原理的工具都有overhead，在特别频繁调用到的路径上，需要谨慎使用。 tcprtt使用方法和例子

2020-09-23

2.9K0

[Linux][kernel]sched delay和steal time的原理分析以及atop的监控改进

前言在虚拟化场景下，经常会用到steal time来判断虚拟机的vCPU执行是否被抢占，进而来衡量虚拟机的性能指标。同时，在延迟敏感型的业务上（例如redis），会用sched delay来分析延迟突刺类问题。这里我们来分析steal time以及进程的sched delay的原理和实现。再进一步延伸到atop对sched delay的支持，做到带外监控。分析 schedstat中的run delay 在进程的proc目录下，存在文件/proc/<PID>/schedstat 在内核文档中可以找到下面的描述

2020-07-09

2.9K0

[Linux][mm]watermark_scale_factor的调整以及遇到的问题

在较高的Linux版本上，支持了watermark_scale_factor参数（完整路径/proc/sys/vm/watermark_scale_factor）调整，这个数值可以比较有效的控制内存回收。

2020-06-28

5.7K0

[linux][redis]redis对cpu亲和性的支持

云数据库 Redis®http https github 网络安全

前言 redis在最近的版本中，开始了对多线程的支持。加上之前对多进程的支持，模型的复杂度也比过去复杂了不少。 redis本身又是一个对性能、延迟非常敏感的业务，多种因素都可能导致小问题。基于上述原因，作者对redis做了CPU亲和性的系统支持，并合入了upstream。分析代码 Redis 6.0.2版本中开始支持 https://github.com/antirez/redis/commit/ae306a3df6cf63b31a0814cb5393a9df59947d2e

2020-05-26

1.6K0

[linux][system]atop的介绍和使用

github 缓存 git 开源

前言 Linux上运行大量的后端的业务程序，往往希望得到更快的响应速度，更小的延迟，甚至有严格的PCT 99的指标。而操作系统的复杂度很高，多个因子之间可能会互相影响，从而影响到业务的指标。在作者的工作环境中，经常使用到atop工具进行问题分析。atop是一个小巧的、高性能、比较全面的系统/进程级别的监控软件，下面就来介绍一下它的主要功能。分析源代码源代码目前主要维护在github上面，https://github.com/Atoptool/atop 代码的原作者也是现在的maintainer通常会在几周甚至个把月的时间处理一下Pull Request，如果有新的改动需要合入到upstream，还是需要一点耐心的。基本原理介绍在源代码中的atop.c中有如下描述：

2020-05-09

2K0

[linux][irq]中断性能监控工具irqtop和lsirq

目前的主流服务器都拥有较多的CPU，2 NUMA node情况下，打开HyperThread，CPU数量通常都在40、64、96、128、192、256左右。

2020-03-18

4K0

[linux][qemu]PVPanic的缺陷和完善

前文《[linux][qemu]PVPanic的实现原理以及应用》中，介绍了pvpanic的原理和基本的使用方法，KVM虚拟化场景下，使用pvpanic驱动可以监控到Guest的panic。

2020-02-25

2.1K0

[linux][perf]list过长导致CPU消耗过高的问题分析

某机器上网络出现时断时续的问题，网络的同事发现ovs进程的CPU消耗很高，硬件offload的规则下发卡住的问题。即通过netlink向内核发送消息卡住。

2019-12-15

1.7K0

[linux][tcp]CLOSE_WAIT的一个TCP问题

某机器上残留了很多CLOSE_WAIT状态的TCP连接，使用netstat却看不到是哪一个进程在使用。

2019-12-13

2.4K0

基于KVM虚拟化的混合部署

linux 编程算法虚拟化 kvm 云数据库 SQL Server

KVM forum 2019上，作者和同事的演讲主题是《How KVM-based Hybrid Deployment Powers Bytedance’s Biggest Day Ever》。在这里详细展开一下，介绍一下基于KVM虚拟化的混合部署。下文的脉络大约是： 1，业务背景 2，为什么使用KVM虚拟化方案 3，在使用KVM虚拟化方案的过程中，我们做了那些改进 4，基于KVM虚拟化的混合部署方案取得了怎样的效果

2019-11-12

2K0

[Linux][mm]TLB shootdown和读取smaps对性能的影响

缓存 c++编程算法

作者遇到了业务的一个性能抖动问题，在这里介绍一下它的原因和解决办法。分析 1，page fault 在Linux上，进程分配到的内存是虚拟内存，经过内核的页表管理，会把虚拟内存映射成物理内存。 a，在第一次访问内存的时候，会触发page fault，内核会给进程分配好内存，进程继续执行。 b，内核进行内存回收，可能会把进程的部分内存进行回收，swap到磁盘上，下次访问到再换回来。当然，这个在实际业务上未必会启用swap以防止性能下降。 c，进程自己判断，认为部分内存段时间内不会使用，会尝试把它归还给内核。它的好处是不需要修改进程的虚拟地址空间，只是把内存页面（page）归还给内核，下一次访问到的时候，会因为page fault而重新分配物理内存。另外需要注意的时候，处理page fault的过程中，需要持有进程的内存的锁（current->mm->mmap_sem）。 2，TLB shootdown 例如某服务器有40CPU，那么就意味着可以同时运行40个task。例如某业务有30个线程，且这30个线程都很忙，并行执行在30个CPU上。因为30个线程共享地址空间，它们使用的是相同的页表（page table）。所以在运行这30个线程的CPU上，会加载相同的页表。当代CPU为了加速TLB查找的速度，会使用cache，也就是说会把对应的页表项（page table entry）加载到TLB cache中。在运行的某一个时刻，某1个线程执行了上述的page fault的case 3，也就是执行了系统调用int madvise(void *addr, size_t length, MADV_DONTNEED)，想要释放1个page（4K大小），除了需要修改页表释放该page外，还需要确保CPU的TLB cache中也是没有该page的PTE的。因为如果TLB cache还有该PTE，那么CPU访问这个page就不会出错，而这个page已经被释放并分配给其他进程使用的话，就会造成安全问题。在多核场景下，这个问题就变得更加复杂了。除了运行madvise的线程之后，还需要确保另外的29个线程运行的CPU的TLB cache也是没有该PTE的。为了实现这种效果，需要当前的CPU通知另外的29个CPU，执行clflush或者重新加载cr3。这个通知的过程需要发送IPI（inter processor interrup）。发送IPI的这个过程，在x86上的体现就是需要CPU执行wrmsr指令，对应的操作是触发ICR。了解虚拟化的朋友应该知道，wrmsr这条指令在虚拟机上需要经过Hypervisor处理，性能更低一些。除此之外，在执行madvise的过程中，还需要持有当前进程的内存的锁（current->mm->mmap_sem），而且这个锁的粒度比较大。而jemalloc库，默认情况下，则会释放过期的内存，调用madvise(void *addr, size_t length, MADV_DONTNEED)。 3，smaps/smaps_rollup cat /proc/PID/smaps，可以查看进程的每一段VMA信息。

2019-10-15

3.2K0

[Linux][seccomp]seccomp引起的SIGSYS问题

虚拟化命令行工具编程算法 shell

前言作者习惯使用Libvrit，多数情况下，会直接使用libvirt进行虚拟机操作。如果要用qemu启动的情况，一般会比较习惯ps -ef | grep qemu得到qemu的启动参数，进行修改，然后启动。在一次启动中，qemu发生了错误：qemu-system-x86_64: network script /etc/qemu-ifup failed with status 159 问题的原因是因为seccomp的配置导致的，那么我们就来看一下这个问题的具体表现。分析实例代码构造一段实例代码，在父进程中初始化了seccomp，禁用了execve这个syscall，在子进程中尝试调用execve运行其他的程序。 #include <stdio.h> #include <unistd.h> #include <sys/types.h> #include <sys/wait.h> #include <seccomp.h> char *cmd = "/bin/ls"; int main() { int pid, status, ret; char *args[4]; char **parg; scmp_filter_ctx ctx; ctx = seccomp_init(SCMP_ACT_ALLOW); if (ctx == NULL) { printf("seccomp_init fail\n"); return 0; } ret = seccomp_rule_add(ctx, SCMP_ACT_KILL, SCMP_SYS(execve), 0); if (ret < 0) { printf("seccomp_rule_add fail\n"); return 0; } ret = seccomp_load(ctx); if (ret < 0) { printf("seccomp_load fail\n"); return 0; } seccomp_release(ctx); pid = fork(); if (pid == 0) { parg = args; *parg++ = cmd; *parg++ = "-al"; *parg++ = "/proc/self/fd"; *parg = NULL; execv(cmd, args); } else { while (waitpid(pid, &status, 0) != pid); printf("status %d\n", status); } return 0; } 需要先安装libseccomp-dev（apt-get install libseccomp-dev），编译的时候: gcc execv.c -g -o execv -lseccomp 运行可以发现，子进程并不是正常退出的。打开coredump 调整/proc/sys/kernel/core_pattern，配置coredump文件生成的规则。 ulimit -c unlimited调整但前shell的coredump文件大小限制，在当前的shell下运行，文件大小生效。

2019-07-30

2.4K0

[x86][QEMU]虚拟化场景下的CPU拓扑

虚拟化缓存 socket编程

前言目前的主流服务器一般是二路，即有2个NUMA node。每个NUMA上有一个CPU。比较主流的CPU一般是10Core/12Core，打开了Hyper-thread的场景下，就是2 Sockets × 10/12 Cores/socket × 2 Hyper-threads/Core，也就是40核或者48核。对于大规格的虚拟机，尤其是32 vCPU或者40vCPU的场景下，对于计算密集型的业务，需要把物理机的CPU拓扑信息正确的透传到虚拟机中，否则跨Socket的内存访问，同一个Core下的两个Hyper-thread的资源的争抢，都是影响性能的关键因素。分析 Host上拓扑关系我们一般会用lscpu命令看到基本的CPU拓扑信息，也可以通过cat /proc/cpuinfo的方式看到“physical id”，“core id” cpuid 再进一步探讨，Host kernle是怎么获取到的CPU的拓扑关系的呢？ Linux有命令cpuid，代码在https://github.com/tycho/cpuid cpuid命令的结果截取如下：

2019-05-16

2.8K0

[linux][atop]atop的改进和在统计io上遇到的问题

企业 bash bash 指令 linux

前言互联网公司一般都会运行着几千到几万的服务器。一般的监控会采用类似ganglia/falcon类似的工具，在本地启动一个agent，把数据统计上报到集中式的服务器中，用来监控和分析系统的问题。另外，有atop这样的工具，可以运行在服务器上，在本地写下record文件，atop命令本身也可以分析record文件，其中保存的数据的粒度更加细致，可以精确到线程级别，还有IPC，主频等等。经验来看，atop每天生成的record文件大约500M左右，保存最近的一段时间，似乎也不是问题。用集中式的监控，配合上atop，对于问题分析来说，会有一些帮助。分析 1,atop的改进 atop的代码量本身并不大，官方的代码在： https://github.com/Atoptool/atop.git 在使用atop的过程中，遇到了一些问题，作者也做了相应的修改： https://github.com/bytedance/atop 在bytedance-features分支上。作者把patch发送给maintainer，但是maintainer一直没有回复。在这里，列举一下改动的内容，如下。 2,smaps的优化尝试使用smaps_rollup代替smaps，用来提高atop收集进程的PSS内存使用的效率。这个patch会在4.14上有所提升。一般情况下，建议在atop收集的时候不要加上-R选项。因为在atop读/proc/PID/smaps的时候，会walk整个PID进程的页表，期间会lock住内存页表的锁。如果在这期间PID进程发生了page fault，也需要lock，就会造成锁的进程。影响PID进程的性能。 3,数据破损问题 atop使用裸数据的方式保存record文件，其中包括三部分：raw record，就是头信息; scompbuf，是系统状态信息的数据; pcompbuf，是task级的状态信息数据，大小和task数量有关系。为了减小record文件的大小，对于 scompbuf和pcompbuf还采用了压缩。所以，数据必须完整的 rr,scompbuf,pcompbuf顺序写下去的，否则atop无法识别数据。 good case : ... rr,scompbuf,pcompbuf ... rr,scompbuf,pcompbuf ... bad case : ... rr,scompbuf[missing] ... rr,scompbuf,pcompbuf … 例如上面的例子，在写完rr,scompbuf之后，atop发生了crash，再重新启动，就会丢失后面的 pcompbuf，造成了整个record文件的不可用。在patch中，作者使用writev进行写入数据，要么都写入成功，要么都写入不成功，用来防止这种case发生。 4,IPC造成的虚拟机性能抖动 IPC,instructions per cycle。可以用来衡量CPU运行的效率。通常是通过perf采集的数据。提到perf，就要说明一下它的工作原理：intel的CPU上集成了PMU，用来采集硬件的信息。可以收集的硬件信息很多，可以通过perf list | grep Hardware来看。但是硬件的寄存器有数量限制，所以需要通过wrmsr指令告诉CPU收集哪些具体的事件，再通过rdpmc指令来读取对应的数据。在虚拟化场景下，在虚拟机中使用PMU又复杂了一下，在虚拟机中执行wrmsr和rdpmc的时候，都需要虚拟机从none-root模式退出，影响了虚拟机的性能。在patch中，作者让atop支持perfevents的配置，支持三种模式：enable模式，启用perf收集IPC。disable模式，禁用perf收集IPC。auto模式，在启动的时候，atop自动检查是否在虚拟机中运行，如果在虚拟机中，禁用;在物理级中，启用。默认是auto模式。 5,减小record文件如果是大规格的服务器，40CPU，甚至到96CPU，通常运行大量的docker，里面运行了很多的task。其中很多task占用资源很少，但是依然会占用atop的record文件。在patch中，支持了配置参数recordcputop & recordmemtop。用来配置收集cpu和内存的topN。其他的task可以忽略。作者测试线上的服务器36CPU, about 500 processes的场景，大约节省了40%的磁盘空间。 6,加速读record 一般在ganglia上看到系统抖动，例如下午三点十分，在对应的服务器上执行： atop -r / var/log/atop/atop_xxxx -b 15:10 如前文所述，因为rawrecord的原因，则会从头读到尾，直到匹配到对应的时间。对于log盘的使用，尤其是虚拟化场景，会限制IOPS。这

2019-05-07

2.2K0

点击加载更多

社区活动

【纪录片】中国数据库前世今生

穿越半个世纪，探寻中国数据库50年的发展历程

Python精品学习库

代码在线跑，知识轻松学

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

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

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

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