首页
学习
活动
专区
工具
TVP
发布

皮振伟的专栏

专栏作者
108
文章
293759
阅读量
78
订阅数
Redis网络连接层的过去、现状和展望
Redis取自Remote Dictionary Server,顾名思义,Redis是运行在网络环境之上的。Redis目前支持3种网络连接类型:
皮振伟
2022-12-03
8550
[linux][irq]irqtop支持-C/--cpu-list
在前文《[linux][irq]中断性能监控工具irqtop和lsirq》中介绍了irqtop和lsirq两条命令,用来观察系统的中断信息和增量变化。
皮振伟
2022-04-27
7780
[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
1.9K0
[linux][bcc]使用virtiostat查看virtio设备的IOPS和吞吐
前言 在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.3K0
[linux][redis]redis支持disable-thp了
前言 前文《[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
1.8K0
[linux][tcp]tcprtt在server端监控多个client延迟
前言 前文《[linux][tcp]使用tcprtt排查网络延迟问题》介绍了tcprtt的基本用法,可以监控特定的连接的TCP的rtt情况。 后来,Branden Gregg大神上阵,也提出了一些改进意见。 分析 Branden Gregg的意见 讨论链接 https://github.com/iovisor/bcc/pull/3068
皮振伟
2020-10-27
9150
[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.6K0
[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.5K0
[Linux][mm]watermark_scale_factor的调整以及遇到的问题
在较高的Linux版本上,支持了watermark_scale_factor参数(完整路径/proc/sys/vm/watermark_scale_factor)调整,这个数值可以比较有效的控制内存回收。
皮振伟
2020-06-28
4.3K0
[linux][redis]redis对cpu亲和性的支持
前言 redis在最近的版本中,开始了对多线程的支持。加上之前对多进程的支持,模型的复杂度也比过去复杂了不少。 redis本身又是一个对性能、延迟非常敏感的业务,多种因素都可能导致小问题。基于上述原因,作者对redis做了CPU亲和性的系统支持,并合入了upstream。 分析 代码 Redis 6.0.2版本中开始支持 https://github.com/antirez/redis/commit/ae306a3df6cf63b31a0814cb5393a9df59947d2e
皮振伟
2020-05-26
1.5K0
[linux][system]atop的介绍和使用
前言 Linux上运行大量的后端的业务程序,往往希望得到更快的响应速度,更小的延迟,甚至有严格的PCT 99的指标。而操作系统的复杂度很高,多个因子之间可能会互相影响,从而影响到业务的指标。 在作者的工作环境中,经常使用到atop工具进行问题分析。atop是一个小巧的、高性能、比较全面的系统/进程级别的监控软件,下面就来介绍一下它的主要功能。 分析 源代码 源代码目前主要维护在github上面,https://github.com/Atoptool/atop 代码的原作者也是现在的maintainer通常会在几周甚至个把月的时间处理一下Pull Request,如果有新的改动需要合入到upstream,还是需要一点耐心的。 基本原理介绍 在源代码中的atop.c中有如下描述:
皮振伟
2020-05-09
1.8K0
[linux][irq]中断性能监控工具irqtop和lsirq
目前的主流服务器都拥有较多的CPU,2 NUMA node情况下,打开HyperThread,CPU数量通常都在40、64、96、128、192、256左右。
皮振伟
2020-03-18
3.3K0
[linux][qemu]PVPanic的缺陷和完善
前文《[linux][qemu]PVPanic的实现原理以及应用》中,介绍了pvpanic的原理和基本的使用方法,KVM虚拟化场景下,使用pvpanic驱动可以监控到Guest的panic。
皮振伟
2020-02-25
1.9K0
[linux][perf]list过长导致CPU消耗过高的问题分析
某机器上网络出现时断时续的问题,网络的同事发现ovs进程的CPU消耗很高,硬件offload的规则下发卡住的问题。即通过netlink向内核发送消息卡住。
皮振伟
2019-12-15
1.6K0
[linux][tcp]CLOSE_WAIT的一个TCP问题
某机器上残留了很多CLOSE_WAIT状态的TCP连接,使用netstat却看不到是哪一个进程在使用。
皮振伟
2019-12-13
2.2K0
基于KVM虚拟化的混合部署
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
1.9K0
[Linux][mm]TLB shootdown和读取smaps对性能的影响 ​
作者遇到了业务的一个性能抖动问题,在这里介绍一下它的原因和解决办法。 分析 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
2.8K0
[Linux][seccomp]seccomp引起的SIGSYS问题 ​
前言 作者习惯使用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.1K0
[x86][QEMU]虚拟化场景下的CPU拓扑
前言 目前的主流服务器一般是二路,即有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.6K0
[linux][atop]atop的改进和在统计io上遇到的问题
前言 互联网公司一般都会运行着几千到几万的服务器。一般的监控会采用类似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
2K0
点击加载更多
社区活动
Python精品学习库
代码在线跑,知识轻松学
【玩转EdgeOne】征文进行中
限时免费体验,发文即有奖~
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
技术创作特训营·精选知识专栏
往期视频·干货材料·成员作品·最新动态
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档