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

皮振伟的专栏

专栏成员
108
文章
312626
阅读量
79
订阅数
[linux][irq]irqtop支持-C/--cpu-list
在前文《[linux][irq]中断性能监控工具irqtop和lsirq》中介绍了irqtop和lsirq两条命令,用来观察系统的中断信息和增量变化。
皮振伟
2022-04-27
8530
[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和吞吐
前言 在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][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.8K0
[Linux][mm]watermark_scale_factor的调整以及遇到的问题
在较高的Linux版本上,支持了watermark_scale_factor参数(完整路径/proc/sys/vm/watermark_scale_factor)调整,这个数值可以比较有效的控制内存回收。
皮振伟
2020-06-28
5.4K0
[linux][irq]中断性能监控工具irqtop和lsirq
目前的主流服务器都拥有较多的CPU,2 NUMA node情况下,打开HyperThread,CPU数量通常都在40、64、96、128、192、256左右。
皮振伟
2020-03-18
3.9K0
基于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
2K0
[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
2.1K0
[linux][block]readahead导致的md-raid1读速度慢问题
前言 为了提高虚拟机的网盘的高科用,同时挂载了两块,在Guest内部使用RAID1,如果后端一块发生故障,可以保证在10s内failover,恢复业务运行。当前的配置是把RAID1的md设备格式化成ext4文件系统,挂载后使用。 atop每天大约生成了200M+的文件,文件在md设备上。发现在查看atop文件的时候,耗时很长,大约估计需要30s。 分析 1,使用filemap分析文件的物理分布 首先怀疑是ext4的文件在物理分布上的情况,有可能是比较零碎,会导致读消耗更高的IOPS。 作者写过一个工具,用来dump出来文件的物理layout情况,代码路径: https://github.com/pacepi/tool/blob/master/filemap.c 编译后执行,
皮振伟
2019-05-06
1.7K0
[gcc][glibc]va_start嵌套导致的问题
使用tgt-1.0.75创建好target之后,在initiator端执行login操作大约卡3s~5s左右。同时观察tgt,CPU消耗到达100%。
皮振伟
2019-05-06
1.6K0
[x86][kvm]avx512指令相关
前文《[x86][linux]AVX512指令引起的进程crash》中,介绍了一次因为avx512指令导致的进程crash。
皮振伟
2018-10-23
5.2K0
[linux][nginx]nginx的graceful shutdown和worker shutdown timeout
前言: 某大佬问作者,nginx做proxy的时候,重新加载配置的时候,会不会影响已有的连接? 作者基于too young too simple的认知:client和proxy之间有established连接,proxy和upstream直接有established连接;重启proxy就以为着重新启动proxy worker进程,kernel在进程exit的试试,会关闭掉所有的fd(socket本身就是fd的一种),就会发生重新连接。。。 然而,作者还是用最新的nginx做了一下实验,nginx实力打脸!作者查了一下git log,大约有两个feature起的影响比较大:graceful shutdown和worker shutdown timeout 分析: 1,client – proxy – upstream环境
皮振伟
2018-07-23
3.6K0
​[kvm][qemu]vm exit的优化
前言: 减少vm exit的次数,提高虚拟机的性能。 本文对比几种场景,讨论kvm的性能优化方案。 本分方案中,host和guest都使用Linux4.4。相比更早的Linux版本,Linux4.4的虚拟化更加完善。如果有不了解的朋友,可以了解一下apicv技术,和相关的posted-interrupt和PV-EOI。 本文中,工具使用systemtap,获取到vm exit的reason和次数。 分析: 1,网卡虚拟化 初始条件: a,为了避免外部中断带来的干扰,把物理网卡的中断绑定到物理机的CPU0
皮振伟
2018-04-09
6.7K4
[linux][storage]Linux存储栈
前言: 随着Linux的版本升高,存储栈的复杂度也随着增加。作者在这里简单介绍目前Linux存储栈。 分析: 1,storage stack 在用户态,可以看到的磁盘主要有几种类型: a,/dev/
皮振伟
2018-04-09
5.3K0
[linux][network]net bridge技术分析
前言: 对于作者这种没有在通信设备方面工作经验的人来说,理解网桥还是挺困难的。 二层之上的数据处理,协议分层,都是相对容易一些(尽管TCP协议复杂的一塌糊涂),毕竟在linux的协议栈代码中,逻辑层次都很清晰。 然后网桥却不同,它是一个二层逻辑。同时,它又不是一个具体的设备(具体的设备,有连接的物理的port口,插入网线就能通数据)。 在虚拟化场景下,虚拟机需要发送、接受数据,和外部交互,就需要有这样的设备。所以有必要深入了解一下网桥的具体的工作原理。 分析: 1,concept 网上的很多说法,网桥类
皮振伟
2018-04-09
3.4K0
[linux][memory]balloon性能优化的几种方案分析
前言: Memory Balloon作为虚拟化平台上的一个重要内存QoS方案,作者在前文《[linux][memory]balloon技术分析 》中做过原理性的简要分析。 本篇介绍Memory Balloon的两种性能优化方案,进一步提升内存QoS性能。 第一种方案:在guest的balloon中填充page,再通知qemu使用madvise让host主动释放page。 第二种方案:在guest的balloon中填充page的同时,把page置零。提升host的ksm/uksm的合并效率。 分析: 1,
皮振伟
2018-04-09
1.8K0
[linux][kernel]虚拟机场景中获取Guest OS的log
前言: GuestOS中如果发生了一些错误,GuestOS还活着,shell已经hung住了,如何获取到GuestOS中的关键log信息呢? 分析: 1,keyboard interrupt QE
皮振伟
2018-04-09
1.3K0
[linux][memory] 物理内存管理
前言: 书接上回《内存映射技术分析》,继续来分析一下linux的物理内存管理。 分析: 1,物理内存 PC上的内存条,或者手机上的内存芯片,物理上实实在在的内存,就是物理内存。大小是硬件决定的,一般就是一个起始地址,加上大小。地址如何分配呢?PC上作者也不太懂,听闻BIOS可以配置。在ARM上,作者曾经看过一份电路图,当时的图上,使用32bit的高2bit作为chip select,后面的30bit作为地址总线,看过chip select信号之后,作者才明白为什么在代码上要配置起始的地址不是0,因为硬件
皮振伟
2018-04-09
2.6K0
[linux][memory] 内存回收
前言: 前文《内存映射技术分析》描述了虚拟内存的管理、内存映射;《物理内存管理》介绍了物理内存管理。 本篇介绍一下内存回收。内存回收应该是整个Linux的内存管理上最难理解的部分了。 分析: 1,PFRA Page Frame Reclaim Algorithm,Linux的内存回收算法。 不过,PFRA和常规的算法不同。比如说冒泡排序或者快速排序具有固定的时间复杂度和空间复杂度,代码怎么写都差不多。而PFRA则不然,它不是一个具体的算法,而是一个策略---什么样的情况下需要做内存回收,什么样的page
皮振伟
2018-04-09
3.3K0
[linux][virt]USB passthrough技术分析
前言: USB passthrough让作者疑惑了一番~ 分析: 1,xml 根据libvirt的官方文档:http://libvirt.org/formatdomain.html#element
皮振伟
2018-04-09
1.9K0
点击加载更多
社区活动
【纪录片】中国数据库前世今生
穿越半个世纪,探寻中国数据库50年的发展历程
Python精品学习库
代码在线跑,知识轻松学
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
技术创作特训营·精选知识专栏
往期视频·千货材料·成员作品 最新动态
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档