這篇文章是基於上篇文章的續章~
一台機器要部署很多爬蟲，每天定時執行的情況下，服務器CPU和內存占比較高的情況出現后
模擬一份代碼，進行分析。
一個簡單的爬蟲程序，爬取10頁數據共計150條，每天定時寫入數據庫
總共不到150行，沒運行期間內存已經20%多了，運行期間內存會漲到60%，CPU會漲到40%左右
一個簡單程序如此高的消耗肯定是有問題的，參考了網上的一些文章
有使用工具的，安裝第三方包的，寫時間判斷的等等
但是對我的幫助不大(windows....)
努(帶)力(薪)工(拉)作(*)之后，根據看過的文章思考了一番： 1.內存和CPU高代表着程序當中的部分代碼在大量或反復的執行 2.爬取的時間3-4秒，寫入MYSQL數據庫，解析使用的XPATH， 保存數據使用的單表，索引只有ID和URL，表結構數據長度都合適 3.使用了線程，線程數4個 4.沒有文件讀寫操作，網絡請求較快，對方服務器響應較快 5.使用了schedule定時模塊 6.對后台接口進行任務輪詢和定時模塊當中出現了while True
還有文章提到判斷導入的模塊是否時c寫的，導致底層頻繁調用，首先這個說法不說對不對...一是不會看，二是看了不也得用這個模塊嗎 所以不考慮這種情況 1.部分代碼在大量或反復的執行，具體是哪里差找起來不方便，可以放在最后進行過濾 2.時間短，執行結束return，應該不存在變量未回收的情況；數據量不大，寫入MySQL應該沒問題； XPATH解析數據很快，網頁結構並不復雜；單表保存，不涉及到復雜邏輯，索引ID為了自增，URL為了去重，數據量少， 數據表的長度戳戳有余，應該也不是這里； 3.線程使用ThreadPoolExecutor，workers = 4，數量不多 4.沒有文件讀寫，網絡請求正常 5.定時模塊的while True和任務輪詢的while True
思考一番之后，情況1和情況5似乎有重疊的部分，於是看了下任務輪詢
每隔半分鍾進行一次查詢，查詢到了便把相關設置傳入定時任務中，抱着不放過任何一個可疑代碼塊的精神
單獨把query_task()拿出來進行測試，CPU占比不到1%，內存占比不到2%
那么就可能是定時模塊的問題
進入定時之后就會在每天早上7點執行，應該也是沒問題的
那么schedule.run_pending()就顯得非常有問題，簡單粗暴的下面添加個print(111)看看情況
簡直是瘋狂輸出1111...
接下來添加個time.sleep(10)看看效果
可以看到python的CPU已經降下來了(不要問我為什么不見那個testss文件，但是pycharm下后面寫的是4)
內存仍然大可以試試在cmd中執行python文件看看效果，不使用pycharm
所以代碼的問題就在定時任務中的while true的地方
后面會試着把schedule換成APS，如果還有類似的問題再說~
以上僅代表個人調試經驗
文章有不對的地方歡迎大佬批評指正，我也是第一次調這個東西~