[firebird-support] Start service of Firebird 2.5 in Centos 7

[Carlos Mazariegos carlos.mazarie...@umg.edu.gt [firebird-support]]

Hello:


I can not start the service Firebird 2.5 on Centos 7. Please if someone
can tell me how.


thank you
--


Carlos Mazariegos
/Dirección de Desarrollo/


Universidad Mariano Gálvez
3a. Av. 9-00 Zona 2 · Int. Finca El Zapote
Tel: *24111800 Ext. 1166 y 1290* · Fax: *Ext. 1166*

carlos.mazarie...@umg.edu.gt  · 

www.umg.edu.gt 

Re: [firebird-support] FB on LAN

[Hugo Eyng hugoe...@msn.com [firebird-support]]

Hello Mark.

I changed the firebird.conf by another one and restarted the server.

Now my string connection 192.168.0.158:C:\DIR1\BASEDIR\MYDATABASE.FDB is 
working.


I compared both firebird.conf and found two differences:

1) In the line near

# Remove protection against opening databases on NFS mounted volumes on
# Linux/Unix and SMB/CIFS volumes on Windows.

that appears in original

# ***WARNING*** ***WARNING*** ***WARNING*** ***WARNING***

in my firebird.conf the line was brioked, like

# ***WARNING*** ***WARNING**
* ***WARNING*** ***WARNING***

2)  There was difference in this line too, but the lines are commented.

#CpuAffinityMask = 1

#CpuAffinityMask = 192

I am sure this could not cause problems, but the item 1 could? I think 
it is not pr
Em 08/04/2016 04:12, Mark Rotteveel m...@lawinegevaar.nl 
[firebird-support] escreveu:


On 7-4-2016 20:54, Hugo Eyng hugoe...@msn.com [firebird-support] wrote:
> Hello Mark.
>
> I was like you showed 192.168.0.158:C:\DIR1\BASEDIR\MYDATABASE.FDB
>
> Than I changed from FB 32 to FB 64 and it stopped working. After that,
> after that even turnning to FB 32 it doesn´t work using this structure.
> I only works
> using \\192.168.0.158\C:\DIR1\BASEDIR\MYDATABASE.FDB or
> C:\DIR1\BASEDIR\MYDATABASE.FDB

In your first question your connection string was:

192.168.0.158:\DIR1\BASEDIR\MYDATABASE.FDB

Note the absence of _C:_ This means you are connecting with a relative
path. And the root of this path depends on the configuration (and maybe
on the user running Firebird).

> I open the 3050 port in FW. But it keep not connecting.

I just realised that you never specified the exact error you received.
Can't you connect to Firebird at all? What error do you get?

In that case it might be that it is 1) configured to use a different
port (setting RemoteServicePort), 2) is blocked by the (Windows)
firewall (make sure there is an exclusion for the process), 3) another
process is running on port 3050, or 4) the firebird process is only
listening on 127.0.0.1 (setting RemoteBindAddress).

Mark
--
Mark Rotteveel




--


Atenciosamente,

Hugo Eyng

Re: [firebird-support] FB on LAN

[Hugo Eyng hugoe...@msn.com [firebird-support]]

Hello Mark.

I changed the firebird.conf by another one and restarted the server.

Now my string connection 192.168.0.158:C:\DIR1\BASEDIR\MYDATABASE.FDB is 
working.


I compared both firebird.conf and found two differences:

1) In the line near

# Remove protection against opening databases on NFS mounted volumes on
# Linux/Unix and SMB/CIFS volumes on Windows.

that appears in original

# ***WARNING*** ***WARNING*** ***WARNING*** ***WARNING***

in my firebird.conf the line was wraped, like

# ***WARNING*** ***WARNING**
* ***WARNING*** ***WARNING***


Em 08/04/2016 04:12, Mark Rotteveel m...@lawinegevaar.nl 
[firebird-support] escreveu:


