本番サーバーの Rails アプリケーションを Ruby 1.9 に更新しようとしています。私たちにはいくつかの本番サイトがあり、そのうちのいくつかはより重要なアップタイム要件があるため、より重要なサイトでのダウンタイムを最小限に抑えるために、各サイトを一度に 1 つずつ更新することは非常に有益です。
Phusion Passenger 4 では、さまざまな Ruby バージョンを使用してサイトを簡単に実行できます。これは、1.9 (およびそれ以降の 2.0) への段階的な移行を確実にするための優れた機能です。現在、サーバーは Apache モジュール Passenger 3.0.11 の下で動作し、システム ruby-1.8.7-352 を使用しています。
更新を開始するために、rvm と ruby-1.9.2-p320 をインストールしました。新しいルビーを使用して、パッセンジャー 4.0.10 をインストールします。次に、httpd.conf を次のように更新しました。
LoadModule passenger_module /path/to/mod_passenger.so
PassengerRoot /path/to/gems/passenger-4.0.10
PassengerDefaultRuby /path/to/ruby-1.9.2-p320/ruby
次に、site.conf で
PassengerRuby /path/to/old/ruby
これは、サイトが以前と同じようにシステム ruby を使用する必要があり、更新する必要があるのは Phusion Passenger だけであることを意味します。その結果、実稼働アプリケーションは、ActiveRecord::StatementInvalidおそらく 3000 リクエストごとに 1 回、例外をスローし始めました。例外率は、トラフィックが多い期間に明らかに高くなります。エラーは次のとおりです。
Exception Class: ActiveRecord::StatementInvalid
Message: Mysql2::Error: Lost connection to MySQL server during query: SELECT ...
いくつかのページでエラーの例がありますが、ほとんどは「大きな」SQLクエリ（おそらく最大0.4秒のクエリ、1.7秒のリクエスト）を使用するページです。
その後、古いパッセンジャーで httpd.conf を復元したところ、エラーはなくなりました。
クエリの死の原因を診断するのに役立つ人はいますか?
ありがとう。
===編集1 ===
PassengerSpawnMethod directhttpd.conf に追加しようとしたので、次のようになりました。
LoadModule passenger_module /path/to/mod_passenger.so
PassengerRoot /path/to/gems/passenger-4.0.10
PassengerDefaultRuby /path/to/ruby-1.9.2-p320/ruby
PassengerSpawnMethod direct
しかし、一見同じ頻度で同じエラーが発生しています。
===編集2 ===
システム 1.8 ルビーの下にパッセンジャー 4.0.10 をインストールすることも必死になって試みましたが、同じ結果が得られました。他にできることはありますか、それともパッセンジャーを更新する準備ができていないと想定すべきですか? これを引き起こしている可能性のあるコードで探すことができるものはありますか? mysql のエラー ログを確認しましたが、何もありません。誰かが他に見る価値のあるものを提案できますか? 先に進むことに関しては、これ以上これ以上時間を割く予定はありません。週末に ruby 1.9 で実稼働サイトをテストし、弾丸をかじってパッセンジャー 3 の下に移動するだけです。
===編集3 ===
パッセンジャーをセットアップしたので、パッセンジャー 4 の下のアプリケーションごとに 1 つのパッセンジャー プロセスしかありません。まだこれらのエラーがあります。したがって、スポーン/複数アクセスの問題ではありません。乗客がデータベースへのアプリケーション接続をいじっているのを見ることはできませんが、私が変更しているのは乗客だけです。Railsアプリに標準のmsyql2 gemを使用しています。失敗している要求は、大規模な選択クエリです (完了までに 1 秒程度)。