[linux-l] Re: Ruby: sehr cool, aber laaaahm... wie geht's schneller?! - D?

Steffen Dettmer steffen at dett.de
So Aug 27 16:09:10 CEST 2006


* Kai Kuehne wrote on Sun, Aug 27, 2006 at 15:49 +0200:
> >Ich hab so einen Java-Service, der regelmässig mit "OutOfMemory"
> >abschmiert. Herrlich.
> 
> Apache Tomcat? :>

Nein, ein "standalone-Dienst". Läuft in einer JVM und speichert
Komponentenübergreifende Daten für eine bestimmte Zeit (zum Beispiel
Logeinträge). Die Daten werden über CORBA benutzt. Es werden
CORBA-Objekte erzeugt und vernichtet. Leider ist Java nicht so wirklich
CORBA-Compliant (zum Beispiel wird "null" nicht als CORBA::_nil
verarbeitet sondern schmiert ab, CORBA::_nil gibt es sogar absolut
/überhaupt nicht/).

Mit Testtools macht der Dienst problemlos Millionen Zugriffe (bis zu
knapp 100 parallel). Bei mehr Druck klemmt gern man das CORBA (blockt
oder 202/208 Exceptions, aber nur beim Client oder OutOfMemory, aber
seltener, wenn ich mich recht erinnere). In der Praxis kommen nach
hunderttausend Zugriffen schon erste OutOfMemory exceptions. Leider
leider kann es soooo viele Stellen geben, wo was falsch ist. Vielleicht
wird irgendwo irgendwas vom CORBA nicht richtig freigegeben oder so.

Ich hab mal für'n Test folgendes probiert:
1 starten
2 Testsatz mit z.B. 10.000 Zugriffen
3 gc starten
4 freien Speicher loggen
5 loop zu 2
Die Ausgabe von 4 schwankt, wurde aber nicht "gleichmässig" grösser.
Wenn man Schritt 2 auslässt, schwankt die Ausgabe von 4 immer noch.
Würde es steigen, könnte ich evtl. wenigestens die Operation aus dem
Testsatz isolieren, die zu Speicherlöchern führen könnte.
Netterweise bekomme ich OutOfMemory, wenn ich massiv parralel den
Testsatz laufen lasse (z.B. 100 threads). Das resultiert dann aber in
sehr viele threads im Testobject (weil die Datenzugriffe entkoppelt
werden müssen u.U. wegen Performance).

Richtig geil ist, dass im Fehlerfall eine Exception u.U. erst nach 10
Sekunden kommt und nicht "gleich". Der andere Service (der den Kram
benutzt) blockt damit 10 Sekunden und läuft in ein Protocol-Timeout
(naja, ist eigentlich noch viel komplizierter, egal), was wieder
umständlich gehandhabt werden muss.

Ich hatte schon überlegt, den ganzen Kram in C++ neu zu schreiben. Dann
unit tests von ganz unten (wie auch im Java), aber mit agressiven
Fehlererkennungsmassnahmen (meine C++ Debug-Object wissen z.B., ob sie
schon gelöscht wurden oder nicht).

Leider ist das multithreading dann mein Problem. Habe Angst, dass ich
dann Speicherlöcher gegen deadlocks und races tausche.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.




Mehr Informationen über die Mailingliste linux-l