Fehler in Suche

[C3D]

Hallo,
ich habe, wie shcon woanders erwähnt, sehr große Datenbestände. In einer Entität mit ca. 3,5 mio Einträgen funktioniert die Suche noch, langsam, aber sie funktioniert.
Diese Entität habe ich nun auf mittlerweile 5,5 mio Einträgen aufgeblasen und die Sucher versagt. Nach einem Klick auf die Suche (ohne Einschränkung) wird das layout zwar ausgegraut und die Prozessorlast der DB geht auf 100% bis dann kurz vor Ende der Suche der Javaprozess sich 100% greift. Im Client wird aber kein Ergebnis angezeigt sondern wieder die leere Suchmaske.

Wenn ich die Suche einschränke auf weniger Ergebnisse, funktioniert es. Im Log auf dem Server ist kein Fehler zu erkennen.

Gruss

Jan

[Nuclosian]

Zitat des referenzierten Artikels:

Hallo,
so langsam fangen wir an, extrem große Datenmengen in Nuclos zu importieren.

Bei einer Entität (Zielgröße ca. 11-12 mio Datensätze) haben wir knapp 600.000 zum testen importiert. Dabei zeigt sich, das beim ausführen der Suche über alle Datensätze hinweg (full table scan) es sehr lange dauert (ca 30 sec auf unserem Server), bis das Ergebnis vorliegt. Wenn dies über alle 11-12 mio gemacht würde, würde es sicher eine halbe Ewigkeit dauern.

Gibt es Pläne auf Seiten der Entwicklung dies zu ändern bzw. zu beschleunigen?
Kann man es irgendwie einstellen, das man keine „full table scan“ Suche ausführen kann?

Gruss

Jan

[Nuclosian]

Hallo,

die Performance im Nuclos Client sollte durch grosse Datenmengen grundsätzlich nicht beeinträchtigt sein, da der Client immer nur chunkweise mit Daten versorgt wird (erst beim Runterblättern im Suchergebnis wird chunkweise nachgeladen). Das Problem ist also eher im Server zu lösen.

Auch der Nuclos Server holt sich von der Datenbank nur die Chunks (je nach verwendeter DB ROWNUM-, LIMIT-, TOP-Clause). Das stimmt allerdings nur mit einer Einschränkung: Es werden zwar nur die Dateninhalte des Chunks in das Suchergebnis geladen, allerdings werden beim ersten Aufbau des Suchergebnisses aus verschiedenen Gründen sämtliche IDs aller Datensätze geholt. Diese Einschränkung ist historisch bedingt, eigentlich heute nur noch als Fehler zu betrachten und steht bereits auf der Änderungsliste. Die Ursache für vorliegendes Performanceproblem dürfte das aber nicht sein.

Das Problem ist vermutlich eher in der erlaubten Flexibilität der Suchfunktionen in Nuclos zu suchen. Da man Einschränkungen auf beliebige Spalten (insbesondere mit Wildcards) vornehmen kann (aber eine Indizierung aller Spalten in der DB wenig Sinn macht), lassen sich „full table scans“ kaum vermeiden. Eine Indizierung von Referenzspalten einer Entität macht der Entitätenwizard übrigens standardmässig, eine Indizierung weiterer Spalten kann ebenfalls über den Entitätenwizard erfolgen(Erweiterte Einstellungen). Um das einzuschränken, könnte man eine Suchmaske mit einer geringeren Menge an angebotenen Suchspalten erstellen (welches Layout für die Suche herangezogen wird, lässt sich über die Verwendung im Layout steuern).

Gleiches gilt für die Sortierung im Suchergebnis. Da man nach jeder Spalte sortieren kann, ist die chunkweise Einschränkung der Ergebnismenge für den Datenbankserver irrelevant und nutzlos, da er trotzdem alle Daten verarbeiten muss, um die Sortierung zu erreichen.

Wir schlagen folgende Massnahmen vor:
a) Wenn die Antwort ab einer bestimmten Datenmenge ganz versagt, wäre der erste Vorschlag, den Speicher, der der Datenbank zur Verfügung gestellt wird, sowie den Speicher, der dem Tomcat-Javaprozess zur Verfügung gestellt wird, zu erhöhen. Möglicherweise ist dieser für die zu verarbeitenden Datenmengen zu niedrig angesetzt. Eine Vergrösserung der Hardware und eine Verbesserung der physikalischen Datenbankstruktur (z.B. Partitionierung) wären weitere Möglichkeiten.
b) Nächster Ansatz wären datenbankspezifische Optimierungsmethoden. In Oracle gibt es mE beispielsweise einen Buffer Pool, dem man sagen kann, dass er eine bestimmte Tabelle vollständig im Speicher halten soll.
c) Man sollte die vom Nuclos Server abgesetzten Statements in der DB protokollieren und die Ausführungszeit in Nuclos mit der Ausführungszeit des SQL-Statements direkt auf der DB (SQL-Fenster o.ä.) vergleichen (d.h. wo geht eigentlich die Zeit verloren? welche Statements genau dauern eigentlich so lang?)

Auch sollte man vielleicht über ein fachliche, generelle Einschränkung der Datenmengen über indizierte Felder nachdenken. Sind z.B. die Daten älterer Jahre typischerweise nicht mehr relevant? Greifen bestimmte User immer nur auf bestimmte Datenmengen (z.B. je nach PLZ, Zuständigkeit, etc.) zu? Dafür könnte man das seit 2.7.4 zur Verfügung stehende Feater „Zwangsfilter“ nutzen (je User und Gruppe einstellbar in der Suchfilteradministration) und die Spalten, auf denen man dort einschränkt, in der DB indizieren.

