花钱的年华

江南白衣,公众号:春天的旁边

在你的代码之外,服务时延过长的三个追查方向(上)

| Filed under 技术

服务化体系里一般都有着严格的超时设定,为业务部门排查那些毛刺慢响应,也是基础架构部门的专家坐诊服务之一。

有时候,即使你的代码写的很努力了,但还是会出现慢响应,因为这本就是艰难的世界。 本文从三个方向上各举一些例子:

第一方面主要是热身,更加有趣的两方面见下集

 

第一方面,操作系统篇

准备知识《从Apache Kafka 重温文件高效读写》中Swap 和 PageCache的部分。

1. 禁用swap

Linux有个很怪的癖好,当内存不足时,看心情,有很大机率不是把用作IO缓存的Page Cache收回,而是把冷的应用内存page out到磁盘上(具体算法看准备知识)。当这段内存重新要被访问时,再把它重新page in回内存(所谓的主缺页错误),这个过程进程是停顿的。增长缓慢的老生代,池化的堆外内存,都可能被认为是冷内存,用 cat /proc/[pid]/status 看看 VmSwap的大小, 再dstat里看看监控page in发生的时间。

在 /etc/sysctl.conf 放入下面一句,基本可以杜绝swap。设成0会导致OOM,案例在此,有些同学就设成1,喜欢就好。

vm.swappiness = 10

 

2. 加快Page Cache Flush的频率

又是一个Linux自己的奇怪设置,Linux的Page Cache机制说来话长(还是看看准备知识), 简单说IO其实都默认不是先写磁盘,而是写进Page Cache内存,inode脏了30秒,或脏数据达到了10%可用内存(Free+PageCache -mmap),才开始起flusher线程写盘。

我们的生产机内存起码都剩20G的样子,想想要以普通硬盘100MB/s级别的速度,一次写2G文件的速度....好在一般都达不到这个条件,一般是由几个日志文件轮流30秒触发,一次写几百M,花个三秒左右的时间。

文章里说,后台刷盘线程不会阻塞应用程序的write(2)。但是,

应用的write 过程是这样的:
锁inode -> 锁page -> 写入page -> 解锁page -> 解锁inode -> 锁inode page -> 写inode page -> 解锁inode page

而flusher的过程是这样的:
锁page -> 将page放进IO队列,等待IO调度写盘完成返回 -> 解锁page

可见,还是有锁,IO调度器也不是绝对公平,当IO繁忙,应用还是会发生阻塞 。

我们的做法是用一个100MB的绝对值来代替可用内存百分比来作为阀值。

在 /etc/sysctl.conf 里加入

vm.dirty_background_bytes = 104857600

在第二篇举的JVM停顿的例子,全和IO相关,即使不做后面JVM的调优,光降低这个阀值,也能大大缓解。

当然什么值是最优,必须根据机器配置,应用特性来具体分析。

 

3. 网络参数

太多可配置的地方,可以参考阿里云团队的一个很好的文章 Linux TCP队列相关参数的总结。 还是那句,不能看着文章就开始设,必须根据自己的情况。

比如我们自己设置网卡软中断队列的CPU亲和度:

平时网卡中断可能只用一个核来响应,在大流量下那个核会跑满。
运行irqbalance,也只是用到了1个CPU,12个核。
最后自己设定24条网卡中断队列对应24个核,效果最佳。。。。。。但你的情况就不一定一样啊。

 
姑娘,漂亮:

有关的...

发表评论

您的电子邮箱不会被公开。

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>