Verfolgen von Speicherlecks in der Anwendung Ruby on Rails 3/Postgres/Apache Passenger

StackOverflow https://stackoverflow.com/questions/5369623

Frage

Hallo,

Wir haben kürzlich eine Anwendung auf Rails 3.0.4 (3.0.5 auf dem Online-Entwicklungsserver) aktualisiert.Die meisten Änderungen von 2.3.10 auf 3.0.4 waren auf veraltete oder veraltete Plugins und Gems zurückzuführen und konnten relativ einfach gelöst werden.Aber eines macht mich wahnsinnig:

Jede einzelne Webanfrage im Entwicklungsmodus führt dazu, dass der Serverprozess etwa 50–60 MB zuweist Mehr Speicherplatz als vorher.Diese Erinnerung ist nicht nach der Anfrage freigegeben, zumindest nicht alles davon.Nach 10–20 Anfragen war jede Ruby-Instanz überlastet 500 MB RAM, während unsere vorherigen Rails 2.3.10-Instanzen selten über 200 MB lagen.

Dies macht es unmöglich, unsere 1300 Tests durchzuführen, da die 4 GB RAM der Entwicklungsmaschine vor dem Ende der Tests voll sind.Es passiert nur im Entwicklungsmodus mit cache_classes = false.Wenn ich „cache_classes“ auf „true“ ändere, verbrauchen die Rails-Instanzen etwa 200 MB Speicher und bleiben dann dort.Bei Tests steigt die Speichernutzung jedoch auch mit „cache_classes = true“.

Ich habe ObjectSpace abgefragt und herausgefunden, dass mit jeder Anfrage etwa 3500 neue Proc, bis zu 50.000 neue Strings und 3000 neue Hashes und Arrays erstellt und nicht freigegeben werden.Diese Zeichenfolgen enthielten (nach dem Dump) meinen gesamten Quellcode, einschließlich Plugins und Gems, Dokumentation, Quellcodekommentare und Pfadnamen.(Warum?)

Um die Ursache dafür zu finden, habe ich Folgendes versucht:(Nach jeder Änderung habe ich die Apps mit gehämmert ab -n 50.)

  1. Ich habe eine erstellt neue Rails 3-Anwendung mit einer einzelnen Ressource und einem Controller und einer SQLite3-Datenbank. Die Speichernutzung begann bei 60 MB und blieb unter 80 MB.
  2. ich habe mich verändert 'sqlite3' zu 'pg' und verwies die neue Rails 3-App auf meine vorhandene Postgres-Datenbank. Die Speichernutzung begann bei 110 MB und stieg nicht über 130 MB an.(Nebenfrage:Warum verbraucht das Postgres-Gem so viel mehr Speicher als das SQLite3-Gem?)
  3. Ich habe meine kopiert Gemfile und Gemfile.lock von der kaputten Rails3-App zur Bare-Bones-App und lief Bundle-Installation. Keine Änderung, Der Speicher blieb bei etwa 115 MB, egal wie viele Anfragen gestellt wurden.
  4. Ich habe einen leeren „def FooController;“ erstellt.auf jeden Fall foo;render :text => 'foo' end;end“ in der kaputten Rails3-App. Die Speichernutzung wuchs langsamer, hörte jedoch nach Anfragen immer noch auf.
  5. Ich habe jede Route außer der FooController-Route gelöscht. Keine Änderung.
  6. Ich habe alle Edelsteine ​​außer den folgenden deaktiviert: pg, rails, aasm, will_paginate, geokit-rails3, koala, omniauth, paperclip. Keine Änderung.
  7. Ich habe jeden before_filter und after_filter in ApplicationController und alle unwesentlichen deaktiviert include in umwelt.rb.Ich habe auch boot.rb, Environment.rb und application.rb mit meiner einfachen Rails 3-App synchronisiert, mit Ausnahme von fünf relativ einfachen Beobachtern, die Dateien automatisch in /lib und filter_parameters laden. Keine Änderung.Jede neue Anfrage verbrauchte immer noch zusätzlich 10-50 MB RAM.

Wenn Sie eine Idee haben, was hier falsch läuft und wo der Speicherverlust liegen könnte, würde ich mich über jede Hilfe sehr freuen.Ich verwende Rails 3.0.4 unter OS X Snow Leopard, Rails 3.0.5 unter Debian Lenny und

Danke schön!

Näher kommen:

Ich habe jedes Plugin, jedes Juwel, jede Erweiterung und alles, was ich nicht persönlich geschrieben habe, entfernt, sodass meine Anwendung im Grunde nackt ist.Insbesondere habe ich diese Plugins entfernt: acts_as_list, acts_as_tree, asset_packager, forgot_password, fudge_form, fudge_scaffold, paperclippolymorph, query_trace, rails_upgrade, repeated_auto_complete-0.1.0, role_requirement, to_select, validates_url, and ym4r_gm.

Nun meine Bewerbung – nur der obige FooController funktioniert noch!- Startet mit 65 MB und überschreitet nie mehr als 75 MB RAM, selbst wenn man es mit Gewalt hämmert ab -n 1000 -c1 (1000 HTTP-Anfragen an /foo mit ApacheBench).Leider ist dies ohne die Plugins auch die einzige URI, die überhaupt funktioniert.

Nach einiger Recherche scheint es, dass eine Kombination zwischen den Plugins „Restful Authentication“ und „Acts As State Machine“ (AASM) den Speicherverlust verursacht.Siehe auch https://github.com/Satish/restful-authentication/issues#issue/11.Ich bin mir noch nicht sicher, warum, und die bloße Ausführung von „AASM einschließen“ in meinem Basisprojekt führt nicht von alleine zu einem Anstieg der RAM-Nutzung.

Ich werde weiter nachforschen.

Täter gefunden

Es ist AASM.In Rails 3 scheint es AASM::xxx-Objektinstanzen zu verlieren.sehen

Zweiter Täter gefunden

Es gab einen weiteren Speicherverlust in rspec.Dies machte meine Tests selbst nach der Entfernung von AASM fast unerträglich langsam, da zwei parallel laufende rspec-Aufgaben (using https://github.com/grosser/parallel_tests) hat am Ende fast 3 GB Speicher beansprucht.Sehen https://github.com/rspec/rspec-core/issues/#issue/321.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top