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

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

皮振伟的专栏

专栏作者

108

文章

296961

阅读量

78

订阅数

[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

1.8K0

[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

9290

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

没有更多了

社区活动

腾讯技术创作狂欢月

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

Python精品学习库

代码在线跑，知识轻松学

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

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

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

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