Unlokalisiertes Performanz-Problem

Hallöchen,

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?

Hi,

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…

Hi!

(Ich sehe es mal aus Oracle-Sicht)

  1. Indizes, Constraints usw. ausschalten/löschen
  2. Tabelle laden/befüllen
  3. Indizes, Constraints usw. einschalten und neu aufbauen/erstellen

Was kann noch sein:

  • Storage-Parameter (PCTFree, PCTUsed, etc.)
  • Index-Tabelspace (auf selber Platte?)
  • Zu hoher SGA-Wert
  • (Archive-)Log-Files zu klein/„schlecht“ definiert

Viel Spaß beim Probieren :wink:

Grüße,
Tomh

Hi!

Ziemlich zeitgleich :wink:

Was mir durch den Kopf geht sind ist die Identifikation
innerhalb der Tabelle bei Eintragen - deswegen Schlüssel und
Index.

Ziemlich selber Gedankengang.

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.

DAS habe ich vergessen: COMMIT!!
Wie schaut’s mit dem Rollback-/Undo-Segment aus??

Grüße,
Tomh

Hi!

(Ich sehe es mal aus Oracle-Sicht)

  1. Indizes, Constraints usw. ausschalten/löschen
  2. Tabelle laden/befüllen
  3. Indizes, Constraints usw. einschalten und neu
    aufbauen/erstellen

Hi Tom,

Darf ich fragen, was den dies aus deiner Sicht bringen würden / kann / soll ?

Gruss

Hallo,

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 ?

Gruss

Hi!

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.

Hallo Tom,

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…

Gruss

Gruss

Hallo!

jedenfalls
würd ich nicht im laufenden Betrieb Indizies und Constraints
disablen…

Ähem, mMn ist dieses „Masseninsert“ eine „außerbetriebliche“ Aktion, bei der die DB zumindest exklusiv gemountet wird.

Aber für den laufenden Betrieb hast Du natürlich vollkommen Recht.

Grüße,
Tomh

Danke erst einmal für die Antworten.

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!

Gruß und Danke,
Michael