昨天早上突然發現測試服務器空間滿了，用du挨個文件夾查看，發現是php debug log占地極大，有的log直接有1G，打開後發現極其多的php stack trace.
立刻到主服務器查看，主服務器日志也400多M的日志，幸好主服務器空間足夠。
那麼多stack trace,可以肯定之前是沒有的，挨個查看日志，是某一天早上一個時刻發生的。
解決方案：
1. 難道是之前升級php導致，到網上搜索php stack trace,所有的都是顯示如何打開，卻沒有如何關閉的。仔細查找php的參數，只找到ignore_repeated_sources和ignore_repeated_error這兩個看似有關的東西，更改後也不頂用。
2. 如果不是升級php所致，再仔細想這幾天做了什麼 改動，哪些是和php trace有關的，想起xdebug. ，先嘗試把xdebug刪除，OK,問題消失了。肯定是xdebug的問題了，開始的時候沒有直接找xdebug的官方文檔，利用phpinfo把xdebug所有的參數都打出來，先猜是哪個參數，試了幾個都不頂用, 後來才靜下心來看看xdebug的官方文檔吧，發現了如下話語：
Stack Traces
When Xdebug is activated it will show a stack trace whenever PHP decides to show a notice, warning, error etc. The information that stack traces display, and the way how they are presented, can be configured to suit your needs.
有戲，再繼續找，發現了一個名稱和用途你如何也聯系不上的變量"xdebug.default_enable",還真就是這個參數來控制了，如下。
xdebug.default_enableType: boolean, Default value: 1
If this setting is 1, then stacktraces will be shown by default on an error event. You can disable showing stacktraces from your code withxdebug_disable(). As this is one of the basic functions of Xdebug, it is advisable to leave this setting set to 1. 這個問題幾乎折騰一天，心得：碰到意外問題時要冷靜，雖然影響了多原有計劃，但如果問題是嚴重的問題就一定要排除萬難先解決了再說，不然會形成習慣。另外，使用一些現成功能模塊時，在在最衩進行搜索無果後，得靜下心來仔細閱讀官方文檔。
