早些天查看nginx的日志发现有这样的错误：
奇怪了这是php-cgi不够用啊！！！！
实际上我开启的php-cgi的数目远大于实际使用的数目。
查看php的日志查看到当时有大量的php-cgi进程重启（按照php-cgi的<value name="max_requests">102400</value>和当时的访问量不应该有这么多的php-cgi重启）。
查看系统日志：
大量的这样的记录日志，而且时间和nginx错误日志中记录的时间一样。
难道是redis出什么问题了，查看redis日志：“Can't re-open the VM swap file: redis.swap. Exiting.”；发现这个redis.swap文件被人删除了，移动redis的数据目录却没有重启redis；但是这个也应该也没有影响吧。先解决这个问题：创建redis.swap。
但是nginx的这个问题还是存在，查了大量的资料也还是没有解决这个问题（郁闷啊！！杯具啊。。。。。。）
过了几天后再看这个问题莫名其妙的没有了》》》什么都没有修改丫的为什么就没有了呢
最近在网络上搜索到一些这样的信息：
kernel : *** : segfault at 0000000000000011 rip 00000032f8670454 rsp 000000004128fd30 error 4
kernel: exp[24505]: segfault at 000000000000053c rip 00002abe2df39eb8 rsp 00007fff7d147290 error 4
这种信息一般都是由内存访问越界造成的，不管是用户态程序还是内核态程序访问越界都会出core, 并在系统日志里面输出一条这样的信息。
其中 kernel 后面的exp 代表程序名，[24505]进程ID号，
segfault at 000000000000053c rip 00002abe2df39eb8 rsp 00007fff7d147290 访问越界的地址以及当时进程堆栈地址等信息，最后的是error number.
在上面的信息中，error number是4 ,下面详细介绍一下error number的信息：
在上面的例子中，error number是4, 转成二进制就是100, 即bit2=1, bit1=0, bit0=0, 按照上面的解释，我们可以得出这条信息是由于用户态程序读操作访问越界造成的。
error number是由三个字位组成的，从高到底分别为bit2 bit1和bit0,所以它的取值范围是0~7.
bit2: 值为1表示是用户态程序内存访问越界，值为0表示是内核态程序内存访问越界
bit1: 值为1表示是写操作导致内存访问越界，值为0表示是读操作导致内存访问越界
bit0: 值为1表示没有足够的权限访问非法地址的内容，值为0表示访问的非法地址根本没有对应的页面，也就是无效地址
难道当时是我的内存不够用了，可是查看监控并没有出现这些的情况
后续：时隔几年才来把这个后续写上，也是懒的可以啦，哈哈哈
我的这个问题错误代码是4， 即bit2=1, bit1=0, bit0=0对应的错误信息就是‘用户态程序内存访问越界’-‘读操作导致内存访问越界’-‘问的非法地址根本没有对应的页面，也就是无效地址’。说明这个是有我们自己的程序导致的，最后的问题是我们的程序员在读取数据的时候出问题导致的：他读取了一张6000左右记录的全表数据，再进行foreach的循环读取某个字段的操作到数组。并且这个在程序的错误日志中也提示这个函数所在行的错误信息
