Problem mit Performance

Hallo Liste,

Ich fange gleich an, weil das Problem ziemlich dringend ist. Ich bin
Administrator einer RoR-Seite, habe aber dennoch leider keine Erfahrung
in der Programmierung in ruby.
Es handelt sich um 2 Root-Server.

Der Erste:
Quad-Core, 2Gig Ram. Raid …, fungiert als Apache-Proxy und leitet
Anfragen an den zweiten Root-Server weiter.

Der Zweite:
Dual Core: 4Gig Ram, (Debian) ist der eigentliche rails-Server. Darauf
laufen 4 Mongrel (V 1.1.5) Ports im Produktiv-Modus

Es kommt seit kurzem vor, dass sich der Mongrel voll Speicher frisst und
die Website nicht mehr erreichbar ist. ( Server 1 schickt dann 500 raus)
Dies geschahr erst nach einem Codeupdate auf dem Server. Nach einem
Neustart des Clusters, geht die ganze Sache wieder ein paar Tage gut
usw.

Nun meine Frage. Kann ich noch irgendeine Sache administrativ
einstellen, damit dies nicht mehr vorkommt? Kann das ein
Programmierfehler sein?

Viele Grüße

Mark

Hi,

Nach einem Codeupdate, is ja wohl klar dass da jemand Unfug
programmiert hat. Aber ohne Code zu sehen kann man dir da
auch nicht helfen.
Vllt nehmt ihr aber auch für’s caching den memory_store statt einem
dediziertem memcache oder filestore.
Das wird in config/environments/production.rb mit config.cache_store
definiert.

ciao, tom

Am 08.11.2008 um 22:48 schrieb Mark:

Nun meine Frage. Kann ich noch irgendeine Sache administrativ
einstellen, damit dies nicht mehr vorkommt? Kann das ein
Programmierfehler sein?


Thomas R. “TomK32” Koll || http://tomk32.de || http://ananasblau.com
just a geek trying to change the world
Skype: TomK32 || Mail: [email protected]
About Thomas R. Koll | Flickr

Ich glaub, sie nehmen nicht mal memcache (meinst du memcache.d?) sondern
eher filecache. Gibt da so ein Verzeichnis im TMP was man mit rake
leeren kann. Ihr wisst da sicherlich besser Bescheid als ich. Code kann
ich natürlich ohne Einwilligung leider nicht veröffentlichen. Allerdings
gibts seit neuestem ein AJAX-Feature, welches den Server alle 3 Sekunden
abfragt.
Ich kenne zwar AJAX aus anderen Umgebungen, kann mir aber nicht
vorstellen, das es bei einer Skriptsprache zu Speicherüberläufen kommt.
Oder verhält sich der mongrel anders als, sagen wir mal, apache + mod_php?

danke

Mark

Thomas R. Koll schrieb:

On Saturday 08 November 2008, Mark wrote:

Allerdings
gibts seit neuestem ein AJAX-Feature, welches den Server alle 3
Sekunden abfragt.

Glückwunsch, du hast die Ursache gefunden. Ziemlich wahrscheinlich
jedenfalls. Wenn du die Entwickler nicht davon überzeugen kannst, den
Code unter halbwegs realistischen Bedingungen zu testen,
einschliesslich der Auswirkungen auf die Prozessgröße, dann hast du als
Admin nur noch die Möglichkeit, zu verhindern, dass die Prozesse so
riesig werden. Ich nehme an, ihr verwendet irgendein System, dass die
Gesundheit der Anwendung überwacht. Schau mal, ob du darin Regeln
anlegen kannst, die Prozesse zwangsweise beenden, wenn sie zu groß
werden.

Michael


Michael S.
mailto:[email protected]
http://www.schuerig.de/michael/

Am 08.11.2008 um 22:58 schrieb Mark:

Allerdings gibts seit neuestem ein AJAX-Feature, welches den Server
alle 3 Sekunden abfragt.

Das sollte es eigentlich nciht sein.
Aber Speicherlücken sind oft eklig und schwer zu finden.
Du hast indixes auf allen wichtigen Spalten in der Datenbank?

Es lohnt sich auch mal das production.log nach den häufigsten
controllern und actions zu filtern. In Relation zur durchschnittlichen
runtime pro request hast du eine hilfreiche Statistik.
Dann weiß man auch gleich was denn unbedingt optimiert werden sollte.

ciao, tom


Thomas R. “TomK32” Koll || http://tomk32.de || http://ananasblau.com
just a geek trying to change the world
Skype: TomK32 || Mail: [email protected]
About Thomas R. Koll | Flickr

Danke für eure Hilfe,

Indizes sind gesetzt. Die Responsezeiten sind immer sehr gut (ein paar
tausendstel Sekunden). Hab ja keine Ahnung vom Code, kann also auch
nicht entscheiden welche Controller nicht so häufig vorkommen sollten.
Ich weiß zwar was MVC ist, aber mit RoR, kenn ich micht wie gesagt,
nicht aus.

ich werde das mal so weitergeben.

Mark

Thomas R. Koll schrieb: