昨日遇到一個(gè)問(wèn)題，使用Yii框架編寫(xiě)php腳本，將db中100多萬(wàn)的數(shù)據(jù)導(dǎo)出，運(yùn)行，成功。

但是在 運(yùn)行到第 49萬(wàn)條時(shí)，腳本終止，提示錯(cuò)誤“File size limit exceeded”，遂google之，原來(lái)是某個(gè)文件大小超過(guò)系統(tǒng)限制。筆者第一反應(yīng)，日志文件寫(xiě)滿了？？？趕忙查看 log，居然只有幾十K !!! 那么這個(gè) “大文件”在哪里呢？

開(kāi)始分析，不可能是Yii框架的問(wèn)題，此乃linux操作系統(tǒng)異常問(wèn)題與框架無(wú)光，也不是 日志文件大小，仔細(xì)查看了所有設(shè)置的log路徑下的文件，均小的可以忽略，即使是將Yii的debug關(guān)掉，也出現(xiàn)了相同的問(wèn)題。

那么換個(gè)思路，重新運(yùn)行腳本，再次運(yùn)行腳本，發(fā)現(xiàn) dead的時(shí)間很有規(guī)律，均是在45萬(wàn)條記錄時(shí)掛掉，一條不多一條不少，開(kāi)始懷疑與進(jìn)程有關(guān)。決定查看腳本進(jìn)程所影響到的io。

1、先獲取腳本進(jìn)程的 <pid>；

2、使用lsof命令查看此pid的io情況 ： lsof -p <pid>

發(fā)現(xiàn)一個(gè)疑似文件 data0/xdebug/cachegrind.out.<pid>，隨著腳本的執(zhí)行，這個(gè)xdebug文件的大小也隨之增大，最后，如愿，掛掉！此時(shí)文件大小為：2147483647?。?/P>

哈哈，好熟悉的數(shù)字，2^31 -1 ??！

看來(lái)問(wèn)題找到了，在腳本執(zhí)行時(shí)，xdebug也隨之對(duì)這個(gè)腳本進(jìn)程進(jìn)行寫(xiě)記錄日志，當(dāng)此文件大小超出 系統(tǒng)所能支持的文件大小時(shí)，如期掛掉。

ok, 將xdebug關(guān)掉，重跑腳本，一百多萬(wàn)的記錄順利跑完，搞定。

ps： 筆者所使用的服務(wù)器為32位系統(tǒng)，而在32位操作系統(tǒng)中，由于是二進(jìn)制，其能最大存儲(chǔ)的數(shù)據(jù)是1111111111111111111111111111111。

正因?yàn)榇?，體現(xiàn)在其他可視系統(tǒng)中的十進(jìn)制就為2147483647。

php技術(shù)：解決File size limit exceeded 錯(cuò)誤的方法，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。