ODBA Verbesserungen

Aus dem Mail von Hannes Wyss an die ywesee interne Liste:

Der Aktuelle commit der ODBA
beinhaltet mehrere Verbesserungen und zwei Bugfixes, die insgesamt die
langfristige Memory-Auslastung kontrollieren sollen. Endgültige
Bestätigung werden wir erst aus dem online-Dauerbetrieb erhalten.

  • der Cleaner-Thread im ODBA.cache läuft mit höherer (normaler) Priorität und häufiger, dafür aber für kürzere Zeit. D.h. konkret dass im Zeitraum von ca 10 Sekunden jeweils 500 Objekte überprüft und gegebenenfalls aus dem Cache gelöscht werden.
  • Bugfix: wenn Collection-Elemente einzeln aus der DB geladen werden, werden sie neu auch im Cache registriert.
  • CacheEntry führt darüber Buch, welche Objekte auf ein bestimmtes anderes Objekt zugreifen. Neu wird dies nicht mehr direkt über die Referenz gemacht, sondern über odba_id/object_id – damit ist diese Information garantiert kein Hindernis für die GC mehr – bis jetzt wurden die Referenzen jeweils rechtzeitig entfernt und ‘sollten’ auch keine Rolle gespielt haben, jetzt gibts dafür eine Garantie.
  • Ebenfalls aus CacheEntry entfernt wurde der @collection-Eintrag. Beim Speichern einer Collection ist es notwendig zu wissen, welche Elemente der Collection bereits in der Datenbank liegen, welche gelöscht werden müssen, und welche neu hinzukommen. Dies wurde bis jetzt mit eben diesem @collection-Eintrag gelöst. Neu werden die bestehenden Daten jeweils direkt von der DB bezogen.
  • Bugfix: die Ausgabe einer Fehlermeldung führte bei einer speziellen Konstellation zu einem Memory-Spike. (konkret: Narcotic#to_s ist abhängig von den Substanzen in Narcotic@substances. Bei einigen instanzen von Narcotic war das entsprechende Objekt aber gelöscht oder nie gespeichert worden. Dies sollte eigentlich mit einer Fehlermeldung vermerkt werden; da die Fehlermeldung aber ODBA::Stub@container.to_s als Bestandteil hatte, ergab sich ein unendlicher Loop von Exceptions) Dieser Bug nahm die Hälfte der 3 Tage in Anspruch. Ich konnte ihn schlussendlich nur dank dieses Tools finden.

Observations about ODBA, Ruby 1.8.6 and ODDB.org

1. I’m following the memory consumption of our application ODDB.org, Ruby 1.8.6 and our OpenSource RAM-Cache-Management Software ODBA. When we have over 300 open Sessions it seems that that the GC takes far longer then 20 secs to do its job. At around 390 simultaneously open sessions my “Fasterfox” measured way over 60 sec until the application ‘returned’ in a responsive way to the user.

2. Somehow I also have the feeling that when we use more memory the GC runs faster. But that is just an assertion.

3. You can watch our memory consumption here.

4. One thing I can also say for sure is that Ruby 1.8.6 can deal with tons of more traffic. Somehow the GC has really been optimized.

5. We now know that we have some duplication of objects that we do not want to have. The objects have been identified but we do not yet know where they come from.

Some more observations on Ruby 1.8.6 and ODDB.org

Ok, since we installed Ruby 1.8.6 the GC (Garbage Collection) does not take 50 secs (or more) to do its job when our Application is around 2 GB big. The time is down to about 20 secs – and – the Speed at witch the queries are delivered is up up up! Thank you for fixing this, Dear Ruby Community.

Update: I must actually elaborate a bit. The GC used to force us to do a restart because it took such a long time to do its job. With Ruby 1.8.6 the memory usage still “grows” throughout the day. This just has less impact on our Service as we have 12 GB of memory on your server. We still want to find out what increases the memory consumption of our software, though. We owe that answer to Ryan Davis.