Ich führe ein Python-Programm aus, das Daten verschrottet, wenn ich versuche, zu viele Daten abzurufen (ich konnte keine Dateien kratzen) Bis zu 16 MB ) stürzt das Programm ab.
Der Fehler:
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()"". Gibt es eine Möglichkeit, mehr Speicher für diesen Prozess zuzuweisen? Es ist mir egal, wie lange es dauert oder welche anderen Prozesse betroffen sein können.
Ich habe ein Raspbian Jessie-Betriebssystem aktualisiert und die Speicherkonfiguration lautet wie folgt:
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
Vielen Dank im Voraus,
Pablo
Kommentare
- Was passiert, wenn Sie von Ende an auf den unterstützten Raspbian Buster aktualisieren? of-life Jessie.
Antwort
Wenn Sie sich nicht um die Ausführungszeit kümmern, erhöhen Sie Ihre Swap-Größe Von 100 MB auf ein paar GB verdreifacht sich der verfügbare Speicher. Wenn Sie Ihre aktuelle Codeeffizienz (1 GB oder RAM für die Verarbeitung von 16 MB Daten) projizieren, sollten Sie in der Lage sein, bis zu 48 MB Daten gleichzeitig zu verarbeiten.
sudo dphys-swapfile swapoff echo "CONF_SWAPSIZE=2048"|sudo tee /etc/dphys-swapfile sudo dphys-swapfile swapon Wenn Ihr Datenverarbeitungsalgorithmus nicht wirklich speichergebunden ist, kann das einfache Schreiben von besserem Code Ihren Speicherbedarf erheblich reduzieren.
Kommentare
- Genial! Ich habe die Swap-Größe erhöht und konnte bisher bis zu 20 MB verarbeiten. Der Prozess funktioniert derzeit. T. Ich danke Ihnen vielmals, Dmitry!