Django多处理和数据库连接

背景：

我正在一个将Django与Postgres数据库一起使用的项目。在某些情况下，我们也会使用mod_wsgi，因为我的一些网络搜索都提到了它。在Web表单提交中，Django视图启动了一个需要大量时间的工作（比用户希望等待的时间还长），因此我们通过后台的系统调用来启动该工作。现在正在运行的作业需要能够读取和写入数据库。因为这项工作需要很长时间，所以我们使用多重处理来并行运行它的各个部分。

问题：

顶级脚本具有数据库连接，当它产生子进程时，似乎父级的连接对子级可用。然后有一个例外，关于在查询之前必须如何调用SET TRANSACTION ISOLATION LEVEL。研究表明，这是由于试图在多个进程中使用相同的数据库连接。我发现一个线程建议在子进程开始时调用connection.close（），以便Django在需要时自动创建一个新连接，因此每个子进程将具有唯一的连接-即不共享。这对我不起作用，因为在子进程中调用connection.close（）导致父进程抱怨连接丢失。

其他发现：

我读过的一些东西似乎表明您不能真正做到这一点，并且多处理，mod_wsgi和Django不能很好地配合使用。我猜这似乎很难相信。

有些人建议使用celery，这可能是一个长期解决方案，但是我目前无法安装celery，需要等待一些批准程序，因此现在无法选择。

在SO和其他地方找到了一些有关持久数据库连接的参考，我认为这是一个不同的问题。

还发现了对psycopg2.pool和pgpool的引用以及有关bouncer的内容。诚然，我不了解我所读的大部分内容，但是它确实并没有像我想要的那样让我惊讶。

当前的“工作环境”：

现在，我已经恢复为仅串行运行，并且可以运行，但是速度比我想要的慢。

关于如何使用多处理并行运行的任何建议？好像我可以让父母和两个孩子都具有与数据库的独立连接一样，一切都会好起来的，但是我似乎无法获得这种行为。

谢谢，很抱歉！

多重处理会在进程之间复制连接对象，因为它会分叉多个进程，因此会复制父进程的所有文件描述符。就是说，与SQL Server的连接只是一个文件，您可以在Linux的/ proc // fd / ...下看到它。任何打开的文件都将在分支的进程之间共享。您可以在此处找到有关分叉的更多信息。

我的解决方案只是在启动进程之前关闭数据库连接，每个进程在需要连接时都会重新创建连接（在django 1.4中进行了测试）：

from django import db
db.connections.close_all()
def db_worker():      
    some_paralell_code()
Process(target = db_worker,args = ())

Pgbouncer / pgpool在多处理的意义上没有与线程连接。这是不关闭每个请求的连接=在高负载下加快连接到postgres的解决方案。

更新：

要完全消除数据库连接问题，只需将与数据库连接的所有逻辑移至db_worker-我想将QueryDict作为参数传递...更好的主意是简单地传递ID列表...请参阅QueryDict和values_list（'id'，flat =是的），不要忘了把它列出来！list（QueryDict），然后传递给db_worker。因此，我们不会复制模型数据库连接。

def db_worker(models_ids):        
    obj = PartModelWorkerClass(model_ids) # here You do Model.objects.filter(id__in = model_ids)
    obj.run()


model_ids = Model.objects.all().values_list('id', flat=True)
model_ids = list(model_ids) # cast to list
process_count = 5
delta = (len(model_ids) / process_count) + 1

# do all the db stuff here ...

# here you can close db connection
from django import db
db.connections.close_all()

for it in range(0:process_count):
    Process(target = db_worker,args = (model_ids[it*delta:(it+1)*delta]))   

使用多个数据库时，应关闭所有连接。

from django import db
for connection_name in db.connections.databases:
    db.connections[connection_name].close()

编辑

请使用与上述提到的@lechup相同的方法关闭所有连接（不确定自从该方法添加到哪个Django版本以来）：

from django import db
db.connections.close_all()

对于Python 3和Django 1.9，这对我有用：

import multiprocessing
import django
django.setup() # Must call setup

def db_worker():
    for name, info in django.db.connections.databases.items(): # Close the DB connections
        django.db.connection.close()
    # Execute parallel code here

if __name__ == '__main__':
    multiprocessing.Process(target=db_worker)

请注意，如果没有django.setup（），我将无法正常工作。我猜想某些东西需要再次初始化以进行多处理。

依次运行Django测试用例时，出现“关闭连接”问题。除测试外，还有另一个过程在测试执行期间有意修改数据库。该过程在每个测试用例setUp（）中启动。

一个简单的修正是要继承我的测试类TransactionTestCase的代替TestCase。这样可以确保实际上已写入数据库，并且其他进程具有该数据的最新视图。

（不是很好的解决方案，但是可能的解决方法）

如果您不能使用celery，也许您可​​以实现自己的排队系统，基本上将任务添加到某些任务表中，并使用常规cron进行处理？（通过管理命令）

嘿，我遇到了这个问题，并通过执行以下操作得以解决（我们正在实施一个有限的任务系统）

task.py

from django.db import connection

def as_task(fn):
    """  this is a decorator that handles task duties, like setting up loggers, reporting on status...etc """ 
    connection.close()  #  this is where i kill the database connection VERY IMPORTANT
    # This will force django to open a new unique connection, since on linux at least
    # Connections do not fare well when forked 
    #...etc

ScheduledJob.py

from django.db import connection

def run_task(request, job_id):
    """ Just a simple view that when hit with a specific job id kicks of said job """ 
    # your logic goes here
    # ...
    processor = multiprocessing.Queue()
    multiprocessing.Process(
        target=call_command,  # all of our tasks are setup as management commands in django
        args=[
            job_info.management_command,
        ],
        kwargs= {
            'web_processor': processor,
        }.items() + vars(options).items()).start()

result = processor.get(timeout=10)  # wait to get a response on a successful init
# Result is a tuple of [TRUE|FALSE,<ErrorMessage>]
if not result[0]:
    raise Exception(result[1])
else:
   # THE VERY VERY IMPORTANT PART HERE, notice that up to this point we haven't touched the db again, but now we absolutely have to call connection.close()
   connection.close()
   # we do some database accessing here to get the most recently updated job id in the database

老实说，为防止出现争用情况（有多个同时用户），最好在分叉该过程后尽快调用database.close（）。不过，在您有机会刷新数据库之前，仍然有可能其他用户完全向数据库发出请求。

老实说，让fork不直接调用命令，而是在操作系统上调用脚本，使派生的任务在自己的django shell中运行，可能更安全，更聪明！

您可以为Postgre提供更多资源，在Debian / Ubuntu中，您可以编辑：

nano /etc/postgresql/9.4/main/postgresql.conf

用postgre版本替换9.4。

这是一些有用的行，应使用示例值进行更新，以使名称生效：

max_connections=100
shared_buffers = 3000MB
temp_buffers = 800MB
effective_io_concurrency = 300
max_worker_processes = 80

注意不要增加太多这些参数，因为它可能导致Postgre尝试获取比可用资源更多的资源而出错。上面的示例在配备4个内核的Debian 8GB Ram计算机上运行良好。

如果仅需要I / O并行性而不是处理并行性，则可以通过将进程切换到线程来避免此问题。更换

from multiprocessing import Process

与

from threading import Thread

该Thread对象具有与以下对象相同的接口Procsess

如果您还使用连接池，则以下对我们有用，在分叉后强制关闭连接。以前似乎没有帮助。

from django.db import connections
from django.db.utils import DEFAULT_DB_ALIAS

connections[DEFAULT_DB_ALIAS].dispose()