Tracing oder Debugging von File Operationen

[franz77]

Hi!

Wir haben keinen Write-Cache am Controller (Single-Controller mit 2x550GB 10k Disk)

Zweck der Analyse: Zu verstehen, was sich wie auf die Performance auswirkt. Es geht um 5250 Sessions, da nur dort diese Schwankungen auffallen.

Zu SQL: Ist mir alles klar. Bei SQL ist das Problem (siehe mein andere Topic) noch viel extremer wegen der Optimizer,... Deshalb hab ich die Applikation zum Vergleich auf RLA umgebaut. War zeitlich vertretbar und es hat mich einfach interessiert, was da an Performance rausgeholt werden kann.

Ich bin mit der Performance auch sehr zufrieden. Jetzt wollte ich noch klären, was hintern den seltenen, aber doch vorhanden Schwankungen steht.

Das mit dem SETOBJACC kann ich so nicht als Problem sehen, da es sich bei unserem Produktivsystem ja um ein reales Umfeld handelt ;-) Unsere DB passt locker in den Speicher.

Mir ist schon klar, dass es sich bei den beiden Topics von mir um theoretische Analysen handelt, aber meine Meinung nach ist es sinnvoll solche Charakteristiken wirklich zu verstehen. Es gibt genug Leute in unserer Branche die nur mit Halbwissen daherkommen.

LG

[Fuerchau]

Das kann ich schon verstehen. Allerdings habe ich auch schon Anwendungen gesehen, die deshalb langsam waren, weil sie einfach zu viele Daten überlesen müssen an Stelle sich eine View/LF/Index aufzubauen, mit dem man direkt nur die benötigten Daten liest.
Da ist eine Optimierung im Millisekundenbereich nicht so besonders zielführend.

Und eine DB, die komplett in den Speicher passen soll erlebt man da auch eher selten.
Ggf. haben deine Zugriffszeiten mit dem eigentlichen DB-Zugriff gar nichts zu tun sondern mit dem Verdrängungswettbewerb der Non-DB-Seiten. M.a.W., das Nachladen von Programmcode ist die Ursache, da zu viel Speicher durch den SETOBJACC-Pool blockiert ist.

Hast du denn mal komplett ohne SETOBJACC getestet?