On 7-4-2016 20:54, Hugo Eyng hugoe...@msn.com [firebird-support] wrote:
> Hello Mark.
>
> I was like you showed 192.168.0.158:C:\DIR1\BASEDIR\MYDATABASE.FDB
>
> Than I changed from FB 32 to FB 64 and it stopped working. After that,
> after that even turnning to FB 32 it doesn´t work using this structure.
> I only works
> using \\192.168.0.158\C:\DIR1\BASEDIR\MYDATABASE.FDB or
> C:\DIR1\BASEDIR\MYDATABASE.FDB

In your first question your connection string was:

192.168.0.158:\DIR1\BASEDIR\MYDATABASE.FDB

Note the absence of _C:_ This means you are connecting with a relative
path. And the root of this path depends on the configuration (and maybe
on the user running Firebird).

> I open the 3050 port in FW. But it keep not connecting.

I just realised that you never specified the exact error you received.
Can't you connect to Firebird at all? What error do you get?

In that case it might be that it is 1) configured to use a different
port (setting RemoteServicePort), 2) is blocked by the (Windows)
firewall (make sure there is an exclusion for the process), 3) another
process is running on port 3050, or 4) the firebird process is only
listening on 127.0.0.1 (setting RemoteBindAddress).

Mark
--
Mark Rotteveel




--


Atenciosamente,

Hugo Eyng

Re: [firebird-support] [FB 2.1] Firebird engine seems to slowdown on high load without utilizing hardware

[liviusliv...@poczta.onet.pl [firebird-support]]

Hi,
i have few questions releated to your problem
1. What is your sweep settings?
2. When you run backup and do you use gbak or nbackup?
3. what is your transactions settings? Do you use readonly readcommited or 
prefered shapshot?
regards,
Karol Bieniaszewski 
 

Re: Re: [firebird-support] [FB 2.1] Firebird engine seems to slow down on high load without utilizing hardware

[liviuslivius liviusliv...@poczta.onet.pl [firebird-support]]

>>Hey,
>>not sure how you can survive with superserver :)
>>I can't see that working with our kind of load (realtime-data-processing, 
>>reports, mostly write IOPS)
>>It's a long time ago (Fb 1.5) since we used superserver but we didn't have 
>>the best time with it back then.
 
I do not know what is your database for
but we have monitoring database where we move all older than 3 day data to 
monthly archive databases.
Then any raports created are fast on working database and slow down in archive.
Archive databases are on different server. Then we never do large raport on big 
data on production server.
>>But currently this is not about switching the server-version. More about 
>>undestanding why the server is not using the provided hardware :)
>>Also it reads kinda strange if you talk about high load, but always have low 
>>cpu usage :)
 
i have high load with low cpu.
When i mean load i think about IO.
I have many record modifications/insert but cpu near to never increase above 
50% of core.
Maybe you have much more load i have 17 000 000 new records stored into 
database and one new record cause 1 to many updates to existing records.
if we calc than we have 196 record per second (if i cal this correctly) - i do 
not know what is your load to compare.
 
All work fast - and only system slow down, when backup start.
But backup is fast because we do backup to RAM disk and then automatically we 
move this backup to another server where automatically db is restored to check 
if db is healthy
 
regards,
Karol Bieniaszewski

Re: [firebird-support] monitoring Table

['Thomas Steinmaurer' t...@iblogmanager.com [firebird-support]]

Hello Olaf,

'Checkmail' check_m...@satron.de [firebird-support] schrieb am 13.04.2016 14:38:

> Hello,
> 
> 
> 
> I've a problem with our database, firebird 3.0 RC2, some Clients (C++,
> Microsoft Access over Firebird ODBC). There are 7 open transactions. But
> in the monitoring Table, I cannot see the one who is the oldest was shown.
> Why?

How/where do you identify the oldest transaction?


--
With regards,
Thomas Steinmaurer
http://www.upscene.com

Professional Tools and Services for Firebird
FB TraceManager, IB LogManager, Database Health Check, Tuning etc.



