folgendes Problem:
Eine eigentlich relativ simple und verhältnismäßig kompakte Applikation schreibt Daten in eine Datenbank. Soweit Standardprozedere.
Als Fallbeispiel:
Insert into Personen (ID, Vorname, Nachname) values (‚123‘,‚Frank‘,‚Müller‘);
Aber:
Schon bei 50k Datensätzen sinkt die Performanz von rund 300 Queries/sek auf c.a. 200 Q/s.
Im Bereich, um den es geht (200k Datensätze) liegt die Performanz schon bei 3 Queries pro Stunde(!).
Der Tablespace war auf 32MB mit einer Erweiterungsgröße von 8 MB festgelegt, aber selbst die 200k Datensätze liegen noch weit unterhalb dieser Grenze (etwa 20 MB).
Nachdem wir mySQL selbst als Fehlerquelle ausgeschlossen hatten (Oracle läuft zwar etwa 10x so schnell, aber 30 Queries/h ist auch noch Mist für 200k Datensätze) haben wir mal die CPU-Auslastung angeschaut, die war immer zwischen 10% und 20% unterwegs.
Hibernate als Fehlerquelle scheint auch raus zu sein, da das gleiche Problem besteht, wenn man ins JMeter direkt das SQL-Statement reinfüttert.
Der RAM der Maschine ist relativ ausgelastet, aber ~100MB sind im Normalfall frei.
Jetzt die Frage: woran kann es noch liegen, dass bei so kleinen Datenbeständen die Performanz schon dermaßen in die Knie geht - sowohl bei ORA als auch mySQL?
genau kann ich es leider auch nicht sagen wo das ganze Problem liegt.
Aber wenn sowas schnell gehen soll, würde ich erstmal das ganze auf Stored Procedures umstellen, falls noch nicht getan.
Wie sieht denn die Tabelle eigentlich aus?
Spalten - Index - Primärschlüssel etc.
Was mir durch den Kopf geht sind ist die Identifikation innerhalb der Tabelle bei Eintragen - deswegen Schlüssel und Index.
Und mir geht noch im Kopf rum das du nach den inserts in der Stored Procedure die Session abschließen könntest per commit bzw. go.
Keine Ahnung ob ich in die richtige Richtung denke…
Du wirst nachschauen müssen, was „wirklich“ passiert bei diesem Insert. Mach doch mal einen Trace für das Statement und poste es hier. Evtl werden noch Trigger ausgelöst ?
Darf ich fragen, was den dies aus deiner Sicht bringen würden
/ kann / soll ?
Performance.
Er ist nach jedem Einfügen eines Datensatzes nicht ständig mit dem „Nebenkram“ wie Constraints und Indizes beschäftigt.
Wir haben damit zumindest Performance-Gewinne von über 50% erreicht (statt 13h waren’s nur noch knappe 6h - inkl. Neuaufbau der Indizes und Constraints).
Grüße,
Tomh
PS: Die reingeladenen Daten müssen aber definitiv sauber sein, sodaß keine Probleme mit diversen Constraint-Verletzungen auftauchen.
Bei einem Dataload ist diese Vorgehen richtig, wir machen dies selbst so. Aber so wie ich den OP vestanden haben, sind dies „normale“ Transaktionen während des Betriebs, und da wäre deine vorgehensweise eher nicht möglich, denke ich, jedenfalls würd ich nicht im laufenden Betrieb Indizies und Constraints disablen…
Trigger: Problem trat sogar auf, als überhaupt keine Trigger oder SP’s aktiv waren.
Rollback-Segment: War deaktiviert.
Wir hatten sogar soweit probiert, dass die Indizierung komplett deaktiviert war - und die Beispieltabelle hatte nicht mal Schlüssel, aber das hat nicht viel geändert.
Mit dem „dieselbe Platte“ ging es schon in die richtige Richtung, dazu sollte man jedoch wissen, dass unsere Entwicklungsmaschine eine Gurke ist, die im Prinzip „alles auf eine Platte“ schaufelt, also Betriebssystem, Sourcecode, Datenbank, Fileystem… nur halt in verschiedenen Partitionen.
Am Schluss hat sich herausgestellt, dass es tatsächlich primär daran lag, dass die Datenbank selbst (also nicht mal das Schema) absolut suboptimal konfiguriert war, da hat tollerweise eine Kollegin ein Analyse-Tool ausgegraben wo dann Dinge rauskamen wie Puffer deaktiviert, Cache im Kilobyte-Bereich und so weiter.
Gab einen Vermerk im Lessons-Learned: Manche Sachen sollte man nicht blind dem DBA überlassen, sondern prüfen!
