c++服务器开发之性能优化

为什么要写这篇文章？

聊技术的时候，谈到内存问题、CPU问题、效率问题的时候，无疑是考量一个工程师的实战水平，作为c++开发工程师，没有自己解决以上问题的专业手段，或许就是缺陷。我之所以写这个文章，主要是为了记录、分享我的办法。我之前写过内存泄漏的一篇文章（https://blog.csdn.net/yl175510/article/details/107384317），其实也是一种手段，如果为你所用，聊技术的时候绝对可以加分。

之前一个同事在线上出问题的时候，竟然用gdb和valgrind去调试，当时问题就大了，服务器骤停，其他人员无法使用，也没法调试。那么这就是手段不对。

内存问题

在这里我很准确的说，内存泄漏没办法跟踪，只能靠日志、代码走查、提前避免、猜测等手段处理。

在写完代码，自测期间，除了使用gdb单步调试，这里介绍两种工具：

1、valgrind

valgrind本身的CPU消耗比较大，大部分内存问题都能解决，常用命令是

valgrind  --leak-check=yes ./a.out

2、strace 

strace主要跟踪系统调用的情况，说实话，不是很常用，但有时候不能不用，因为谁也不知道系统是不是因为“系统调用”的开销造成的问题。常用命令如下：

strace -o output.txt -T -tt -e trace=all -p 12345

当然，linux内核还实现了很多探针。dstrace就是一种。

 

3、mstrace

这个函数主要跟踪malloc与free的对应情况，需要编程，加入代码，Linux提供mtrace和muntrace两个函数。在查找内存问题上，能知道个写泄漏情况的大概。

 

4、addresssanitizer

是一个快速的内存错误检测工具。它非常快，只拖慢程序两倍左右（比起Valgrind快多了）。它包括一个编译器instrumentation模块和一个提供malloc()/free()替代项的运行时库。具体使用命令在官网能查到。

 

CPU问题

关于CPU的使用情况。很多时候不知道怎么去定位，线上CPU 百分之百的时候显得很棘手，其实是有工具的。

 

Perf、火焰图

Perf是Linux 2.6+内核中的工具，在linux源码的 tools/perf里，编译安装就行.

perf利用Linux的trace特性，可以用于实时跟踪，统计event计数(perf stat)；或者使用采样(perf record)，报告(perfreport|script|annotate)的使用方式进行诊断。

 

火焰图看起来就像一团跳动的火焰，燃烧在火苗尖部的就是 CPU 正在执行的操作，不过需要说明的是颜色是随机的，本身并没有特殊的含义。

纵向表示调用栈的深度，横向表示消耗的时间。因为调用栈在横向会按照字母排序，并且同样的调用栈会做合并，所以，一个格子的宽度越大越说明其可能是瓶颈。

综上所述，主要就是看那些比较宽大的火苗，特别留意那些类似平顶山的火苗。

 

 

效率问题

其实这个问题特别广，效率也就是程序快慢问题。

同步与异步的问题一直的很重要的，linux中没有很有好的异步支持，但是强大的epoll让我们很轻松的实现非阻塞，reactor设计模式，让性能不再受多线程亦或多进程的弊端限制。

其实我们很难绕开多线程和多进程，因为要实现并发，像现在c++引入协程库，其实也是为了解决效率问题和高并发的瓶颈。服务器开发目前很多能用golang语言解决的，绝对不会使用c++，因为golang已经解决了多线程的弊端，自带协程框架。

聊效率问题，本人大致总结以下几点

1、代码设计

redis与memcached的对比，就是单线程的reactor与多线程的的对比。所以说程序的架构特别重要。实战中一定要结合业务。

除了代码架构，开源库的选择也很重要啊，高性能中间件（如redis、nginx、memcached、libevent、zmq），使用c/c++编写。选择开源库，也是要看编程语言属性的。

2、内存问题

高性能的服务，一定要基于内存去考虑，redis完全基于内存，所以单线程模式也很快呀。

内存也有瓶颈的，4g的RAM,能开多少线程（单个10M）？那用个内存池怎么样？我认为nginx的内存池可以一学。

3、服务器的耦合性

所有服务部署到一台机器？高耦合，必然对日志、维护、问题排查造成影响，不知道哪天宕机，恐怖如斯，还是一个服务一台机器吧。