定位python腳本內存佔用過多的緣由

今天跑了個腳本，在linux下運行沒過多久，就被操做系統kill了，猜測應該是腳本佔用的系統資源過多，被操做系統強殺了。經過google，肯定了這是linux的OOM Killer機制。

剛開始想，應該有配置關掉oom Killer，這樣個人進程就不會被殺掉了，但以後又擔憂更改了這些配置，會對機器上的其餘程序有影響，因此決定從程序裏面找緣由，試圖優化資源的佔用。

因而，就開始了漫長的定位過程...

我經過top指令發現(剛開始我還傻傻的用ps -euf執行屢次去看內存的變化)，該腳本運行後，進程的內存佔用漲很快，平均每秒張百分之10。而後很快被系統kill掉了。

剛開始懷疑是程序採用的數據結構不對，看了代碼，沒發現問題。

因而，在懷疑可能出問題的部分，先後分別寫上raw_input，配合top指令查看內存佔用率的變化，將範圍縮小到了一個函數內。

最後定位到，因爲一個判斷寫錯了，致使一個string不斷的被累加，而後撐爆了內存。原來是一個很低級的判斷錯誤致使了bug，花了我半天時間去定位，感受好崩潰。

在這過程當中，順便學了用pdb調試python，原來用命令行去調試代碼還挺有趣的嘛，我應該能很快熟悉windbg的使用，想一想仍是有點小激動呢。

• python -m pdb main.py            用pdb調試py腳本
• b                                              15 在代碼15行打斷點
• c                                               讓程序繼續執行，至關於VC裏面的F5
• s                                               跳入函數，至關於VC裏面的step into
  
• p param                                    打印param的值
• cl                                              清除全部斷點
  
• condition 4 date=="20140101" 將第四個斷點的條件設置爲 date等於"20140101"