django.contrib.sessions.backends.cached_db
MySQL データベース バックエンドを備えたバックエンドで構成された 1 年間の運用サイトがあります。cached_db を選択した理由は、セキュリティと読み取りパフォーマンスの組み合わせです。
問題は、有効期限が切れたすべてのセッションを削除するクリーンアップ コマンドが実行されなかったため、セッション テーブルのデータ長が 2.3GB、行数が 600 万行、インデックス長が 500Mb になったことです。
./manage.py cleanup
(Django 1.3 で) コマンドを実行しようとしたとき、または./manage.py clearsessions
(Django の 1.5 通信で) コマンドを実行しようとしても、プロセスが終了しません (または、私の忍耐力が 3 時間も続きません)。
これを行うために Django が使用するコードは次のとおりです。
Session.objects.filter(expire_date__lt=timezone.now()).delete()
最初の印象では、テーブルに 6M 行あるので、これは正常だと思いますが、システムのモニターを調べると、すべてのメモリと CPU が mysqld ではなく python プロセスによって使用され、マシンのリソースがいっぱいになっていることがわかりました。このコマンド コードには何かひどい問題があると思います。Python は、確立された期限切れのすべてのセッション行を反復処理してから、それぞれを 1 つずつ削除しているようです。この場合、生のDELETE FROM
コマンドにコードをリファクタリングすることで問題を解決でき、Django コミュニティに役立ちますよね? しかし、これが事実である場合、クエリセットの削除コマンドは奇妙な動作をしており、私の意見では最適化されていません。私は正しいですか?