2 
print 'restore db1'
run_command('pg_restore -i -h localhost -p 5432 -U postgres -d db1 -v "/var/lib/project/backup/db1.backup" -c')
print '--- wait 3 seconds'
time.sleep(3)

print 'restore db2'
run_command('pg_restore -i -h localhost -p 5432 -U postgres -d db2 -v "/var/lib/project/backup/db2.backup" -c')
print '--- wait 3 seconds'
time.sleep(3)

print 'restoring mongodb'
run_command('/var/lib/project/bbds/mongodb-linux/bin/mongorestore /var/lib/project/backup/dump --drop')
print '--- wait 3 seconds'
time.sleep(3)

私run_commandは基本的にこれから取られています。

私のコンソールで：

python ignition.py --load-fixtures
For safety, this process will run for about one minute.
setup LDAP
restore db1
['pg_restore', '-i', '-h', 'localhost', '-p', '5432', '-U', 'postgres', '-d', 'db1', '-v', '/var/lib/project/backup/db1.backup', '-c']
Password:

パスワードを入力した直後にスタックしました。その後は何も起こりません。リソースがビジーかどうかはわかりません。pg_restoreはまだ実行中ですがps au|grep pg_restore、そうでmongorestoreはありません。したがって、最初の復元でスタックする必要があります。仮想マシンには512MBしかなく、常に満杯であり、常にスワップメモリ​​を使用しているため、メモリが満杯だとは思いません。

それが何をしているのかをどうやって知るのですか？時々それはmongoの復元に固執します。したがって、これらすべての操作が問題を引き起こす可能性があります。これをどのようにトラブルシューティングする必要がありますか？

ありがとう。

プロセスを強制終了すると、次のトレースバックが返されます。http: //pastebin.com/Cnv9P6HW 再起動すると問題が「解決」されます。これにより、スクリプトを問題なく実行できるようになります。しかし、それは安定していません。後で時々行き詰まってしまうでしょう。

4

1 に答える 1

2

pg_restoreandの使用法はmongorestore独立しているようです。私は試してみます：

  • コマンドラインから直接各コマンドを実行する (つまり、 Python 経由ではないdo_command())
  • これらを別々のスクリプトに入れて、どのコマンドがハングしているかを判断できるようにします

512MB の RAM しかなく、常にスワップを使用しているというあなたの言及は、この VM に十分な空きメモリがないことを示唆しています。「固まる」とは具体的にどういう意味ですか？VM が実際に動かなくなり、再起動する必要がある場合は、RAM とスワップの両方が不足している可能性があります。それでもログインできるが、復元スクリプトが予想よりも長く実行されているように見える場合は、 や などのパフォーマンス監視ツールを使用してリソースの使用状況を把握しようとします。iostatvmstat

于 2012-06-26T03:45:47.393 に答える