2013-10-27 59 views
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 
+0

可能在開發機器中有更多的備用RAM。我想你已經遇到了與燈具大小有關的已知錯誤。 –

+0

我的夾具尺寸是72.4 mb。我會分別嘗試傾倒/加載我的每個模型。 – gwaramadze

+0

當有大量數據時,我被告知XML裝置比JSON裝置表現得更好。當我遇到這個錯誤時,我傾向於使用普通的sql dump/load; –

回答

5

無法找到有關加載燈具的具體錯誤。這一個是傾銷,但我想根本原因相關:

有你的問題的一對夫婦重複:

當我遇到這個錯誤時,我被告知使用XML Fixtures,因爲XML解析器在內存佔用方面表現更好。

我的建議是不要在這個問題上失去多少睡眠,如果可以的話,儘量使用普通的SQL轉儲。