Uruchamiam program w Pythonie, który usuwa dane, więc za każdym razem, gdy próbuję pobrać zbyt dużo danych (nie byłem w stanie zeskrobać plików do 16 MB ) program ulega awarii.
Błąd:
INFO: Got 45294 tweets for %23COVID19%20since%3A2020-03-16%20until%3A2020-03-17. Traceback (most recent call last): File "/home/pi/Downloads/coronavirus2.py", line 127, in <module> search_term = "#NoSonVacaciones" File "/home/pi/Downloads/coronavirus2.py", line 77, in myfunction tweets= query_tweets(search_term, begindate= begin_date, enddate = end_date, poolsize=poolsize, lang= lang) File "/home/pi/Downloads/twitterscraper-1.3.1/twitterscraper/query.py", line 285, in query_tweets for new_tweets in pool.imap_unordered(partial(query_tweets_once, limit=limit_per_pool, lang=lang), queries): File "/usr/local/lib/python3.6/site-packages/billiard/pool.py", line 1964, in next raise Exception(value) Exception: Traceback (most recent call last): File "/usr/local/lib/python3.6/site-packages/billiard/pool.py", line 366, in workloop put((READY, (job, i, result, inqW_fd))) File "/usr/local/lib/python3.6/site-packages/billiard/queues.py", line 366, in put self.send_payload(ForkingPickler.dumps(obj)) File "/usr/local/lib/python3.6/site-packages/billiard/reduction.py", line 56, in dumps cls(buf, protocol).dump(obj) billiard.pool.MaybeEncodingError: Error sending result: ""(<twitterscraper.tweet.Tweet object at 0x734435b0>, <twitterscraper.tweet.Tweet object at 0x726a0750>, <twitterscraper.tweet.Tweet object at 0x726a03b0>, <twitterscraper.tweet.Tweet object at 0x726a0450>, <twitterscraper.tweet.Tweet object at 0x726a0090>, <twitterscraper.tweet.Tweet object at 0x726a0e70>, ... Reason: ""MemoryError()"". Czy istnieje sposób, żebym mógł przydzielić więcej pamięci na ten proces? Nie obchodzi mnie, ile czasu to zajmie, ani innych procesów, na które może to mieć wpływ.
Mam zaktualizowany system operacyjny Raspbian Jessie, a konfiguracja pamięci jest następująca:
pi@raspberrypi:~ $ cat /proc/meminfo MemTotal: 947748 kB MemFree: 285512 kB MemAvailable: 510712 kB Buffers: 78584 kB Cached: 193256 kB SwapCached: 1328 kB Active: 252492 kB Inactive: 362552 kB Active(anon): 99520 kB Inactive(anon): 275632 kB Active(file): 152972 kB Inactive(file): 86920 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 102396 kB SwapFree: 1736 kB Dirty: 20 kB Writeback: 0 kB AnonPages: 341888 kB Mapped: 60048 kB Shmem: 31944 kB Slab: 25744 kB SReclaimable: 11572 kB SUnreclaim: 14172 kB KernelStack: 1976 kB PageTables: 4640 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 576268 kB Committed_AS: 1269388 kB VmallocTotal: 1114112 kB VmallocUsed: 0 kB VmallocChunk: 0 kB CmaTotal: 8192 kB CmaFree: 1412 kB kod tutaj
Z góry dziękuję,
Pablo
Komentarze
- Co się stanie, jeśli zaktualizujesz od końca do obsługiwanego Raspbian Buster- of-life Jessie.
Odpowiedź
Jeśli nie zależy Ci na czasie wykonania, zwiększ rozmiar wymiany od 100 MB do kilku GB potroi ilość dostępnej pamięci. Prognozując aktualną wydajność kodu (1 GB lub RAM potrzebny do przetworzenia 16 MB danych), powinieneś być w stanie przetworzyć do 48 MB danych naraz.
sudo dphys-swapfile swapoff echo "CONF_SWAPSIZE=2048"|sudo tee /etc/dphys-swapfile sudo dphys-swapfile swapon O ile algorytm przetwarzania danych nie jest naprawdę związany z pamięcią, samo napisanie lepszego kodu może znacznie zmniejszyć wymagania dotyczące pamięci.
Komentarze
- Świetnie! Zwiększyłem rozmiar swapu i do tej pory mogłem przetworzyć do 20 MB, a proces obecnie działa. T dziękuję ci bardzo, Dmitry!