On 24-7-2015 00:23, conver...@gmail.com [firebird-support] wrote:
Thanks for your insightful response. FWIW, I would like to mention that,
in the same server, we have another database (same size ~7 GB) no one
connects to, it's a restore of the production database from January this
year. This
Hi there,
Can the connection errors in the log contribute to the increasing gap between
the OAT and NT?
Regards,
-Eduardo
snip
As you are using
FB TraceManager, it is a simple mouse-click via the context-menu in the
parsed gstat output to locate the OAT in the monitoring tables.
Thanks Thomas. I've located the OAT in the monitoring tables as you mention.
Can you please elaborate a bit on how to find the
Take at look at the HDD usage. Is HDD been used around 100% when slowly
appears?
On 24/07/2015 16:00, conver...@gmail.com [firebird-support] wrote:
Thanks Thomas. Today we had a performance problem about 3 hours ago,
we had to reboot the Windows server to solve it. Prior to the restart,
the
Thanks Thomas. Today we had a performance problem about 3 hours ago, we had to
reboot the Windows server to solve it. Prior to the restart, the OAT-NT gap was
120479. After the restart it was 33.
Interestingly enough, currently the gap is 354354 as I write this. That's
almost three times
Hi,
OAT is an active transaction. You can see it alive if you analyze MON$
snaphot (you can use trial of our FBMonLogger).
So, disconnects are not related with Next-OAT gap - because this gap is
caused by some open transaction which you can easily identify.
However, disconnects can lead
gstat output (normal performance):
-
Oldest transaction 18709808
Oldest active 18953295
Oldest snapshot 18851591
Next transaction 19520857
The large difference in Oldest Active and Next Transaction suggests that your
problem
On 23-7-2015 21:07, conver...@gmail.com [firebird-support] wrote:
Hi there, we have a 7 GB Firebird 2.5 database, running on FB Classic
2.5.2 64 bits on a Windows Server. This is a 64 bits Windows server with
24 CPU cores and 32 GB of RAM.
When the client connection count surpasses 200, the
Hi again,
Hi Eduardo,
[snip]
Firebird.conf:
-
DefaultDbCachePages = 1024
#FileSystemCacheThreshold = 65536 (commented out)
#FileSystemCacheSize = 0 (commented out)
Server environment:
--
CPU utilization: 11%
Memory utilization: 11
Hi Eduardo,
[snip]
Firebird.conf:
-
DefaultDbCachePages = 1024
#FileSystemCacheThreshold = 65536 (commented out)
#FileSystemCacheSize = 0 (commented out)
Server environment:
--
CPU utilization: 11%
Memory utilization: 11 GB (out of
Hi Mark,
Thanks for your insightful response. FWIW, I would like to mention that, in
the same server, we have another database (same size ~7 GB) no one connects to,
it's a restore of the production database from January this year. This database
works perfectly even when the production
Hi there, we have a 7 GB Firebird 2.5 database, running on FB Classic 2.5.2 64
bits on a Windows Server. This is a 64 bits Windows server with 24 CPU cores
and 32 GB of RAM.
When the client connection count surpasses 200, the database starts
freezing, I.E., opening a connection with
12 matches
Mail list logo
