背景

在使用scrapy爬取東西的時候，使用crontab定時的啟動爬蟲，但是發(fā)現(xiàn)機器上經常產生很多卡死的scrapy進程，一段時間不管的話，會導致有10幾個進程都卡死在那，并且會導致數(shù)據(jù)產出延遲。

問題定位

使用py-spy這個非常好用的python性能分析工具來進行排查，py-spy可以查看一個python進程函數(shù)調用用時，類似unix下的top命令。所以我們用這個工具看看是什么函數(shù)一直在執(zhí)行。

首先安裝這個工具

pip install py-spy

用py-spy看看scrapy哪個函數(shù)執(zhí)行時間長

# 先找到這個卡死的scrapy進程的pid
ps -ef |grep scrapy 
# 啟動 py-spy 觀察這進程
py-spy top --pid 53424

首先我們按3，按OwnTime進行排序，這個表示函數(shù)自身執(zhí)行的時間，可以看到read這個函數(shù)執(zhí)行的時間最長，那看來是IO導致的，程序中的IO行為就是讀寫磁盤和網(wǎng)絡IO，磁盤讀寫一般不會有問題，所以初步定位是網(wǎng)絡IO導致的。

接下來進行進一步確認，再按4，按TotalTIme 所有子函數(shù)執(zhí)行時間總和進行排序，可以看到是在process_item和download，upload_image這些主流程函數(shù)的執(zhí)行時間比較長，這一步是先把圖片下載到本地，然后上傳到靜床，看來是下載這步從網(wǎng)絡中read數(shù)據(jù)時出現(xiàn)了問題，進一步追蹤代碼。

看下download的函數(shù)的代碼：

if filename == '':
      filename = os.path.basename(url)
    path = path + '/' + filename
    
    try:
      res = request.urlretrieve(url,filename=path)
      print(url,res)
      return path
    except Exception as e:
      print('download img failed')
      print(e)
      return False

可以看到用了urllib這個庫里面request.urlretrieve函數(shù)，這個函數(shù)是用來下載文件的，去看看python官網(wǎng)文檔的函數(shù)說明，發(fā)現(xiàn)里面沒有超時時間這個參數(shù)，所以是由于沒有超時時間，導致一直在read，進而使得進程卡死。

urllib.request.urlretrieve(url, filename=None,reporthook=None,data=None)

解決方案

使用另一種方式來下載圖片，使用支持超時時間的urlopen函數(shù)，封裝成一個自定義的url_retrieve，這樣就不再會出現(xiàn)沒有超時導致的卡死問題了。

def url_retrieve(self,url, path):
    r = request.urlopen(url, timeout=5)
    res = False
    with open(path,"wb") as f:
      res = f.write(r.read())
      f.flush()
      f.close()
    return res

到此這篇關于使用py-spy解決scrapy卡死的問題方法的文章就介紹到這了,更多相關scrapy卡死內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論