0

すべてのアプリ マシンで Jenkins にデプロイ スクリプトを実行させています。最近、ビルドの半分が終了せず、同じことを実行しようとしてもハングし続けます。最後の出力は次のようになります。

 ** [app@app1 :: stdout] Generating Configuration to /var/www/app/releases/20130509192657/config/production.sphinx.conf
 ** [app@app2 :: stdout] Generating Configuration to /var/www/app/releases/20130509192657/config/production.sphinx.conf
 ** [app@app3 :: stdout] Generating Configuration to /var/www/app/releases/20130509192657/config/production.sphinx.conf
 ** [app@app4 :: stdout] Generating Configuration to /var/www/app/releases/20130509192657/config/production.sphinx.conf
 ** [app@app6 :: stdout] Generating Configuration to /var/www/app/releases/20130509192657/config/production.sphinx.conf
 ** [app@app7 :: stdout] Generating Configuration to /var/www/app/releases/20130509192657/config/production.sphinx.conf

app5 は常にこの問題があると思われるマシンであり、実行しようとすると発生します。

/usr/local/bin/ruby /usr/local/bin/bundle exec rake db:migrate ts:conf

本番環境では ruby​​ 1.9.3p194 を実行していますが、従来の理由により、まだ ThinkingSphinx v. 0.9.8 を実行しています。また、Rails 3.2.13 と ThinkingSphinx 2.0.7 も実行しています。

ハングしているプロセスで strace を実行すると、次のようになります。

...
29802 select(4, [3], NULL, NULL, NULL <unfinished ...>
29790 restart_syscall(<... resuming interrupted call ...>) = -1 ETIMEDOUT (Connection timed out)
29790 futex(0x64a88e8, FUTEX_WAKE_PRIVATE, 1) = 0
29790 write(4, "!", 1 <unfinished ...>
29802 <... select resumed> )            = 1 (in [3])
29790 <... write resumed> )             = 1
29802 read(3,  <unfinished ...>
29790 futex(0x1d47f64, FUTEX_WAIT_PRIVATE, 3, NULL <unfinished ...>
29802 <... read resumed> "!", 1024)     = 1
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
29802 select(4, [3], NULL, NULL, {0, 100000}) = 0 (Timeout)
...

誰もこれを見たことがありますか？sysops のバックグラウンドがあまりありませんが、この問題に取り組むために取るべき特定のアプローチはありますか?

4

1 に答える 1

0

db:migrateがロックしている場合は、移行で参照されているデータベース テーブル (またはその他のリソース) をロックしているアクティブなプロセス、またはハングした (おそらくゾンビの) プロセスがある可能性があります。私は最近、別のエンジニアによって実行されたデータ修正スクリプトがクラッシュした (私が試みていた展開の 1 週間以上前) が終了しなかったという状況を経験しました。私たちにとっての修正は、スタックしているプロセスを終了することだけでした。その後、移行は通常どおりに機能しました。

システム アーキテクチャを知らなければ、競合するリソースが何であるかを正確に特定することは困難です。rdbms ツールキットを使用すると、サーバーでホストされている db を調べて、開いている接続の状態を確認できる場合があります。

于 2013-05-10T06:48:38.270 に答える