分析师之路：基础（系统：内存）

 内存这块对分析系统瓶颈很重要，但容易忽略，同时发现次问题一般都是用加内存的方式来解决。但是分析内存到位的话，是一个非常有意义的活动。开头我会用C++的角度来从测试角度谈论内存，最后拿其与python做对比。在C++中，内存分成5个区，他们分别是堆、栈、自由存储区、全局/静态存储区和常量存储区。这里主讲堆。堆就是那些由new分配的内存块，他们的释放编译器不去管，由我们的应用程序去控制，一般一个new就要对应一个delete。

一般程序开发的时候人工干预最多的是堆。对于堆来讲，频繁的new/delete势必会造成内存空间的不连续，从而造成大量的碎片，使程序效率降低。我就响应时间这个性能指标来分析CPU和内存瓶颈的表现，大量的创造并发线程去给服务器施加压力，在服务端还有客户端群所创建的线程都是上3000个，由于测试机有10个，所以这些线程的效率非常高，基本没因为客户端的cpu拖后腿。此时发现这个服务器cpu占用率飙高，在局域网状态好的情况下，达到了危险区85%占用率。但是内存并没有增长，同时响应时间也没有慢多少。这个性能的测试让我发现了句柄数少的情况下，即使cpu的处理事务非常多，也不会让计算机感觉响应很慢。后来我换一种测法，用3台客户端用创建socket的方式但是不疯狂的发包，仅仅是一个线程一直创建socket，然后一个线程创建一个列表对socket句柄逐个发心跳，一直循环。大概创建几w个句柄后，出现了很多连接失败（因为linux打开限制我没开得很狠），发现从一个没做测试的客户端去测试服务器的响应时间比之前的测试慢了不少。同时每台客户端到达自己极限的时候，几乎到了死机状态。

所以在不同测试手法比较起来，各有观察点。而在第二个测试的基础上，我专门做了异常断开测试，造就出一些释放内存和重新申请内存的动作。结果也比前2次测试内存使用率提高和响应时间更长。从这种进程级的测试我们可以发现了一个话题：内存泄露。对于堆来讲，频繁的new/delete势必会造成内存空间的不连续，从而造成大量的碎片，使程序效率降低。堆内存是指程序从堆中分配的，大小任意的，使用完后必须显示释放的内存。应用程序一般使用malloc，realloc，new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则，这块内存就不能被再次使用。但是我们从性能测试结果或者测试的日志要第一时间分析出是内存泄露是比较难的，通过标准的定位流程也只是排除法，因为内存泄漏在一般的应用中也会伴随cpu资源耗尽，io等问题，基本在我的几个性能项目中，找出内存泄漏的bug都会跟开发2～3次确认才能定下，因为检测内存泄漏的关键是要能截获住对分配内存和释放内存的函数的调用，这是对测试人员还是比较难的。毕竟性能和自动化不能像白盒那样直面源代码。

另外一种问题我一般在和同行分析一些奇怪的bug时会发现一些表面看不出问题的错误，通常这些错误表现会误导我们是逻辑错误，后来发现是堆栈混乱使用造成，C++/C程序中，指针和数组在不少地方可以相互替换着用，让人产生一种错觉，在结构体等地方混着用会出现一些不是我们想要的结果。当然这个范畴已经不是我们测试这边解决的。

最后谈下脚本语言。Python在运行期间会大量地执行malloc和free的操作，频繁地在用户态和核心态之间进行切换，这将严重影响Python的执行效率。虽然python引入了一个内存池机制和很多拓展的东西来提升效率，但是因为它帮我们自动做了很多东西，付出的代价就是执行效率。这点很重要，虽然长期我们测试都是用分析和比较的数据手段来分析系统瓶颈，但是我投身项目发现很多次用一种编程语言的执行来模拟另外一种语言编写的场景来测试性能，这里经常出现错误。你测试代码测的是哪个语言的效率，你想要测的是性能是哪个阶段？指标？负载？压力？还是确切数据？这些问题简单但是都在很漂亮的趋势图下埋没了。

最后总结：内存对我分析系统时带来很多难题，内存泄漏，逻辑，脚本模拟产品效率，还有对服务器硬件配置和操作系统配置的评测，都是不小的挑战，也是我技术能力的一个大瓶颈。