0

Railsサーバーの再起動時だけでなく、本番環境でも大量のSHOW TABLES;andクエリが見られます。DESCRIBE `table name`;パーティション化されたテーブル専用であることに気付きました。これは Rails 3.1.1 でのものです - 他のバージョンではテストされていません。

開発コンソールで ( を使用してcache_classes = true) テストしたところ、分割されたモデルについて、Rails が 任意の find メソッドから返されたレコードごとにSHOW TABLES;1 つと 1 つ実行されることに気付きました。DESCRIBE `table name`;

たとえば、itemsがパーティション化されていて、 Item.limit(5)5 つのレコードを返す場合、mySQL ログは次のようになります (注:SHOW TABLESの ANDDESCRIBEは Rails のログには含まれません)。

SELECT  `items`.* FROM `items`  LIMIT 5;
SHOW TABLES;
DESCRIBE `items`;
SHOW TABLES;
DESCRIBE `items`;
SHOW TABLES;
DESCRIBE `items`;
SHOW TABLES;
DESCRIBE `items`;
SHOW TABLES;
DESCRIBE `items`;

それはかなり正気ではありません。

もちろん、Railsサーバーを起動するときを除いて、パーティション化されていないモデルはSHOW TABLES「」も「」も実行しません。DESCRIBEAR モデルが主キーを認識していない場合、AR はそのモデルのオブジェクトがインスタンス化されるたびにスキーマを取得する必要があるようです。

cache_classesが に設定されている場合true、Rails は既知の主キーのないモデルでもスキーマをキャッシュする/キャッシュする必要があると考えるでしょう。しかし、そうではありません。

システムに実際に影響を与えるSHOW TABLESとは思わないでしょうが、十分なトラフィックがあると、1 つのパーティション テーブルに対するこれらの余分なクエリによる同時読み取りが実際のパフォーマンスの問題を引き起こすことがわかりました。DESCRIBE

これらのクエリをどのように取り除くことができますか?

4

1 に答える 1

0

composite_primary_keys gem がその日を救ってくれました。この宝石はずっと前に見た覚えがありますが、使用したことはありません。これらのメソッドを使い始めると、gem の意図された機能により、パーティション化されたモデルが確実に単純化されますが、gem を使用することの副作用の方が重要でした。

primary_key分割された各テーブルのを Rails に伝えるだけで、すべてSHOW TABLESの とが削除されましDESCRIBEた。これにより、explode-due-to-read-concurrency のしきい値を大幅に下回り、応答時間が改善されました。

于 2012-07-12T19:32:00.787 に答える