'Steve Friedl' steve@unixwiz.net [firebird-support]
2016-10-31 14:05:06 UTC
Hi everybody,
I'm hoping somebody can point me in the right direction to track down
performance problems on Firebird 2.5.6 on 64-bit CentOS 7 Linux, where
SuperClassic is slower than Classic. I cannot find any explanation for this.
The line-of-biz application I support puts each customer in its own database
(C1000.gdb, C1001.gdb, etc.), and there could be tens of thousands of
databases in a given installation, though perhaps only hundreds open at any
one time.
This performance difference has manifested itself in a number of ways, but
one I can pin down precisely: backups.
If I have a /home/database/ directory full of (say) 2000 databases, a perl
script runs gbak in parallel through the network interface up to the number
of real CPU cores - typically 12 - to back everything up.
gbak -backup -transportable -limbo -garbage -ignore \
-u SYSDBA -p xxx \
localhost:/home/database/C1000.gdb \
/home/backup/C1000.gbk
The SuperClassic backup typically takes twice as long (ex: 97min vs 43min)
as the Classic on an otherwise idle machine, and this is widely reproducible
on many different machine; SuperClassic is *always* slower in spite of
holding as many things in common.
There are lots of tuning guides that talk about lock tables and cache sizes
and the like, but I'm not sure they apply to the backup scenario so I
haven't really done much with them; they might weigh into the other
performance issues.
Thanks,
Steve
---
Stephen J Friedl | Security Consultant | UNIX Wizard | 714 345-4571
***@unixwiz.net | Southern California | Windows Guy | unixwiz.net
I'm hoping somebody can point me in the right direction to track down
performance problems on Firebird 2.5.6 on 64-bit CentOS 7 Linux, where
SuperClassic is slower than Classic. I cannot find any explanation for this.
The line-of-biz application I support puts each customer in its own database
(C1000.gdb, C1001.gdb, etc.), and there could be tens of thousands of
databases in a given installation, though perhaps only hundreds open at any
one time.
This performance difference has manifested itself in a number of ways, but
one I can pin down precisely: backups.
If I have a /home/database/ directory full of (say) 2000 databases, a perl
script runs gbak in parallel through the network interface up to the number
of real CPU cores - typically 12 - to back everything up.
gbak -backup -transportable -limbo -garbage -ignore \
-u SYSDBA -p xxx \
localhost:/home/database/C1000.gdb \
/home/backup/C1000.gbk
The SuperClassic backup typically takes twice as long (ex: 97min vs 43min)
as the Classic on an otherwise idle machine, and this is widely reproducible
on many different machine; SuperClassic is *always* slower in spite of
holding as many things in common.
There are lots of tuning guides that talk about lock tables and cache sizes
and the like, but I'm not sure they apply to the backup scenario so I
haven't really done much with them; they might weigh into the other
performance issues.
Thanks,
Steve
---
Stephen J Friedl | Security Consultant | UNIX Wizard | 714 345-4571
***@unixwiz.net | Southern California | Windows Guy | unixwiz.net