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

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

皮振伟的专栏

专栏成员

108

文章

312967

阅读量

79

订阅数

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

linux 云计算

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

2022-04-27

8570

[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][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虚拟化的混合部署

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][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.1K0

[linux][block]readahead导致的md-raid1读速度慢问题

http linux 打包

前言为了提高虚拟机的网盘的高科用，同时挂载了两块，在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嵌套导致的问题

gcc linux https github 网络安全

使用tgt-1.0.75创建好target之后，在initiator端执行login操作大约卡3s～5s左右。同时观察tgt，CPU消耗到达100%。

2019-05-06

1.6K0

[x86][kvm]avx512指令相关

kvm linux grep kernel http

前文《[x86][linux]AVX512指令引起的进程crash》中，介绍了一次因为avx512指令导致的进程crash。

2018-10-23

5.2K0

[linux][nginx]nginx的graceful shutdown和worker shutdown timeout

linux nginx kernel git

前言：某大佬问作者，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] 物理内存管理

node.js linux kernel

前言：书接上回《内存映射技术分析》，继续来分析一下linux的物理内存管理。分析： 1，物理内存 PC上的内存条，或者手机上的内存芯片，物理上实实在在的内存，就是物理内存。大小是硬件决定的，一般就是一个起始地址，加上大小。地址如何分配呢？PC上作者也不太懂，听闻BIOS可以配置。在ARM上，作者曾经看过一份电路图，当时的图上，使用32bit的高2bit作为chip select，后面的30bit作为地址总线，看过chip select信号之后，作者才明白为什么在代码上要配置起始的地址不是0，因为硬件

2018-04-09

2.7K0

[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精品学习库

代码在线跑，知识轻松学

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

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

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

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