记5.28大促压测的性能优化—线程池相关问题

目录:

1.环境介绍

2.症状

3.诊断

4.结论

5.解决

6.对比java实现

废话就不多说了,本文分享下博主在5.28大促压测期间解决的一个性能问题,觉得这个还是比较有意思的,值得总结拿出来分享下。

博主所服务的部门是作为公共业务平台,公共业务平台支持上层所有业务系统(2C、UGC、直播等)。平台中核心之一的就是订单域相关服务,下单服务、查单服务、支付回调服务,当然结算页暂时还是我们负责,结算页负责承上启下进行下单、结算、跳支付中心。每次业务方进行大促期间平台都要进行一次常规压测,做到心里有底。

在压测的上半场,陆续的解决一些不是太奇怪的问题,定位到问题时间都在计划内。下单服务、查单服务、结算页都顺利压测通过。但是到了支付回调服务压测的时候,有个奇怪的问题出现了。

1.环境介绍

我们每年基本两次大促,5.28、双12。两次大促期间相隔时间也就只有半年左右,所以每次大促压测都会心里有点低,基本就是摸底检查下。因为之前的压测性能在这半年期间一般不会出现太大的性能问题。这前提是因为我们每次发布重大的项目的时候都会进行性能压测,所以压测慢慢变得常规化、自动化,遗漏的性能问题应该不会太多。性能指标其实在平时就关注了,而不是大促才来临时抱佛脚,那样其实为时已晚,只能拆东墙补西墙。

应用服务器配置,物理机、32core、168g、千兆网卡、压测网络带宽千兆、IIS 7.5、.NET 4.0,这台压测服务器还是很强的。

我们本地会用JMeter进行问题排查。由于这篇文章不是讲怎么做性能压测的,所以其他跟本篇文章关系的不大的情况就不介绍了。包括压测网络隔离、压测机器的配置和节点数等。

我们的要求,顶层服务在200并发下,平均响应时间不能超过50毫秒,TPS要到3000左右。一级服务,也就是最底层服务的要求更高,商品系统、促销系统、卡券系统平均响应时间基本保持在20毫秒以内才能接受。因为一级服务的响应速度直接决定了上层服务的响应速度,这里还要去掉一些其他的调用开销。 

2.症状

这个性能问题的症状还是比较奇怪的,情况是这样的:200并发、2000loop,40w的调用量。一开始前几秒速度是比较快的,基本上TPS到了2500左右。服务器的CPU也到了60左右,还是比较正常的,但是几秒过后处理速度陡降,TPS慢慢在往下掉。从服务器的监控中发现,服务器的CPU是0%消耗。这很吓人,怎么突然不处理了。TPS掉到100多了,显然会一直掉下去。等了大概不到4分钟,一下子CPU又上来了。TPS可以到2000左右。

我们仔细分析查看,首先JMeter的吞吐量的问题,吞吐量是按照你的请求平均响应时间计算的,所以这里看起来TPS是慢慢在减慢其实已经基本停止了。如果你的平均响应时间为20毫秒,那么在单位时间内你的吞吐量是基本可以计算出来的。

症状主要就是这样的,我们接下来对它进行诊断。

3.诊断

开始通过走查代码,看能不能发现点什么。

这是支付回调服务,代码的前后没有太多的业务处理,鉴权检查、订单支付状态修改、触发支付完成事件、调用配送、周边业务通知(这里有一部分需要兼容老代码、老接口)。我们首先主要是查看对外依赖的部分,发现有redis读写的代码,就将redis的部分代码注释掉在进行压测试试看。结果一下子就正常了,这就比较奇怪了,redis是我们其他压测服务共用的,之前压测怎么没有问题。没管那么多了,可能是代码的执行序列不同,在并发领域里面,这也说得通。

我们再通过打印redis执行的时间,看处理需要多久。结果显示,处理速度不均匀,前面的很快,后面的时间都在5-6秒,虽然不均匀但是很有规律。

所以我们都认为是redis的相关问题,就开始一头扎进去检查redis的问题了。开始对redis进行检查,首先是开启Wireshark TCP连接监控,检查链路、redis服务器的Slowlog查看处理时间。redis客户端库的源代码查看(redis客户端排除原生的StackExhange.Redis的有两层封装,一共三层),重点关注有锁的地方和thread wait的地方。同时排查网络问题,再进行压测的时候ping redis服务器看是否有延迟。(此时是晚上21点左右,这个时候的大脑情况大家都懂的。)

就是这样地毯式的搜查,以为是肯定能定位到问题。但是我们却忽视了代码的层次结构,一下子专到了太细节的地方,忽视了整体的架构(指开发架构,因为代码不是我们写的,对代码周边情况不是太了解)。

先看redis服务器的建立情况,tcp抓包查看,连接建立正常,没有丢包,速度也很快。redis的处理速度也没问题,slowlog查看基本get key也就1毫秒不到。(这里需要注意,redis的处理时间还包括队列里等待的时间。slowlog只能看到redis处理的时间,看不到blocking的时间,这里面还包括redis的command在客户端队列的时间。)

