Ik gebruik een Python-programma dat gegevens schrapt, dus wanneer ik probeer te veel gegevens op te halen (ik heb geen bestanden kunnen schrapen tot 16 MB ) crasht het programma.
De fout:
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()"". Is er een manier waarop ik meer geheugen kan toewijzen aan dit proces? Het kan me niet schelen hoeveel tijd het kost of andere processen die mogelijk worden beïnvloed.
Ik heb een Raspbian Jessie OS bijgewerkt en de geheugenconfiguratie is als volgt:
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 code hier
Bij voorbaat dank,
Pablo
Reacties
- Wat gebeurt er als je vanaf het einde een upgrade naar de ondersteunde Raspbian Buster uitvoert? of-life Jessie.
Antwoord
Als de uitvoeringstijd je niet kan schelen, vergroot dan je ruilgrootte van 100 MB tot een paar GB zal de hoeveelheid beschikbare geheugen verdrievoudigen. Als u uw huidige code-efficiëntie projecteert (1 GB of RAM nodig om 16 MB aan gegevens te verwerken), zou u in staat moeten zijn om tot 48 MB aan gegevens tegelijk te verwerken.
sudo dphys-swapfile swapoff echo "CONF_SWAPSIZE=2048"|sudo tee /etc/dphys-swapfile sudo dphys-swapfile swapon Tenzij uw gegevensverwerkingsalgoritme echt geheugengebonden is, kan het eenvoudigweg schrijven van betere code uw geheugenvereisten aanzienlijk verminderen.
Opmerkingen
- Briljant! Ik heb de swap-grootte vergroot en ik heb tot nu toe 20 MB kunnen verwerken en het proces werkt momenteel. T heel erg bedankt, Dmitry!