4
我一直致力於將兩個遺留數據庫中的57k +記錄精煉並重構爲一個Django兼容實體。現在,當我完成後,我將它作爲一個固定裝置傾倒,我試圖在生產環境中加載它。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
可能在開發機器中有更多的備用RAM。我想你已經遇到了與燈具大小有關的已知錯誤。 –
我的夾具尺寸是72.4 mb。我會分別嘗試傾倒/加載我的每個模型。 – gwaramadze
當有大量數據時,我被告知XML裝置比JSON裝置表現得更好。當我遇到這個錯誤時,我傾向於使用普通的sql dump/load; –