所以打印出来的redis处理时间很慢,不纯粹是redis服务器的处理时间,中间有几个环节需要排查的。

经过一番折腾,排查,问题没定位到,已是深夜,精力严重不足了,也要到地铁最后一班车发车时间了,再不走赶不上了,下班回家,上到最后一班地铁没耽误三分钟~~。

重整思路,第二天继续排查。

我们定位到redis客户端的连接是可以先预热的,在global application_begin启动的时候先预热好,然后性能一下子也正常了。

范围进一步缩小,问题出在连接上,这里我们又反思了(一夜觉睡过了,脑子清醒了),那为什么我们之前的压测没出现过这个问题。对技术狂热爱好的我们,哪能善罢甘休。此时问题算是解决了,但是背后所涉及到的相关线索穿不起来,总是不太舒服。(中场休息片刻,已是第二天的下午快傍晚了~~。)技术人员要有这种征服欲,必须搞清楚。

我们开始还原现场,然后开始出大招,开始dump进程文件,分不同的时间段,抓取了几份dump文件down到本地进行分析。

首先查看了线程情况,!runaway,发现大多数线程执行时间都有点长。接着切换到某个线程中~xxs,查看线程调用堆栈。发现在等一把monitor锁。同时切换到其他几个线程中查看下是不是都在等待这把锁。结果确实都在等这把锁。

结论,发现一半的线程都在等待moniter监视器锁,随着时间增加,是不是都在等待这把锁。这比较奇怪。

这把锁是redis库的第三层封装的时候用来lock获取redis connectioin时候用的。我们直接注释掉这把锁,继续压测继续dump,然后又发现一把monitor,这把锁是StackExchange.Redis中的,代码一时半会无法消化,只查了主体代码和周边代码情况,没有时间查看全局情况。(因为时间紧迫)。暂且完全信任第三方库,然后查看redis connection string 的各个参数,是不是可以调整超时时间、连接池大小等。但是还是未能解决。

回过头继续查看dump,查看了下CLR连接池,!ThreadPool,一下子看到问题了。

继续查看其他几个dump文件,Idle都是0,也就是说CLR线程池没有线程来处理请求了,至少CLR线程池的创建速率和并发速率不匹配了。

CLR线程池的创建速率一般是1秒2个线程,线程池的创建速率是否存在滑动时间不太清楚。线程池的大小可以通过 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config 配置来设置,默认是自动配置的。最小的线程数一般是当前机器的CPU 核数。当然你也可以通过ThreadPool相关方法来设置,ThreadPool.SetMaxThreads(), ThreadPool.SetMinThreads()。

然后我们继续排查代码,发现代码中有用Action的委托的地方,而这个Action是处理异步代码的,上面说的redis的读写都在这个Action里面的。一下我们明白了,所有的线索都连起来了。

4.结论

.NET CLR线程池是共享线程池,也就是说ASP.NET、委托、Task背后都是一个线程池在处理。线程池分为两种,Request线程池、IOCP线程池(完成端口线程池)。

我们现在理下线索:

1.从最开始的JMeter压测吞吐量慢慢变低是个假象,而此时处理已经全面停止,服务器的CPU处理为0%。肉眼看起来变慢是因为请求延迟时间增加了。

2.redis的TCP链路没问题,Wireshark查看没有任何异常、Slowlog没有问题、redis的key comnand慢是因为blocking住了。

3.其他服务压测之所有没问题是因为我们是同步调用redis,当首次TCP连接建立之后速度会上来。

4.Action看起来速度是上去了,但是所有的Action都是CLR线程池中的线程,看起来快是因为还没有到CLR线程池的瓶颈。

Action asyncAction = () => 
           { 
               //读写redis 
               //发送邮件 
               //...

           };

asyncAction.BeginInvoke();

5.JMeter压测的时候没有延迟,在压测的时候程序没有预热,导致所有的东西需要初始化,IIS、.NET等。这些都会让第一次看起来很快,然后慢慢下降的错觉。

总结:首次建立TCP连接是需要时间的,此时并发过大,所有的线程在wait,wait之后CPU会将这些线程交换出去,此时是明显的所线程上下文切换过程,是一部分开销。当CLR线程池的线程全部耗光吞吐量开始陡降。每次调用其实是开启力了两个线程,一个处理请求的Request,还有一个是Action委托线程。当你以为线程还够的时候,其实线程池已经满了。

5.解决

针对这个问题我们进行了队列化处理。相当于在CLR线程池基础上抽象一个工作队列出来,然后队列的消费线程控制在一定数量之内,初始化的时候默认一个线程,会提供接口创建顶多6个线程。这样当队列的处理速度跟不上的时候可以调用。大致代码如下(已进行适当的修改,非源码模样,仅供参考):

Service 部分:

private static readonly ConcurrentQueue<NoticeParamEntity> AsyncNotifyPayQueue = new ConcurrentQueue<NoticeParamEntity>(); 
private static int _workThread;

static ChangeOrderService() 
{ 
    StartWorkThread(); 
}

public static int GetPayNoticQueueCount() 
{ 
    return AsyncNotifyPayQueue.Count; 
}

