You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On ncei.nceas.ucsb.edu, which is a small test server with 8GB of RAM, we're seeing the kernel oom-killer repeatedly kill the python process that results from the cron job running python manage.py process_replication_queue. Since the job runs once per minute, and the vast majority of them succeed, I suspect it's jobs that are replicating large files across the wire that are causing the issue, and that perhaps there's some code that is spooling data to memory prior to writing to disk. Here's a sample from /var/log/syslog:
Hey Chris, I'm cleaning out some old issues on GitHub. Looking at the syslog for the bug you reported, there's certainly one Python process that stands out:
7.5 GB of reserved virtual memory on an 8GB box would explain why it ends up getting killed. Did you confirm that it was a GMN related process? GMN is designed to stream pretty much everything, and management commands like the queue processing tasks should exit out right away if another command of the same kind is already running.
On ncei.nceas.ucsb.edu, which is a small test server with 8GB of RAM, we're seeing the kernel
oom-killer
repeatedly kill the python process that results from the cron job runningpython manage.py process_replication_queue
. Since the job runs once per minute, and the vast majority of them succeed, I suspect it's jobs that are replicating large files across the wire that are causing the issue, and that perhaps there's some code that is spooling data to memory prior to writing to disk. Here's a sample from/var/log/syslog
:The text was updated successfully, but these errors were encountered: