Subject | Re: [firebird-support] allocl_global: Event table space exhausted |
---|---|
Author | Ann W. Harrison |
Post date | 2005-09-27T15:13:42Z |
unordained wrote:
server machine, you should change some values in the firebird.conf file.
The default values were chosen when a system with a hundred megs of
memory was huge, so they can be increased by a lot on modern systems.
This time, you've run out of memory in the event table, a shared memory
space used for communication to clients waiting for events. You may
also see performance degradation due to the lock table, or errors caused
by exhausting the lock table.
The first parameter to change is in bytes
#EventMemSize = 65536
Uncomment that line and double or quadruple the memory allocated for the
event table:
EventMemSize = 262144
While you system is loaded, run fb_lock_print with no switches. You'll
see output that starts something like this:
LOCK_HEADER BLOCK
Version: 114, Active owner: 0, Length: 262144, Used: 85740
Semmask: 0x0, Flags: 0x0001
Enqs: 18512, Converts: 490, Rejects: 0, Blocks: 0
Deadlock scans: 0, Deadlocks: 0, Scan interval: 10
Acquires: 21048, Acquire blocks: 0, Spin count: 0
Mutex wait: 0.0%
Hash slots: 101, Hash lengths (min/avg/max): 0/ 5/ 13
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (8): forward: 11500, backward: 11780
Free owners: *empty*
Free locks (648): forward: 13216, backward: 31248
Free requests (648): forward: 14284, backward: 14172
Lock Ordering: Enabled
The second line
Version: 114, Active owner: 0, Length: 262144, Used: 85740
tells you how close you are to running out of space in the lock table.
If the amount used is anywhere near the total length, change this
parameter in the configuration file
#LockMemSize = 262144
to this = or even something bigger - the value is in bytes.
LockMemSize = 1048576
The seventh and eighth lines can suggest that the system is being slowed
down by hash conflicts in the lock table. [If that sentence doesn't
make any sense, don't worry. Just follow the directions.]
Mutex wait: 0.0%
Hash slots: 101, Hash lengths (min/avg/max): 0/ 5/ 13
If the value of mutex wait is large than 5.0%, your system performance
may be throttled by the width of the hash table. If the hash lengths
are more than min 5, avg 10, or max 30, you need to increase the number
of hash slots. Choose a prime number.
Change this line:
#LockHashSlots = 101
to
LockHashSlots = 499
where 499 can be an prime number below 2048.
Regards,
Ann
> kronos (Server) Mon Sep 26 23:21:09 2005If you're trying to run a lot (> 100) classic processes on a single
> alloc_global: Event table space exhausted
>
server machine, you should change some values in the firebird.conf file.
The default values were chosen when a system with a hundred megs of
memory was huge, so they can be increased by a lot on modern systems.
This time, you've run out of memory in the event table, a shared memory
space used for communication to clients waiting for events. You may
also see performance degradation due to the lock table, or errors caused
by exhausting the lock table.
The first parameter to change is in bytes
#EventMemSize = 65536
Uncomment that line and double or quadruple the memory allocated for the
event table:
EventMemSize = 262144
While you system is loaded, run fb_lock_print with no switches. You'll
see output that starts something like this:
LOCK_HEADER BLOCK
Version: 114, Active owner: 0, Length: 262144, Used: 85740
Semmask: 0x0, Flags: 0x0001
Enqs: 18512, Converts: 490, Rejects: 0, Blocks: 0
Deadlock scans: 0, Deadlocks: 0, Scan interval: 10
Acquires: 21048, Acquire blocks: 0, Spin count: 0
Mutex wait: 0.0%
Hash slots: 101, Hash lengths (min/avg/max): 0/ 5/ 13
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (8): forward: 11500, backward: 11780
Free owners: *empty*
Free locks (648): forward: 13216, backward: 31248
Free requests (648): forward: 14284, backward: 14172
Lock Ordering: Enabled
The second line
Version: 114, Active owner: 0, Length: 262144, Used: 85740
tells you how close you are to running out of space in the lock table.
If the amount used is anywhere near the total length, change this
parameter in the configuration file
#LockMemSize = 262144
to this = or even something bigger - the value is in bytes.
LockMemSize = 1048576
The seventh and eighth lines can suggest that the system is being slowed
down by hash conflicts in the lock table. [If that sentence doesn't
make any sense, don't worry. Just follow the directions.]
Mutex wait: 0.0%
Hash slots: 101, Hash lengths (min/avg/max): 0/ 5/ 13
If the value of mutex wait is large than 5.0%, your system performance
may be throttled by the width of the hash table. If the hash lengths
are more than min 5, avg 10, or max 30, you need to increase the number
of hash slots. Choose a prime number.
Change this line:
#LockHashSlots = 101
to
LockHashSlots = 499
where 499 can be an prime number below 2048.
Regards,
Ann