>> This mean that Firebird's process already allocated 2GB of VM and
>> failed to get more.
>>
>> Usually this is because of some high value of "DefaultDbCachePages"
>> setting in firebird.conf
>
>
> In the firebird.conf file, the setting regarding "DefaultDbCachePages"
> is the standard value.
> This value should be decreased, rigth ?
>
> #
> #DefaultDbCachePages = 2048
>
> should be changed to
>
> #
> DefaultDbCachePages = 1024
>
> Or what value should I try to use.

It depends. At least now we know you didn't changed it, ok.

> or database(s) have high value of "page buffers"
>> configured at header page.
>>
>
> Database header page information:
> Flags 0
> Checksum 12345
> Generation 11563831
> Page size 4096
> ODS version 10.1
> Oldest transaction 8836719
> Oldest active 8836720
> Oldest snapshot 8811773
> Next transaction 8921833
> Bumped transaction 1
> Sequence number 0
> Next attachment ID 0
> Implementation ID 16
> Shadow count 0
> Page buffers 0
> Next header page 0
> Database dialect 1
> Creation date Mar 20, 2008 11:26:39
> Attributes force write
>
> Variable header data:
> Sweep interval: 0
> *END*
>
>
>
> The "Page buffers" is the above value.
> And a setting of 0 means its disabled, rigth?

0 means - use value from firebird.conf. I.e. for this database Firebird SS will
use 4KB * 2048 = 8MB of memory for page cache. Sounds not big.

Count how many databases is opened when VM use is near 2GB. Look at every
such database header page and see value of "Page buffers" and "Page size". This
gives you sum of amount of memory allocated for page cache for all databases.

If this sum much lower than 2GB, you probably have memory leak in Firebird or
in some UDF. If after full disconnect from all databases FB still used big amount
of VM (say more than 50MB), then this is definitely memory leak.

Regards,
Vlad

PS calculations above correct for SS only