> 
> 
> 
> INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
> MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
> MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
> MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)
> 
>  VALUES (2834893, 85000, 1, '2016-04-13 14:34:31',
> 2834893, 2774214, 2771000, 2, 0, 0, 0, 1, 201);
> 
> INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
> MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
> MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
> MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)
> 
>  VALUES (2208191, 68114, 0, '2016-04-07 05:03:44',
> 2208191, 2768721, 2771000, 2, -1, 1, 0, 1, 319);
> 
> INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
> MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
> MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
> MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)
> 
>  VALUES (2833276, 83617, 1, '2016-04-13 07:00:29',
> 2771000, 2768721, 2769594, 2, -1, 0, 0, 1, 1267);
> 
> INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
> MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
> MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
> MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)
> 
>  VALUES (2834878, 84239, 1, '2016-04-13 10:38:25',
> 2792941, 2768721, 2771000, 2, -1, 0, 0, 1, 1677);
> 
> INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
> MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
> MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
> MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)
> 
>  VALUES (2834800, 84681, 1, '2016-04-13 14:21:39',
> 2832348, 2768721, 2771000, 2, -1, 0, 0, 1, 1933);
> 
> INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
> MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
> MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
> MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)
> 
>  VALUES (2833230, 84857, 1, '2016-04-13 14:25:23',
> 2833010, 2768721, 2771000, 2, -1, 0, 0, 1, 2196);
> 
> INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
> MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
> MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
> MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)
> 
>  VALUES (2829258, 84866, 1, '2016-04-13 14:06:50',
> 2829258, 2768721, 2771000, 2, -1, 0, 0, 1, 2293);
> 
> INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
> MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
> MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
> MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)
> 
>  VALUES (2834822, 84891, 1, '2016-04-13 14:13:14',
> 2829911, 2768721, 2771000, 2, -1, 0, 0, 1, 2358);
> 
> INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
> MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
> MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
> MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)
> 
>  VALUES (2833355, 84977, 1, '2016-04-13 14:27:03',
> 2833355, 2768721, 2771000, 2, -1, 0, 0, 1, 2450);
> 
> INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
> MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
> MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
> MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)
> 
>  VALUES (2833491, 84980, 1, '2016-04-13 14:28:18',
> 2833491, 2768721, 2771000, 2, -1, 0, 0, 1, 2527);
> 
> INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
> MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
> MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
> MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)
> 
>  VALUES (2834880, 85006, 1, '2016-04-13 14:34:02',
> 2834880, 2774214, 2771000, 2, -1, 0, 0, 1, 2664);
> 
> 
> 
> COMMIT WORK;
> 
> 
> 
> Thank you
> 
> 
> 
> Best 

[firebird-support] monitoring Table

['Checkmail' check_m...@satron.de [firebird-support]]

Hello,

 

I've a problem with our database, firebird 3.0 RC2, some Clients (C++,
Microsoft Access over Firebird ODBC). There are 7 open transactions. But
in the monitoring Table, I cannot see the one who is the oldest was shown.
Why?

 

INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)

  VALUES (2834893, 85000, 1, '2016-04-13 14:34:31',
2834893, 2774214, 2771000, 2, 0, 0, 0, 1, 201);

INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)

  VALUES (2208191, 68114, 0, '2016-04-07 05:03:44',
2208191, 2768721, 2771000, 2, -1, 1, 0, 1, 319);

INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)

  VALUES (2833276, 83617, 1, '2016-04-13 07:00:29',
2771000, 2768721, 2769594, 2, -1, 0, 0, 1, 1267);

INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)

  VALUES (2834878, 84239, 1, '2016-04-13 10:38:25',
2792941, 2768721, 2771000, 2, -1, 0, 0, 1, 1677);

INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)

  VALUES (2834800, 84681, 1, '2016-04-13 14:21:39',
2832348, 2768721, 2771000, 2, -1, 0, 0, 1, 1933);

INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)

  VALUES (2833230, 84857, 1, '2016-04-13 14:25:23',
2833010, 2768721, 2771000, 2, -1, 0, 0, 1, 2196);

INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)

  VALUES (2829258, 84866, 1, '2016-04-13 14:06:50',
2829258, 2768721, 2771000, 2, -1, 0, 0, 1, 2293);

INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)

  VALUES (2834822, 84891, 1, '2016-04-13 14:13:14',
2829911, 2768721, 2771000, 2, -1, 0, 0, 1, 2358);

INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)

  VALUES (2833355, 84977, 1, '2016-04-13 14:27:03',
2833355, 2768721, 2771000, 2, -1, 0, 0, 1, 2450);

INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)

  VALUES (2833491, 84980, 1, '2016-04-13 14:28:18',
2833491, 2768721, 2771000, 2, -1, 0, 0, 1, 2527);

INSERT INTO MON$TRANSACTIONS (MON$TRANSACTION_ID, MON$ATTACHMENT_ID,
MON$STATE, MON$TIMESTAMP, MON$TOP_TRANSACTION, MON$OLDEST_TRANSACTION,
MON$OLDEST_ACTIVE, MON$ISOLATION_MODE, MON$LOCK_TIMEOUT, MON$READ_ONLY,
MON$AUTO_COMMIT, MON$AUTO_UNDO, MON$STAT_ID)

  VALUES (2834880, 85006, 1, '2016-04-13 14:34:02',
2834880, 2774214, 2771000, 2, -1, 0, 0, 1, 2664);

 

COMMIT WORK;

 

Thank you

 

Best regards

 

Olaf

 

 

[firebird-support] Re[2]: [FB 2.1] Firebird engine seems to slow down on high load without utilizing hardware

[Alexey Kovyazin (ak) a...@ib-aid.com [firebird-support]]

Patrick,
Definetely you need to compare real life loads.
--
Regards,
Alexey Kovyazin
IBSurgeon среда, 13 апреля 2016г., 04:47 +03:00 от " thetr...@yahoo.com 
[firebird-support]" < firebird-support@yahoogroups.com> :

