| Subject | Re: [firebird-support] Re: firebird.conf for HP Proliant Server |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-06-16T23:30:51Z |
At 11:28 PM 16/06/2008, Haija wrote:
It is noted that, although the ODS is 11.0, this database was not created by Firebird 2. "Dialect 1" tells us that this is a VERY old database, that was created by an InterBase 5.6 or older engine. Amongst other things, this makes 8 years of improvements in Firebird unavailable. Possibly the old database was never upgraded due to incompatibility with whatever is being used as the database access layer. We still don't know. You owe it to yourself to find out.
You have already told us that each instance of the client application is writing data across to the server every 30 seconds. Why would you expect not to see writes?
If you are running tools in the background constantly, that do expensive operations, then you can expect performance to go down. On the other hand, unfortunately there are lots of old Delphi applications out there that use techniques which are very bad for a database engine designed for multiple concurrent users over network connections.
If you do this, you must make sure that your firebird.conf parameter DefaultDbCachePages has a much lower setting than the default 2048 that is set for SS. This is because each Classic process has its own private cache, not a shared one as in SS. I suggest 128. The server will have to be stopped and restarted after this change.
But keep in mind that it is the SAME database engine. If your applications are doing horrible things that cause undesirable writes, it makes no difference whether you are running Classic or SS.
Please trim your messages!
^ heLen
>Here the gstat:At this level, the header stats look very good. A next step would be to get the index stats using gstat -i. Use the IB 6 beta Operations Guide (or The Firebird Book, if you have it) for the syntax to output the results to a text file. The index stats can be useful for identifying indexes that don't perform well.
>
>D:\Database>gstat -h msup.fdb
>
>Database "msup.fdb"
>Database header page information:
> Flags 0
> Checksum 12345
> Generation 21260075
> Page size 4096
> ODS version 11.0
> Oldest transaction 21260066
> Oldest active 21260067
> Oldest snapshot 21260067
> Next transaction 21260069
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 0
> Implementation ID 16
> Shadow count 0
> Page buffers 0
> Next header page 0
> Database dialect 1
> Creation date Feb 13, 2008 20:13:13
> Attributes force write
>
> Variable header data:
> Sweep interval: 20000
> *END*
It is noted that, although the ODS is 11.0, this database was not created by Firebird 2. "Dialect 1" tells us that this is a VERY old database, that was created by an InterBase 5.6 or older engine. Amongst other things, this makes 8 years of improvements in Firebird unavailable. Possibly the old database was never upgraded due to incompatibility with whatever is being used as the database access layer. We still don't know. You owe it to yourself to find out.
>The app is written in Delphi.That doesn't tell us what the database access layer is. If you have the source code, get the names of the data access components.
>Again: When i start a query from the client, i see a lot of "WritesAnd, AGAIN, *we* have no way to tell why this is so. It is quite likely that the tool you are using, or the application code, is creating temporary structures and making writes to these structures.
>to database". I expect to see "Reads from database". For me not to
>explain.
You have already told us that each instance of the client application is writing data across to the server every 30 seconds. Why would you expect not to see writes?
If you are running tools in the background constantly, that do expensive operations, then you can expect performance to go down. On the other hand, unfortunately there are lots of old Delphi applications out there that use techniques which are very bad for a database engine designed for multiple concurrent users over network connections.
>Shall i install the ClassicServer for Tests on the MultiProcessorIt is a separate issue. The architectural difference between Classic and Superserver is that SS is a single process that spawns threads for client connections (and other tasks), whereas Classic creates one process for each client connection. A 32-bit process on Windows is limited to a maximum of 2 GB of RAM and Firebird's threading model does not support SMP. Therefore, if the problems with SS are related to inadequate RAM then it would be worthwhile to test Classic and see whether the availability of extra RAM improves anything.
>Server or is this a bad idee?
If you do this, you must make sure that your firebird.conf parameter DefaultDbCachePages has a much lower setting than the default 2048 that is set for SS. This is because each Classic process has its own private cache, not a shared one as in SS. I suggest 128. The server will have to be stopped and restarted after this change.
But keep in mind that it is the SAME database engine. If your applications are doing horrible things that cause undesirable writes, it makes no difference whether you are running Classic or SS.
Please trim your messages!
^ heLen