Subject FirebirdSQL freeze on 100% used ram
Author Pirk Lajos
Dear Developers!
We have issue with the Firebird SQL server.

Usually the server used by 50-70 user via our ERP.
We also have a b2b (online shop) system, what uses the same DB.
Once, in a time, around 12-13h daytime, we have a huge load, a big pike in our memory usage, the FB DB slow down, then stop working, until we restart the whole server environment, except hardware-side (restart only the FB SQL server softver)

In normal usage, we have used around 30% of our memory (64GB), when the problem above appears, the usage gone to 80%, stagnate for a while (around 5-10 mins), and the go to the top (100%), and the DB stuck.
In this time, we have around 300 pcs of fb_inet_server.exe running, and the most of them using around 110-140 Mbyte of memory.

At this time, we have some problem with security2.fdb file.
Log and config (only the active paramters attached) file contets are below.

LOG:
----------------------------------------


TOPSQL Thu Oct 17 12:08:01 2013
no permission for read-write access to database D:\PROGRAM FILES (X86)\FIREBIRD_2_1\SECURITY2.FDB

TOPSQL Thu Oct 17 12:08:43 2013
INET/inet_error: read errno = 10054
----------------------------------------

CONFIG:
----------------------------------------

# ----------------------------
#
# Determines the number of seconds that the lock manager will wait after a
# conflict has been encountered before purging locks from dead processes
# and doing extra deadlock scan cycle. Engine detects deadlocks instantly
# in all normal cases, so this value affects things only if something goes
# wrong. Setting it too low may degrade system performance.
#
# Type: integer
#
DeadlockTimeout = 2

# ----------------------------
#
# This option controls whether to call abort() when internal error or BUGCHECK
# is encountered thus invoke post-mortem debugger which can dump core suitable
# for off-line analysis. When disabled engine tries to minimize damage and
# continue execution.
#
# Note that setting this option to 1 makes engine produce traceable coredumps
# when something nasty like SIGSEGV happens inside UDF. On Windows enabling
# this option makes engine invoke JIT debugger facilities when errors happen.
#
# For debugging builds (DEV_BUILD), default value is 1 (Enabled)
#
# Type: boolean
#
BugcheckAbort = 1

# ----------------------------
# Client Connection Settings (Basic)
#
# Seconds to wait before concluding an attempt to connect has failed.
#
# Type: integer
#
ConnectionTimeout = 30

# ----------------------------
# Locking and shared memory parameters
#
# Bytes of shared memory allocated for lock manager.
# In Classic mode, the size given is used for the initial allocation. The
# table expands dynamically up to the limit of memory. In SuperServer, the
# initial size is also the final size.
#
# Type: integer
#
LockMemSize = 104857600
----------------------------------------


Please give me some instruction about this problem.
Best Regards,
Lajos Pirk