Je ne sais pas ce qui est mieux :répondre à ma question ou la mettre à jour... alors je choisis de répondre. Veuillez me faire savoir s'il est préférable de mettre à jour
Nous découvrons enfin le problème. Depuis la version 3.1, Rails a ajouté des instructions préparées sur simple demande comme User.find(id). Version 4.0, ajout d'instructions préparées aux requêtes sur les associations (has_many, exists_to, has_one).Par exemple le code suivant :
class User
has_many :adresses
end
user.addresses
générer une requête
SELECT "addresses".* FROM "addresses" WHERE "addresses"."user_id" = $1 [["user_id", 1]]
Le problème est que Rails n'ajoute que des variables d'instruction préparées pour les clés étrangères (ici user_id). Si vous utilisez une requête sql personnalisée comme
user.addresses.where("moved_at < ?", Time.now - 3.month)
il n'ajoutera pas de variable aux instructions préparées pour move_at. Ainsi, il génère des instructions préparées à chaque fois que la requête est appelée. Les rails gèrent les instructions préparées avec un pool de taille maximale 1000.
Cependant, les instructions préparées postgresql ne sont pas partagées entre les connexions, donc en une ou deux heures, chaque connexion a 1000 instructions préparées. Certains d'entre eux sont très grands. Cela a conduit à une consommation de mémoire très élevée sur le serveur postgreqsl.
