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

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

皮振伟的专栏

专栏作者

108

文章

297225

阅读量

78

订阅数

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

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

2020-06-28

4.4K0

[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

1.9K0

[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

2.9K0

[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.6K0

[linux][kvm]模拟大量虚拟机遇到的问题

kernel 缓存虚拟化 node.js

前言：网络的同事希望模拟大量的虚拟机（万台数量级），又受到物理资源的限制，只能使用几台物理机。遇到了各种奇奇怪怪的问题。分析：

2019-05-06

1.3K0

没有更多了

社区活动

腾讯技术创作狂欢月

“码”上创作 21 天，分 10000 元奖品池！

Python精品学习库

代码在线跑，知识轻松学

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

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

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

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