早些天查看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的循環讀取某個字段的操作到數組。並且這個在程序的錯誤日誌中也提示這個函數所在行的錯誤信息