私はdjango、celery、rabbitmqを使用して、2つの定期的なタスクと6つのアドホックタスクを実行しています。すべてのタスクは（app）/tasks.pyにあります。定期的タスクとアドホックタスクは、2つの別々のキュー（high_priority_queueとlow_priority_queue）に分割されます。
ビートと2つのキューに対して3つのスーパーバイザコマンドを設定しています。
$ ./manage.py celeryd --concurrency=1 --verbosity=3 --loglevel=INFO --beat
$ ./manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=high_priority_queue
$ ./manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=low_priority_queue
tasks.pyファイルは約686行のPythonであり、主にネットワークとDBの作業を行っています。15行のインポートと約14のDjangoモデルがあります。1つのインポート行のモデルクラスがインポートされます。
私のubuntuサーバーでは、各スレッドが41〜48MBのRESメモリを使用していることがわかります。これは大変なことだと思います。各スレッドのRESメモリ使用量を減らす方法があるかどうか疑問に思っています。私ができるコード編成のトリックはありますか？各タスクなどで使用する直前にモデルをインポートする必要がありますか？
上からの抜粋は次のとおりです。
VIRT RES SHR %MEM COMMAND 18701 mark 20 0 253m 61m 1396 S 26 8.3 0:10.90 /home/mark/.virtualenvs/searchrank.is/bin/python /home/mark/searchrank.is/src/manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=low_priority_queue
320m 59m 1400 8.1 .../manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=low_priority_queue
317m 59m 1360 8.0 .../manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=high_priority_queue
303m 45m 1172 6.2 .../manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=high_priority_queue
300m 43m 1056 5.9 .../manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=low_priority_queue
300m 43m 348 5.9 .../manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=high_priority_queue
305m 30m 0 4.1 .../manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=high_priority_queue
305m 29m 0 4.0 .../manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=low_priority_queue
306m 27m 8 3.7 .../manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=high_priority_queue
305m 25m 16 3.5 .../manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=low_priority_queue
304m 24m 0 3.4 .../manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=high_priority_queue
304m 24m 12 3.4 .../manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=low_priority_queue
305m 19m 4 2.7 .../manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=low_priority_queue
230m 19m 164 2.6 .../manage.py celeryd --concurrency=1 --verbosity=3 --loglevel=INFO --beat
306m 18m 0 2.5 .../manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=high_priority_queue
303m 16m 4 2.3 .../manage.py celeryd --concurrency=1 --autoscale=2,1 --verbosity=3 --loglevel=INFO --queues=low_priority_queue
299m 15m 1020 2.2 .../manage.py celeryd --concurrency=1 --verbosity=3 --loglevel=INFO --beat