这是2017年8月一篇内部博客文章的严重删节版本。有关Kafka的最新更新，请查看另一篇关于压缩的博客文章，其中我们优化了磁盘和网络的吞吐量4.5倍。Alex Povolyashko/Unsplash摄影将我们的系统升级到Debian Stretch相当长一段时间以来，我们一直在推出Debian Stretch，到目前为止，我们的核心数据中心的采用率已经达到10%。作为升级底层操作系统的一部分，我们还评估了更高级别的软件堆栈，例如，看看我们的ClickHouse和Kafka集群。在升级Kafka的过程中，我们成功地迁移了两个较小的集群，logs和dns，但是在尝试升级我们的一个较大的集群http时遇到了问题。值得庆幸的是，由于操作系统和更高级别的软件堆栈都有很高的版本控制，我们能够相对容易地回滚http集群升级。如果这篇博文有一个收获，那就是利用一致的版本控制。高水平差异我们升级了一个Kafka http节点，但没有按计划进行：拥有5倍的CPU使用率绝对是一个意想不到的结果。对于控制数据点，我们将其与未进行升级的节点和接收到软件堆栈升级而不是操作系统升级的中间节点进行了比较。这两个节点都没有遇到相同的CPU饱和问题，尽管它们的设置实际上是相同的。为了调试CPU饱和问题，我们调用perf来找出细节：使用的命令是：perf top-f99。RCU失速除了更高的系统CPU使用率之外，我们还发现了二级减速，包括读拷贝更新（RCU）暂停：[4909.110009]logfwdr（26887）使用的最大堆栈深度：剩余11544字节[4909.392659]oom_reaper:收获过程26861（logfwdr），现在继续-rss:8kB，文件-rss:0kB，施孟-rss:0kB[4923.462841]信息：rcu_sched在CPU上自我检测到暂停[4923.462843]13-…：（2个GPs在后面）空闲=ea7/14000000000001/0软IRQ=1/2 fqs=4198[4923.462845]（t=8403吉菲斯g=110722 c=110721 q=6440）我们以前见过RCU暂停，我们的（次优）解决方案是重新启动机器。然而，在问题变得严重到需要深入研究之前，一个人只能处理如此多的重启。在深入研究过程中，我们在dmesg中注意到，在尝试写入错误时，我们在分配内存时遇到了问题：8月15日21:51:35 myhost kernel:INFO:rcu sched检测到CPU/任务暂停：8月15日21:51:35我的主机内核：26-…：（1881勾选这个GP）idle=76f/14000000000000/0 softirq=8/8 fqs=3658月15日21:51:35我的主机内核：（由0检测，t=2102 jiffies，g=1837293，c=1837292，q=262）8月15日21:51:35我的主机内核：CPU 26的任务转储：8月15日21:51:35 myhost kernel:javar运行任务13488 1714 1513 0x000801888月15日21:51:35我的主机内核：ffffc9000d1f7898 ffffffff 814ee977 ffffff88103f410400 000000000000000 a8月15日21:51:35我的主机内核：000000000000041 ffffffff 82203142 ffc9000d1f78c0 ffffffff 814eea108月15日21:51:35我的主机内核：000000000000041 fffffffffff82203142 ff88103f410400 ffffc9000d1f79208月15日21:51:35 myhost内核：调用跟踪：8月15日21:51:35我的主机内核：[]？scrup+0x147/0x1608月15日21:51:35我的主机内核：[]？低频+0x80/0x908月15日21:51:35我的主机内核：[]？控制台打印+0x295/0x3c08月15日21:51:35我的主机内核：[]？呼叫控制台_驱动程序.isra.22.constprop.30+0xf3/0x1008月15日21:51:35我的主机内核：[]？控制台解锁+0x281/0x5508月15日21:51:35我的主机内核：[]？vprintk_发射+0x278/0x4308月15日21:51:35我的主机内核：[]？vprintk_默认值+0x1f/0x308月15日21:51:35我的主机内核：[]？打印K+0x48/0x508月15日21:51:35我的主机内核：[]？转储堆栈打印信息+0x7e/0xc08月15日21:51:35我的主机内核：[]？转储堆栈+0x44/0x658月15日21:51:35我的主机内核：[]？警告分配+0x124/0x1508月15日21:51:35我的主机内核：[]？__分配页\慢路径+0x932/0xb808月15日21:51:35我的主机内核：[]？__分配页\u节点掩码+0x202/0x2508月15日21:51:35我的主机内核：[]？分配页当前+0x92/0x1208月15日21:51:35我的主机内核：[]？__页面\u cache_alloc+0xbf/0xd08月15日21:51:35我的主机内核：[]？filemap_故障+0x2ea/0x4d08月15日21:51:35我的主机内核：[]？xfs_filemap_故障+0x45/0xa08月15日21:51:35我的主机内核：[]？__do_故障+0x6b/0xd08月15日21:51:35我的主机内核：[]？手柄故障+0xe98/0x12b08月15日21:51:35我的主机内核：[]？__seccomp_过滤器+0x1db/0x2908月15日21:51:35我的主机内核：[]？__do_page_故障+0x22c/0x4c08月15日21:51:35我的主机内核：[]？执行页面错误+0x20/0x708月15日21:51:35我的主机内核：[]？页面故障+0x22/0x30这表明我们记录了太多的错误，而实际的失败可能发生在这个过程的早期。有了这个假设，我们看到了错误链的最开始：8月16日01:14:51我的主机系统日志[13812]：遗漏了17171条内核消息8月16日01:14:51我的主机内核：[]收缩不活动的_list+0x1f4/0x4f08月16日01:14:51我的主机内核：[]收缩节点_memcg+0x5bb/0x7808月16日01:14:51我的主机内核：[]收缩节点+0xd2/0x2f08月16日01:14:51我的主机内核：[]是否尝试使用"免费"页面+0xef/0x3108月16日01:14:51我的主机内核：[]尝试使用"免费"页面+0xd5/0x1808月16日01:14:51我的主机内核：[]\u alloc_pages_slowpath+0x31b/0xb80尽管shrink_node可能会尖叫"NUMA问题"，但您主要关注的是：8月16日01:14:51我的主机系统日志[13812]：遗漏了17171条内核消息此外，我们还发现内存分配问题：[78972.506644]内存信息：[78972.506653]激活_anon:3936889非活动：371971隔离_无：0[78972.506653]激活_文件：25778474非活动_文件：1214478隔离_文件：2208[78972.506653]联合国可逐出：0脏：1760643个写回：0不稳定：0[78972.506653]楼板可索赔：1059804板坯不可索赔：141694号[78972.506653]制图：47285 shmem：535917便士年龄表：10298反弹：0[78972.506653]免费：202928免费：3085免费_cma:0[78972.506660]节点0处于活动状态_账号：8333016kB非活动账号：989808kB活动_文件：5062284KB非活动_文件：2401416kB联合国可逐出：0kB隔离（anon）：0kB隔离（文件）：3072kB映射：96624kB脏：3422168kB写回：0kB shmem：1261156kB shmem_thp:0kB shmem_pmdmapped:0kB anon_thp:0kB写回_tmp:0kB不稳定：0kB页_扫描：15744所有不可收回的？不[78972.506666]节点1活动_anon:7414540kB不活动：498076kB活动_文件：52491512kB非活动的_文件：2456496kB联合国可逐出：0kB隔离（anon）：0kB隔离（文件）：5760kB映射：92516kB脏：3620404kB写回：0kB shmem：882512kB shmem_thp:0kB shmem_pmdmapped:0kB anon_thp:0kB写回_tmp:0kB不稳定：0kB页_扫描：9080974所有不可收回的？不[78972.506671]节点0 DMA免费：最少15900kB：100kB低：124kB高：148kB活动_anon:0kB不活动：0kB激活_文件：0kB非活动\u文件：0kB联合国可收回：0kB writepending：0千字节存在：15996kB管理：15900kB锁定：0kB板可回收：0kB平板可索赔：0kB内核_堆栈：0千字节/秒年龄表：0kB反弹：0kB免费_pcp:0kB本地\pcp：0kB免费_cma:0kB**9个printk消息丢弃**[78972.506716]节点0正常：15336*4kB（UMEH）4584*8kB（MEH）2119*16kB（UME）775*32kB（MEH）106*64kB（UM）81*128kB（MH）29*256kB（UM）25*512kB（M）19*1024kB（M）7*2048kB（M）2*4096kB（M）=236080kB[78972.506725]节点1正常：31740*4kB（UMEH）3879*8kB（UMEH）873*16kB（UME）353*32kB（UM）286*64kB（UMH）62*128kB（UMH）28*256kB（MH）20*512kB（UMH）15*1024kB（UM）7*2048kB（UM）12*4096kB（M）=3057552KB[78972.506726]节点0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB[78972.506727]节点1 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB[78972.506728]共27531091页页面缓存[78972.506729]交换缓存中有0页[78972.506730]交换缓存状态：添加0、删除0、查找0/0[78972.506730]自由交换=0kB[78972.506731]总掉期=0kB[78972.506731]33524975页RAM[78972.506732]0页仅限HighMem/可移动[78972.506732]保留546255页[78972.62029]ntpd:页面分配暂停272380毫秒，顺序：0, 模式：0x24000c0（GFP_内核）[78972.620132]CPU:16 PID:13099通信：ntpd污染：G O 4.9.43-cloudflare-2017.8.4#1[78972.620133]硬件名称：Quanta Computer Inc D51B-2U（双1G LoM）/S2B-MB（双1G LoM），BIOS S2B U 3A21，2015年1月10日[78972.620136]ffffc90022f9b6f8 FFFFFF 8142D668 FFFFFF 81CA31B8 0000000000000001[78972.620138]ffffc90022f9b778 FFFFFF 81162F14 024000c022f9b740 FFFFFF 81CA31B8[78972.620140]FFFFC90022F9B7200000000000000010 FFC90022F9B788 FFC90022F9B738[78972.620140]呼叫跟踪：[78972.620148][]转储堆栈+0x4d/0x65[78972.620152][]警告分配+0x124/0x150[78972.620154][]分配页\慢路径+0x932/0xb80[78972.620157][]分配页\节点掩码+0x202/0x250[78972.620160][]分配页当前+0x92/0x120[78972.620162][]获取\u免费页面+0xe/0x40[78972.620165][]\uu pollwait+0x9a/0xe0[78972.620168][]数据报_poll+0x29/0x100[78972.620170][]插座轮询+0x48/0xa0[78972.620172][]选择+0x335/0x7b0这个特定的错误消息看起来确实很有趣：[78991.546088]系统网络：页面分配暂停287000毫秒，顺序：0, 模式：0x24200ca（可移动的高用户）你不希望你的页面分配暂停5分钟，特别是当它是零订单分配（最小分配一个4kib页面）。与我们的控制节点相比，只有两种可能的解释：内核升级，以及从Debian Jessie切换到Debian Stretch。我们怀疑前者，因为CPU使用率意味着内核问题。然而，为了安全起见，我们将两个内核都回滚到4.4.55，并将受影响的内核降级