> 
>
>Hey Alexey,
>thanks you for our input. I think what you say is correct, and we reviewed our 
>disk setup again.
>We are utilizing mechnical discs so it's kinda hard to compare SSD performance 
>to them.
>But they should provide enought IOPS for our load.
>
>Unfortunatly we can't just switch to a single SSD, since we would loose 
>replication and failover systems the SAN provides which is a critical demand 
>for us. I'm afraid for now we have to stick with it, until we have some facts 
>to proof that the SAN Setup is our limiting factor. And data is not should 
>that for me currently.
>
>On a sidenode, we do own a server with SSD setup, but in tests we couldn't get 
>a noticable performance gain through increasement of IOs this way. (tests was 
>generic and not real world load unfortunatly)
>
>Best Regards,
>Patrick
>
>---In firebird-support@yahoogroups.com,  wrote :
>
>Hi Patrick,
>
>If you say that problem occurred recently, I would suggest you to
check SAN disks health.
>
>However, these values
>>> Average system IOPS under load read: 100
>>>Average system IOPS under load write: 550
>>> Backup Restore IOPS read: 1700
>>> Backup Restore IOPS write: 250
are really, really low. 
>1700 IOPS for the database with 4k page means 6.8Mb/sec (in case
of random reads).
>
>I suggest to install a single SSD drive and check how it will
work.
>SSD IOPS looks like
>  Random Read 4KB (QD=32) :   283.050 MB/s [ 69104.0 IOPS]
>  Random Write 4KB (QD=32) :   213.837 MB/s [ 52206.2 IOPS]
>
>
>From our optimization practice we found that if you need to
optimize only the single instance of the database, the most cost
effective way is to upgrade to SSD first, and only then fix other
problems.
>
>Regards,
>Alexey Kovyazin
>IBSurgeon HQbird  www.ib-aid.com
>
>
>
>>> 
>>>hi,
>>>recently we had some strange performance issues with our
Firebird DB server.
>>>On high load, our server started to slow down. Select and
update SQL query times did go up by more than 500% on
average,
>>>but reaching unreasonable high execution times at worst
case. (several minutes instead of < 1sec)
>>>
>>>OIT/OAT/Next Transaction statistics was within 1000 the
hole time
>>>We were not able to messure any hardware limiting factor.
Indeed, this system was running with only 8 cores at about
70% CPU usage on max. load.
>>>We decided that this may be our problem since we
experienced a similar problem at about 80% CPU load in the
past.
>>>So we upgraded the hardware. As expected, the CPU-load
dropped to ~35% usage on max. load scenario.
>>>But this did not solve the problem.
>>>Same story for the harddisk system. The usage is not even
near it's max capacity.
>>>
>>>We also can't see any impact on the harddisk.
>>>We'r kind of stuck with our ideas, because we have no
idea what could be a potential bottleneck to the system.
>>>Since the hardware doesn't show a limit, there have to be
anything else - most likely firebird engine related that's
limiting our system.
>>>We would be very grateful if anyone can give us hints
where we can search further.
>>>Or someone has similar experiences to share with us.
>>>
>>>
>>>Operating System: Windows Server 2003
>>>Firebird: 2.1.5 Classic
>>>Dedicated database server (VMWare)
>>>
>>>CPU: 16 cores, each 2.4 GHz
>>>RAM: 32 GB
>>>About
14GB are used from OS and firebird processes under max
load.
>>>HDD: SAN Storage System
>>>
>>>Average
system IOPS under load read: 100
>>>Average
system IOPS under load write: 550
>>>Backup
Restore IOPS read: 1700
>>>Backup
Restore IOPS write: 250
>>>SAN
IPOS Limit (max): 3000
>>>
>>>Firebird Config Settings, based on defaults
>>>DefaultDbCachePages
= 1024
>>>LockMemSize
= 134247728
>>>LockHashSlots
= 20011
>>>Database
>>>size:
about 45 GB
>>>450
to 550 concurrent connections
>>>Daily
average of 65 transactions / second (peak should be
higher)
>>>
>>>FB_LOCK_PRINT (without any params) while system was
slowing down (~4 days uptime).
>>>I have to note, Firebird was not able to print the
complete output (stats was not cropped by me)
>>>
>>>LOCK_HEADER BLOCK
>>>Version:
16, Active owner:      0, Length: 134247728, Used:
82169316
>>>Semmask:
0x0, Flags: 0x0001
>>>Enqs:
4211018659, Converts: 10050437, Rejects: 9115488, Blocks:
105409192
>>>Deadlock
scans:   1049, Deadlocks:      0, Scan interval:  10
>>>Acquires:
4723416170, Acquire blocks: 640857597, Spin count:   0
>>>Mutex
wait: 13.6%
>>>Hash
slots: 15077, Hash lengths (min/avg/max):    3/  12/  25
>>>Remove
node:      0, Insert queue:     36, Insert prior: 74815332
>>>Owners
(456): forward:
131316, backward: 14899392
>>>Free
owners (9): forward:
39711576, backward: 49867232
>>>Free
locks (42409): forward:
65924212, backward: 23319052
>>>
>>>With best Regards,
>>>
>>>Patrick Friessnegg
>>>Synesc GmbH
>

[firebird-support] Re[2]: [FB 2.1] Firebird engine seems to slow down on high load without utilizing hardware

[Alexey Kovyazin (ak) a...@ib-aid.com [firebird-support]]

Hi,
You wrote:
>The thing is, sure this numbers look really low. But >the system never uses 
>it. The monitoring of the >SAN show's that this load's are never used
You are confusing the reason and the result.
Monitoring shows low numbers because spinning drives cannot provide fast enough 
random reads. 
>From Sintatica, every 20 Minutes a Peak in GC for >~15.000 transactions
Sinatica uses really strange terms to describe transactions behaviour, and 
since it is an abandonen tool, nobody can explain how they are aligned with 
real situation.
--
Regards,
Alexey Kovyazin
IBSurgeon среда, 13 апреля 2016г., 05:08 +03:00 от " thetr...@yahoo.com 
[firebird-support]" < firebird-support@yahoogroups.com> :

