某年某月某日，一个工程师跑来找我说：很多用户抱怨APP频繁闪退，他觉得server运行正常，找不出原因，请我帮忙
按照流程一路排查下去，发现nginx访问日志里面有大量的http 504 err code
tail -f /var/log/messages
同时出现大量的类似错误信息
nginx[1234]: segfault at 0000000000000008 rip 000000000043edf8 rsp 00007fff34a21fa0 error 4
出现segfault那只能用gdb了，这也是Linux做server的好处了，换成微软平台，无比的麻烦
解决问题分成4步：
-
配置系统生成coredump文件，很简单
ulimit -a
第一行就是关于core file的设置，默认是不生成coredump文件的，执行
ulimit -c 1024
即可，记得调试完成之后要用
ulimit -c 0
关闭，不然你的硬盘很快会被填满
-
gdb调试，需要debug版本的nginx才能定位到源代码，于是需要重新编译一份nginx
首先把现有的nginx bin目录和conf目录都备份
然后打印nginx的原始编译选项
/opt/nginx/sbin/nginx -V
在这个基础上加上 --with-debug,重新make一份即可
在${NGINX-SOURCE-DIR}$/objs 目录中找到编译好的nginx ，复制到你的nginx运行目录，切记不要make install ，因为这样会覆盖掉你的nginx.conf文件
-
重新运行nginx，等待core.xxx文件生成。一般是在当前目录下生成
-
用gdb加载 coredump 文件
gdb --core=core.xxx
gdb> where
很容易就找到了nginx segfault的原因：我们自己写的一个nginx modules里面，对某些参数没有做边界检查，但外部环境变化之后，访问空指针了
转自：
http://lutaf.com/140.htm
提供给我的页面内网域名（inter.xxxx.xxxx）从1月1日中午开始陆陆续续有
nginx
499 链接断开的告警，12月30日有过类似问题的发生，但是只
出
现了几次。
当时排查问题
原因
以为是机器内存过小导致，因为线上机器中只有一台机器是8G 而正好是告警的业务机器，就替换16G内存机器。这个错误的决定也导致了后面问题的再次发生，因为我们的JVM参数中配置的JVM大小是4G，机器内存8G。
1月1号11点左右
nginx
告警不断，由于新版...
# dmesg[139503.905960] a.out[85431]: segfault at 1458 ip 0000000000400ad0 sp 00007ffd2b619100 error 6 in a.out[400000+2000]# cat /var/log/messages | grep segfaultJul 6 21:54:20 localhost kernel: a.ou...
1.打开CoreDump功能ulimit -c unlimitedulimit unlimitedulimit -c2.修改CoreDump存储路径（其中mount_dir为存放路径）echo $mount_dir/core.%e.%p > /proc/sys/kernel/core_pattern
最近在学习
gdb
调试
coredump，看到一篇非常棒的文章，忍不住转载到自己的博客下，感兴趣的同学可以直接去原博客查看~
gdb
调试
coredump(使用篇)
一、什么是coredump
Coredump叫做核心转储，它是进程运行时在突然
崩溃
的那一刻的一个内存快照。操作系统在程序发生异常而异常在进程内部又没有被捕获的情况下，会把进程此刻内存、寄存器状态、运行堆栈等信息转储保存在一个文件里。
该文件也是二进制文件，可以使用
gdb
、elfdump、objdump或者windows下的windebug、solar
有一台阿里云上的服务器，上一任运维留下来的，里面装了
nginx
1.10.2 ，还开启了iptables。之前一直都是相安无事，内存占用率稳定达到85%-90%，cpu占用率偶尔达到50%，一般在10%以下。
突然一天，发现
nginx
设置跳转的域名无法连接，观察内存，cpu都没问题，连接数也正常，由于能力有限，因此也未进入查看内核方面的情况，只是做了些紧急措施，将重要的域...
最近在上线项目的过程中遇到由于一个请求大量查询数据库，导致生产系统宕机。后期在把开发、dba、运维都拉在一起开会讨论时，按dba提供的数据库配置 性能后都无法相信这个请求会导致数据库宕机。后面重新复盘，在执行一次这个请求后仔细排查执行过程，才发现是由于
nginx
自带的请求故障转移导致了这次的宕机。
我们系统是采用
nginx
作为负载均衡工具，负责转发请求到后端的应用节点。
nginx
有一个故障请求重试的机制。在后端节点请求超时时会把该请求自动转发到下一个节点，如果下一个节点返回结果则将该结果返回给用户..
