背景

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

問題定位

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

首先安裝這個(gè)工具

pip install py-spy

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

# 先找到這個(gè)卡死的scrapy進(jìn)程的pid
ps -ef |grep scrapy 
# 啟動(dòng) py-spy 觀察這進(jìn)程
py-spy top --pid 53424

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

接下來進(jìn)行進(jìn)一步確認(rèn)，再按4，按TotalTIme 所有子函數(shù)執(zhí)行時(shí)間總和進(jìn)行排序，可以看到是在process_item和download，upload_image這些主流程函數(shù)的執(zhí)行時(shí)間比較長(zhǎng)，這一步是先把圖片下載到本地，然后上傳到靜床，看來是下載這步從網(wǎng)絡(luò)中read數(shù)據(jù)時(shí)出現(xiàn)了問題，進(jì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這個(gè)庫(kù)里面request.urlretrieve函數(shù)，這個(gè)函數(shù)是用來下載文件的，去看看python官網(wǎng)文檔的函數(shù)說明，發(fā)現(xiàn)里面沒有超時(shí)時(shí)間這個(gè)參數(shù)，所以是由于沒有超時(shí)時(shí)間，導(dǎo)致一直在read，進(jìn)而使得進(jìn)程卡死。

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

解決方案

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

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

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

最新評(píng)論