public static int StartWorkThread() 
{ 
    if (_workThread > 5) return _workThread;

    ThreadPool.QueueUserWorkItem(WaitCallbackImpl); 
    _workThread += 1;

    return _workThread;; 
}

public static void WaitCallbackImpl(object state) 
{ 
    while (true) 
    { 
        try 
         { 
            PayNoticeParamEntity payParam; 
            AsyncNotifyPayQueue.TryDequeue(out payParam);

            if (payParam == null) 
            { 
                Thread.Sleep(5000); 
                continue; 
            }

            //获取订单详情

            //结转分摊

            //发短信

            //发送消息

            //配送 
        } 
        catch (Exception exception) 
        { 
            //log 
        } 
    } 
}

原来调用的地方直接改成入队列:

private void AsyncNotifyPayCompleted(NoticeParamEntity payNoticeParam) 
{ 
    AsyncNotifyPayQueue.Enqueue(payNoticeParam); 
}

Controller 代码:

public class WorkQueueController : ApiController 
    { 
        [Route("worker/server_work_queue")] 
        [HttpGet] 
        public HttpResponseMessage GetServerWorkQueue() 
        { 
            var payNoticCount = ChangeOrderService.GetPayNoticQueueCount();

            var result = new HttpResponseMessage() 
            { 
                Content = new StringContent(payNoticCount.ToString(), Encoding.UTF8, "application/json") 
            };

            return result; 
        }

        [Route("worker/start-work-thread")] 
        [HttpGet] 
        public HttpResponseMessage StartWorkThread() 
        { 
            var count = ChangeOrderService.StartWorkThread();

            var result = new HttpResponseMessage() 
             { 
                Content = new StringContent(count.ToString(), Encoding.UTF8, "application/json") 
            };

            return result; 
        } 
    }

上述代码是未经过抽象封装的,仅供参考。思路是不变的,将线程利用率最大化,延迟任务无需占用过多线程,将CPU密集型和IO密集型分开。让速度不匹配的动作分开。

优化后的TPS可以到7000,比原来快近三倍。

6.对比JAVA实现

这个问题其实如果在JAVA里也许不太容易出现,JAVA的线程池功能是比较强大的,并发库比较丰富。在JAVA里两行代码就可以搞定了。

ExecutorService fiexdExecutorService = Executors.newFixedThreadPool(Thread_count);

直接构造一个指定数量的线程池,当然我们也可以设置线程池的队列类型、大小、包括队列满了之后、线程池满了之后的拒绝策略。这些用起来还是比较方便的。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏哲学驱动设计

“秒杀”心得

    本文记录对某网站A的秒杀活动编写秒杀器的经历和技术重点。 故事回顾     某日早上,朋友给我说最近A网站在开展秒杀活动,有IPad、IPhone,让大...

2908
来自专栏Gaussic

淘宝开放平台API开发(一) 原

       淘宝官方为应用开发者提供了一套很好的API,开发是只要调用它的API接口就可以获取相应的数据。笔者现正从事Java Web开发,因而就淘宝API调...

1192
来自专栏极客生活

七种武器之一口箱子Redis

江湖传言「在任何规模、任何类型的服务器项目中,都存在一些最适合用Redis存储的数据。」

932
来自专栏移动端周边技术扩展

移动端常用数据库

2664
来自专栏Java帮帮-微信公众号-技术文章全总结

基于Redis实现分布式锁-Redisson使用及源码分析【面试+工作】

在分布式场景下,有很多种情况都需要实现最终一致性。在设计远程上下文的领域事件的时候,为了保证最终一致性,在通过领域事件进行通讯的方式中,可以共享存储(领域模型和...

8832
来自专栏coding

这一次,真正掌握composercomposer是现代PHP的基石初识composercomposer包管理规范

现代高级编程语言,依赖管理工具是必不可少的。Java有Maven,Python有pip,Nodejs有npm, 而在composer出现之前,PHP只有被广为诟...

1862
来自专栏Java帮帮-微信公众号-技术文章全总结

java中调用web service接口

1.首先要把AXIS包里的jar文件放到java项目的lib目录下,这里用的是AXIS1_4版本

1982
来自专栏京东技术

多级缓存设计详解 | 给数据库减负,刻不容缓!

物流研发部架构师,GIS技术部负责人,2012年加入京东,多年一线团队大促备战经验,负责物流研发一些部门的架构工作,专注于低延迟系统设计与海量数据处理。曾负责青...

3355
来自专栏小狼的世界

提高Mac下itunes的下载速度

给老婆买了iPhone4s之后,开始在Mac上用iTunes下载软件,发现速度龟速,好歹家里也是10M光纤啊,这个小水管的下载速度绝对不能忍受,于是百度了一下,...

1172
来自专栏VMCloud

【解析向】腾讯云的Windows Server日志配置收集工具是个什么鬼?(5)

且听笔者一句劝,无论是Windows还是Linux抑或是Unix都是大部分理论是相同的,与其与人争吵对比这几个平台之类的差异,不如好好研究下底层的各个子系统...

2477

扫码关注云+社区

领取腾讯云代金券