Django 固定装置。正在加载初始数据进程被杀死答案

【问题标题】：Django fixtures. Loading initial data process is being KilledDjango 固定装置。正在加载初始数据进程被杀死
【发布时间】：2013-11-06 12:31:00
【问题描述】：

我一直致力于将 57k+ 条记录从两个遗留数据库中提炼和重构为一个与 Django 兼容的实体。现在，当我完成后，我将其作为固定装置转储，并尝试将其加载到生产环境中。

我的问题是该过程在短时间内被“杀死”。我的流程是：

./manage.py syncdb --noinput
./manage.py loaddata core/fixtures/auth.json  # just a default user
./manage.py migrate

结果：

Running migrations for django_extensions:  # custom apps migrate just fine
 - Migrating forwards to 0001_empty.
 > django_extensions:0001_empty
 - Loading initial data for django_extensions.
Installed 0 object(s) from 0 fixture(s)
Running migrations for myotherapp:
 - Migrating forwards to 0001_initial.
 > myotherapp:0001_initial
 - Loading initial data for myotherapp.
Installed 4 object(s) from 1 fixture(s)  # my other app with a fixture migrates ok
Running migrations for myapp:
 - Migrating forwards to 0001_initial.
 > myapp:0001_initial
 - Loading initial data for myapp.
Killed

我必须注意，这个过程在我的开发机器上没有问题。另一个注意事项是，我的开发机器运行的是 postgres 9.2，生产中是 9.1 - 这会是个大问题吗？

我该如何调试呢？我什至不知道打印模糊的“Killed”有什么问题。 South 是否存储任何日志？任何帮助表示赞赏。

编辑：正如 Paulo Scardine 指出的那样，问题在于 JSON 文件过于繁重。首先我尝试了 XML 转储，它走得更远，但最终也被杀死了。一种方法是 SQL 转储。对于 Postgres，对我有用的是：

pg_dump dbname | gzip > filename.gz # dump data on dev machine
createdb dbname # create empty db in production
gunzip -c filename.gz | psql dbname # restore the dump in production

【问题讨论】：

可能你在开发机器上有更多的空闲内存。我认为您遇到了与灯具大小相关的已知错误。
我的灯具大小为 72.4 mb。我将尝试分别转储/加载我的 4 个模型。
有人告诉我，当您拥有大量数据时，XML 固定装置的性能优于 JSON 固定装置。当我遇到这个错误时，我倾向于使用普通的 sql 转储/加载；
谢谢，我需要一些时间来了解这个线索。您可能想将其发布为答案。

标签： django django-south django-fixtures

【解决方案1】：

找不到有关加载固定装置的特定错误。这个是为了倾销，但我想根本原因是相关的：

"dumpdata" should stream output one row at a time

您的问题有几个重复：

当我遇到这个错误时，我被告知要改用 XML 固定装置，因为 XML 解析器在内存占用方面表现得更好。

我的建议是不要因为这个问题而失眠，如果可以的话，请使用普通的 SQL 转储。

【讨论】：