针对nginx，大胆利用调试信息来部署应用（去掉优化参数）

       在高并发情况下，nginx程序有时候会遇到偶然的进程崩溃，这些bug在测试的过程中又往往不能够或者很难重现，导致调试非常困难。

       有些人说，用输出log的方式，但这种方式并不一定适用，有些问题是无法输出到log中去的，即使有，往往信息又很少。

       最佳的方式就是保留程序崩溃时的现场，就像保留事故现场信息一样。linux环境下，可以利用core文件，但产生有用的core文件又必须要有调试信 息，而且不加优化(例如-O2 -O)。由于nginx一般只有几个进程，每个进程一般所占的虚拟内存又不大，所以产生core文件非常理想，不像apache往往虚拟内存非常大，进程 崩溃往往产生很大的core文件，而且往往core文件还很多，导致磁盘很快就被用完。很多人也许会反对编译的时候加-g，认为会影响性能，根据我的对比 测试和上线经验，针对nginx，影响的性能很有限，当然具体项目要具体分析，不过对于大部分项目我觉得还是可行的。我们上线的广告投放程序编译的时候就 加上了-g，一直运行到今天，广告投放系统高峰的时候每秒处理2万个请求，每台机器处理大概3千左右，根据access log分析，95%以上请求处理的时间（nginx内部处理的时间，只统计到毫秒）都小于1毫秒，所以在nginx环境下，加调试信息在某些场合是非常适 合的。

      通过加-g，去掉优化参数，执行的时候加上ulimit -c unlimited，我们发现了若干个很难发现的bug，受益匪浅。

      所以我建议nginx程序加-g，并去掉优化参数。