Llevo un buen rato perdiendo el tiempo por culpa de un “behaviour” de ruby/rails, pero después de mucho batallar por fin he encontrado lo que estaba pasando, y lo he solucionado.
Escribo esto para ver si san google me indexa el blog y desde aqui puedo ayudar un poco a los pobres desarrolladores web que se enfrenten al mismo problema que yo… Memory Leaks!!
Pero esta vez de los gordos, nada de mariconadas como el GetText 1.90 y su Mb por request perdido….
El tema tiene relación con activerecord, una asociación has_many :through junto con otra has_and_belongs_to_many y un callback. Vayamos a por el ejemplo práctico:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | class User < ActiveRecord::Base has_many :groups_users has_many :groups, :through => :groups_users has_and_belongs_to_many :discussions end class Group < ActiveRecord::Base has_many :groups_users has_many :users, :through => :groups_users has_one :discussion before_create :create_discussion end class GroupsUser < ActiveRecord::Base belongs_to :group belongs_to :user before_create :add_owner_to_discussion def add_user_to_discussion group.discussion.users << user end end class Discussion < ActiveRecord::Base belongs_to :group has_and_belongs_to_many :users end |
El tema está claro, un usuario puede pertenecer a n grupos, cada grupo tiene una discusión, y los usuarios pertenecen a estas discusiones.
Vayamos a la consola, primero creamos 3000 usuarios
1 | >> 3000.times {|x| User.create } |
Vale, ahora creemos un grupo
1 | >> g = Group.create |
Y como paso final…. le asignamos a este grupo todos los usuarios
1 | >> User.all.each {|u| g.users << u} |
PAM! Si lo has ejecutado de petará la maquina por exceso de memoria, en mi caso, 2 Gb de SWAP ocupadas en mi precioso MacBook Pro.
¿Cuál es el problema?
El memory leak está en el callback definido en GroupsUser. Al parecer en una asociación has_and_belongs_to_many, el método << devuelve el proxy (en nuestro caso users) y este proxy se queda en el limbo de ruby al finalizar la llamada al callback, provocando que para cada llamada al callback el proceso pierda bastante memoria (calculo que entre 500 kb y 1 Mb). ¿Cómo solucionarlo? Fácil, asigna una variable y despues nullificala para borrar de la memoria el proxy, en nuestro ejemplo:
1 2 3 4 | def add_user_to_discussion x = group.discussion.users << user x = nil end |
That’s it, problema resuelto. Increible pero cierto. Atentos a vuestro código. 
Bueno saberlo!
Creo de todos modos que el porqué es otro, me explico.
Este programa
def build_large_array
Array.new(5000)
end
while true
build_large_array
end
no tiene un leak. La memoria sube hasta que entra el garbage collector (a los 7-8 megas en mis pruebas). Si asignas el array a una variable que luego nilificas el comportamiento es el mismo.
A posteriori dirias que la asignacion no afecta porque igualmente sucede que el array es un objeto que es susceptible de ser recolectado porque fue creado. Es decir, que la variable que lo almacenaba apunte a otra cosa lo hace recolectable del mismo modo que lo hace el que no este almacenado en ninguna variable ya de entrada.
Dicho esto, he replicado tus modelos y en mi maquina pasa lo mismo. Pero parece que depende del valor _retornado_ por el hook mas que de nilificar una variable, ya que evitamos el leak tambien si hacemos simplemente esto:
(group.discussion.users << user) && true
Mi conjetura es que el valor retornado por el callback se esta quedando almacenado en algun lugar de AR y no puede recolectarse.
Razón llevas Xavier,
a esas horas de la madrugada uno ya no estaba demasiado fino como para ponerse a probar cosas, a ver si saco algo de tiempo esta semana y veo en más profundidad que está pasando, tal vez pueda caer algun parche…
Encantado de tenerte por aqui!
Opino igual que Xavier, no es un memory leak como tal: los callbacks deben devolver un valor, y en tu caso devuelves el array (cada vez más grande) de usuarios que están en la “discussion”, probando a devolver simplemente nil o false funciona sin problemas. Si no devuelvo false o nil la memoria empieza a crecer un mega cada par de segundos.
Viendo el código y sin conocer exactamente la gestión de memoria de Ruby y su recolector de basura voy a hechar la culpa a los closures que se generan durante la ejecución de los callbacks. Estoy pensando que, de alguna forma, los closures que se van formando en cada iteración se mantienen en scope, y el GC no los elimina, con lo que se queda un closure con 1 usuario, otro con 2, otro con 3, etcétera… al de las iteraciones tenemos unos 450.000 objetos User en memoria. No se cuanto ocupan en memoria un objeto ActiveRecord, pero 450.000 objetos son muchos objetos.
Creo que la moraleja es siempre devolver true o false en lo callbacks (true, false y nil deben ser valores compartidos en Ruby, por lo que no deben aumentar tanto el uso de memoria).