早些天檢視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的循環讀取某個字段的操作到數組。并且這個在程式的錯誤日志中也提示這個函數所在行的錯誤資訊