1

Topic: Problem with productivity of basis

Hello.
Help to find, please, the reason "" bases.
Each 5 minutes, basis "fades" - requests , but do not fall off, new connections are not connected and do not disappear with an error. Thus activity on the server is not present - all kernels use 0,1 %, network \disk activity - under 0. In 1-1,5 minutes all kernels \disks start to work actively as well as basis -  the requests, new connections - .
fb_lock_print-h showed big kol-in Deadlock scans, here at a forum read that it can cause frequent reversal to monitoring tables. There was a trigger on a connection which climbed in the table mon$attachments, it was disconnected. The situation with deadlock scans did not change. Similar symptoms of behavior of basis are described CORE-3787, rolled away on version 2.5.6 - the problem remained. sad
Linux, Firebird Classic 2.5.6 x86 (were rolled away with 2.5.7 problem remained) the Size of basis: 310GB. CPU: 16 kernels, Mem: 32GB. About 200-300 simultaneous connections to basis.
firebird.conf
[spoiler]
DefaultDbCachePages = 1024
TempBlockSize = 2097152
TempCacheLimit = 536870912
LockMemSize = 67108864
LockHashSlots = 30011
[/spoiler]
fb_lock_print-h
[spoiler]
LOCK_HEADER BLOCK
Version: 17, Active owner: 0, Length: 67108864, Used: 19963784
Flags: 0x0001
Enqs: 21316962, Converts: 106998, Rejects: 29956, Blocks: 41118
Deadlock scans: 16950, Deadlocks: 0, Scan interval: 10
Acquires: 26067878, Acquire blocks: 2020423, Spin count: 0
Mutex wait: 7.8 %
Hash slots: 30011, Hash lengths (min/avg/max): 0/1/9
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (174): forward: 487352, backward: 11780228
Free owners (157): forward: 11769300, backward: 955512
Free locks (5634): forward: 11623412, backward: 10126092
Free requests (89469): forward: 3174308, backward: 19506404
Lock Ordering: Enabled
[/spoiler]

2

Re: Problem with productivity of basis

firemn;
And calls to MON $ to tables of times 5 minutes are not present?

3

Re: Problem with productivity of basis

firemn> Each 5 minutes, basis "fades"
Trace tried to do?
Before hangup that is visible?

4

Re: Problem with productivity of basis

Shavljuk Evgenie;
No, already is not present. There were calls at each connection and lived with it without problems for a long time - now disconnected.

5

Re: Problem with productivity of basis

At the moment of hangup
- Remove  lok-tables (fb_lock_print-a-c)
- Remove  from several processes fb_inet_server (gdb and.debug in the help)

6

Re: Problem with productivity of basis

firemn wrote:

the Size of basis: 310GB. CPU: 16 kernels, Mem: 32GB. About 200-300 simultaneous connections to basis.

As on me so the explicit warp - storages is not enough, I would increase time in 4 at least.

7

Re: Problem with productivity of basis

Ivan_Pisarevsky wrote:

it is passed...
As on me so the explicit warp - storages is not enough, I would increase time in 4 at least.

Old kind CS would pull and did not frown on this storage. And here that there about kernels in 2.5 - I do not know. In my opinion a problem all the same between wires and bytes in an axis. But it is not exact ().

8

Re: Problem with productivity of basis

Old teddy bear;
Just what isn't needed new the super pulls not , and here with CS there can be problems

9

Re: Problem with productivity of basis

Denis wrote:

the Old teddy bear;
And here with CS there can be problems

Unless  to inflate to

10

Re: Problem with productivity of basis

firemn wrote:

Linux, Firebird Classic 2.5.6 x86

It means 32 bit AXIS? Or how?

firemn wrote:

There was a trigger on a connection which climbed in the table mon$attachments, it was disconnected.

trace confirms absence of calls to monitoring?

firemn wrote:

Thus activity on the server is not present - all kernels use 0,1 %, network \disk activity - under 0.

than measured?

the teddy bear wrote:

Old kind CS would pull and did not frown on this storage.

At us on comparable loading pulled, but after rotation of servers, began to pull very much more cheerfully, but we  both percents, and storage, and a disk. To "specific " we certainly did not lead up, decided to change  already upon small moaning on . Actually helped.

11

Re: Problem with productivity of basis

wrote:

here at a forum read that it can cause frequent reversal to monitoring tables

Prompt  where here it is possible to esteem about it?

12

Re: Problem with productivity of basis

hvlad;

wrote:

- remove  lok-tables (fb_lock_print-a-c)

https://drive.google.com/open?id=0B-fzk … nR2amtKOW8

wrote:

- remove  from several processes fb_inet_server (gdb and.debug in the help)

https://drive.google.com/open?id=0B-fzk … XVNbHItdFE
This process on which suspicions that it "brings down" basis.

13

Re: Problem with productivity of basis

vvvait;
Found search in a forum on deadlock scans.
Here wrote: http://www.sql.ru/forum/1182884/deadloc … l=deadlock scans

14

Re: Problem with productivity of basis

171 connection, in peak there were 458 connections
94 connections wait  for header page
20 connections wait  for page 133
Probably, very slow IO, it is possible (bad shot) because of problems with spot-check \barrier in file system, etc.

firemn wrote:

it is passed...
https://drive.google.com/open?id=0B-fzk … XVNbHItdFE
This process on which suspicions that it "brings down" basis.

This process fulfills request and waits disk IO (read).
Any crime I do not see.
Probably, he creates superfluous IO, but on  it it is impossible to tell

15

Re: Problem with productivity of basis

hvlad wrote:

  slow IO, it is possible (bad shot) because of problems with spot-check

marking  it is not sounded, whether there is it generally?
The server "iron" or virtual?

hvlad wrote:

94 connections wait  for header page
20 connections wait  for page 133

very much the storage magnification under a file cache and  caching on  the controler helps.

firemn wrote:

disk activity - under 0

Once again a question than and in what measured? Visually on a bulb blinking on a disk and in megabytes per second? It is necessary to measure in  (kol-in operations of input of an output in a second).

16

Re: Problem with productivity of basis

record caching is it is necessary to it to be convinced still that the rejd-controler with a battery.
If the basis more or less answers during the moment  it is possible and to look at statistics of the active requests. Perhaps to optimize that it turns out?

17

Re: Problem with productivity of basis

And can it is simple disks on the verge of a last breath?

18

Re: Problem with productivity of basis

On the verge of a last breath so, what  exactly time 5 minutes happens?

19

Re: Problem with productivity of basis

o_v_a wrote:

Rajtbek record caching is it is necessary to it to be convinced still that the rejd-controler with a battery.

+, instead of , but the same essence Now is more fashionable.  yes, the clever controler with  is necessary.  the equipment.
Marking of disks is not sounded. Under  loading I would deliver features 6   (with a copying resource "the server of databases") in  10 on what-nid fresh  with possibility to cache record.