Firebird: welche Architektur ist installiert?

[ADelph]

Moin,

ich würde gern bei einem Kunden die firebird.conf optimieren, bzw. eine optimierte Version anbieten - da gibt es ja viele Anregungen. Dazu müsste ich aber wohl wissen, welche Architektur installiert wurde (Classic, SuperClassic, SuperServer). Der Kunden weiß nichts über die Installation und möchte auch nicht, dass ich Firebird neu installiere (dafür hat der einen externen Admin - der ist etwas 'sperrig', um es mal so auszudrücken).

Gibt es einen Weg, die Architektur herauszufinden? Mir ist keiner eingefallen...

Danke schon mal!

[Delphi.Narium]

Eventuell:
https://stackoverflow.com/questions/...ecture/1927269

https://ib-aid.com/en/articles/how-t...ith-sql-query/

[IBExpert]

von wo willst du das denn herausbekommen?

unterscheidung per sql zwischen superserver+superclassic und classic ist einfach

select count(distinct mon$attachments.mon$server_pid) from mon$attachments

wenn mehr als 1 dann classic, sonst superserver oder superclassic

bei superserver heisst der prozess fbserver, bei allen anderen fb_inet_server
(es sein denn, der installierte wurde einfach umbenannt, was auch mal vorkommt
zum beispiel in unserem freien Firebird IBExpert Benchmark)

per sql unterschied zwischen superclassic und super wüsste ich aber gerade auch nicht,
versprech dir aber nicht zu viel von den diversen conf files (vermutlich die von ibsurgeon)

Unter extreme High Load auf lahmen gurken kann das was bringen, aber sonst kannst du dir auch
einen turbo Aufkleber ans gehäuse kleben, das bringt genau so viel (Die default werte
von Firebird sind mit Ausnahme vom default db cache pages beim *classic schon sehr gut)

[hoika]

Hallo,
das sehe ich auch (fast) auch so wie Holger.

Fast heißt: page_size beim Superserver auf 10.000 (für die konkrete DB) setzen, bringt doch schon was.

Aber: Mehr bringt z.B.
die Nutzung einer SSD (Hardware)
Optimierung der Querys:
- Indizes
- Select Count(*) ersetzen
- Select Feld1,Feld 2 statt Select *
- Prepared Queries
- explizites Transaktions-Handling
usw ...

Also einfach mal per DBMonitor (bei Devart-Komponenten) die eigene Anwendung
auf langsame Queries und oft (unnütz oft) ausgeführte Queries prüfen.

[IBExpert]

Oder noch besser per trace api auf die suche nach lahmen sqls gehen, weil du auf dem weg
auch trigger gedöns usw siehst und je nach einstellung auch index plan usw.

War schon thema in einer Stammtisch Session von mir , aber vielleicht ist die anwendung ja schon pefekt ;-)

cache buffer leg ich immer lieber in der db selber fest (in ibexpert services -database properties oder mit gfix)

Das überschreibt den Wert aus der conf