> 
>Hey Thomas,
>thanks for your extensive reply.
>Unfortunatly we'r still bound to some old 32bit UDF functionality which we 
>can't get in 64bit. 
>I think you know about the use of SuperClassic with 32bit Server - 2GB RAM 
>Limit :)
>It's not impossible, but also not really a fast route we can go. But for sure 
>again a reason to talk about moving the switch to 2.5.
>
>We did ran some some disk IO benchmarks (with AS SSD) today, and in times of 
>SSD kinda depressing :D
>The thing is, sure this numbers look really low. But the system never uses it. 
>The monitoring of the SAN show's that this load's are never used. The 
>Single-4k-read is worring me, but i lean towards that our 500 proceses are 
>more like the 64-thread test. But even then, we only messured 100 Iops reading 
>on livesystem.
>
>Sequential Read speed: ~ 450 MB / s
>Sequential Write speed: ~500 MB / s
>4k read: 196 Iops
>4k write: 1376 Iops
>4k-64 thread read: 15945 Iops
>4k-64 thread write: 7361 Iops
>
>
>Garbage Info still needs to be collected.
>But first signs show that this indeed could be a potential problem.
>From Sintatica, every 20 Minutes a Peak in GC for ~15.000 transactions. This 
>get's fixed by the server in the relative small amount of time (i think < 1 
>minute), since it's really only a single peak in the graph everytime.
>When the GC stop increasing and the server starts to collect it, we see an 
>increase of concurrent running transactions (= transactions are longer open 
>and processed slower).
>
>We don't have data from the live system yet to see if this behaviour kind of 
>"snowballs" when there is really high load on the server.
>
>Best Regards,
>
>---In firebird-support@yahoogroups.com,  wrote :
>
>Hi Patrick,
>
>>> Hi Thomas, nice to get a response from you. We already met in ~2010 in Linz 
>>> at
>>> your office :)
>>> (ex. SEM GmbH, later Playmonitor GmbH)
>>
>I know. XING (Big Brother) is watching you. Nice to see that you are still 
>running with Firebird. ;-)
>
>
>>> First, sorry for posting a mixed state of informations. The config settings 
>>> i
>>> postet are the current settings.
>>> But the Lock-Table-Header was from last saturday (day of total system 
>>> crash) -
>>> we changed Hash Slot Value since than, but it didn't work. New Table looks
>>> like:
>>> 
>>> 
>>> LOCK_HEADER BLOCK
>>> Version: 16, Active owner:  0, Length: 134247728, Used: 55790260
>>> Semmask: 0x0, Flags: 0x0001
>>> Enqs: 1806423519, Converts: 4553851, Rejects: 5134185, Blocks: 56585419
>>> Deadlock scans: 82, Deadlocks:  0, Scan interval:  10
>>> Acquires: 2058846891, Acquire blocks: 321584126, Spin count:   0
>>> Mutex wait: 15.6%
>>> Hash slots: 20011, Hash lengths (min/avg/max):0/   7/  18
>>> Remove node:  0, Insert queue:  0, Insert prior:  0
>>> Owners (297): forward: 385160, backward: 38086352
>>> Free owners (43): forward: 52978748, backward: 20505128
>>> Free locks (41802): forward: 180712, backward: 3620136
>>> Free requests (-1097572396): forward: 46948676, backward: 13681252
>>> Lock Ordering: Enabled
>>> 
>>> 
>>> The Min/Avg/Max hash lengths look better now, but as you mentioned the Mutex
>>> wait is worring us too.
>>> We have 2 direct questions about that.
>>> 
>>> 
>>> 1) What are the negative effects of increasing Hash-Slots (too high)?
>>
>It somehow defines the initial size of a hash table which is used for lock(ed) 
>object lookup by a key (= hash value), ideally with constant O(1) run-time 
>complexity. If the hash table is too small, due to a too small value for hash 
>slots, it starts to degenerate into a linked/linear list per hash slot. Worst 
>case resulting in O(n) complexity for lookups. The above 20011 setting shows 
>an AVG hash length which looks fine.
>
>As you might know, Classic having a dedicated process per connection model 
>somehow needs a (global) mechanism to synchronize/protect shared data 
>structures across these processes via IPC. This is what the lock manager and 
>the lock table is used for.
>
>>> 2) As far as we know, we can't influence Mutex wait directly (it's just
>>> informational). But do you think that's the reason the underlying hardware 
>>> is
>>> not utilized?
>>
>I don't think you are disk IO bound. Means, I'm not convinced that faster IO