Ach ja: Gibt es berechnete Attribute in der betroffenen Entität? Wir hatten schon Fälle, in denen wir Antwortzeiten von Minuten auf Sekunden heruntergebracht haben, indem wir einfach nur einige berechnete Attribute eliminiert (und die entsprechende Anforderung durch eine benutzerdefinierte View ersetzt) haben. Zumindest bei Oracle (bei anderen DBs weiss ich es nicht) scheint es so zu sein, dass die den berechneten Attributen zugrundeliegenden Funktionen immer aufgerufen werden – unabhängig davon, ob sie Bestandteil der Ergebnisspaltenauswahl sind oder nicht (vermutlich weil sie Exceptions werfen könnten und Oracle das prüfen will).

Zu guter Letzt: Die Suchabfragen laufen in Nuclos immer gegen die Views der Entitäten (wegen der Anzeige der Referenzfelder im Suchergebnis), d.h. es werden momentan Joins durchgeführt, die vielleicht gar nicht benötigt werden, weil manche Felder evtl. nicht Bestandteil des Suchergebnisses sind. Auh hier ist eine Verbesserung der Implementierung geplant, durch die die Entitätenviews durch dynamisch generierte Adhoc-SQL-Statements ersetzt werden – abhängig von der Auswahl der Suchergebnisspalten. Gerade wenn Ihre Entität viele Referenzfelder beinhaltet, und die referenzierten Entitäten viele Datensätze, könnte das ebenfalls eine mögliche Ursache sein.

Grüsse,
nuclosian

[C3D]

Hallo,
die betroffene Entität enthält nur 4 Attribute: Name, Vorname, Geburtsdatum, E-Mail (UNIQUE)

Keine Referenzen, keine berechneten Felder. Wir werden das mal genauer analysieren und den Speicher anpassen. Vll sehen wir dann schon wo da etwas zu optimieren ist.

Danke und Gruß

Jan

[Nuclosian]

Hallo,

ich habe das Szenario (auf einer Postgres-DB) nachgestellt (die Entität nachgebaut und Testdaten generiert) und habe folgendes Verhalten mit angegebener Hardwareaussstattung:

800.000 Datensätze: Suche ohne Einschränkung: ca. 5 Sek

1,6 Mio Datensätze: Suche ohne Einschränkung: Fehlerhaftes Verhalten wie bei Ihnen (Rückkehr ohne Ergebnis) nach 25 sek. Ursache ist lt. Console des Servers „Out of memory“, wie vermutet. Speicher (java max heap space) des Tomcat angepasst auf 256MB (-Xmx256M).
1,6 Mio Datensätze: Suche ohne Einschränkung: ca. 9 Sek (linearer Anstieg)

3,2 Mio Datensätze: Suche ohne Einschränkung: Fehlerhaftes Verhalten wie bei Ihnen (Rückkehr ohne Ergebnis) nach 1min. Ursache ist lt. Console des Servers „Out of memory“, wie vermutet. Speicher (java max heap space) des Tomcat angepasst auf 512MB (-Xmx512M).
3,2 Mio Datensätze: Suche ohne Einschränkung: ca. 18 Sek (linearer Anstieg)

6,4 Mio Datensätze: Suche ohne Einschränkung: Fehlerhaftes Verhalten wie bei Ihnen (Rückkehr ohne Ergebnis) nach 1,5min. Ursache ist lt. Console des Servers „Out of memory“, wie vermutet. Speicher (java max heap space) des Tomcat angepasst auf 1024MB (-Xmx1024M). Dann Speicherproblem im Client (Fehlermeldung „Out of memory“). Speicher (java max heap space) des Clients ebenfalls angepasst auf 1024MB (in /webapps/WEB-INF/jnlp/jnlp.xsl).
6,4 Mio Datensätze: Suche ohne Einschränkung: ca. 1 Min. (schlechter als linear, Analyse der Ursache steht noch aus)

Für alle Fälle gilt:

Ist das Suchergebnis einmal da, geht Runterblättern praktisch in Nullzeit (was man aufgeben würde, wenn man den obigen Umstand, dass immer alle IDs geladen werden, ändert – man hat also immer einen gewissen trade-off).

Sucht man mit Einschränkung (auf nicht indizierter Spalte), kommt das Ergebnis wesentlich schneller (ebenfalls linear). Wesentlicher Knackpunkt bei grossen Datenmengen scheint also der Umstand zu sein, dass sämtliche IDs mitgeladen werden.
z.B. nachname wie ‚*an*‘ liefert in meinem Fall ca. 700.000 Datensätze und dauert etwa 15 sek.
z.B. nachname wie ‚*ane*‘ liefert in meinem Fall ca. 65.000 Datensätze und dauert etwa 7 sek.

Bei 6,4 Mio Datensätzen hatte ich hin und wieder das Phänomen, dass die ersten Suchen noch funktionierten, irgendwann weitere Suchen in derselben Maske wieder ein Out of memory produziert haben. Weitere Suchen in neu aufgemachten Maske hingegen funktionierten wieder. Das deutet daraufhin, dass eine geöffnete Maske erst beim Schliessen benötigten Speicher zuverlässig wieder freigibt (obwohl es in diesem Fall früher sinnvoll wäre). Dem werden wir mit einem Memory Profiler weiter auf den Grund gehen.

Grüsse,
nuclosian

Attachments:

• Screen_shot_2011_03_29_at_12.png
• Screen_shot_2011_03_29_at_11.png

[Autor]

Beiträge