Subject Re: Firebird 1.5.1 sucking all memory - Problem found
Author jssahdra
I think I have narrowed down to the root cause of problem. After
doing testing for whole of sunday and today, I found that stored
procedures are creating problem. I ran a perl scripts, which
continously calls two SPs. One of those SP does an insert into a
table.
When I do an insert from within the stored procedure, it reached
135MB in 20 minutes. But when I remove that insert from SP, and
execute the same insert from the perl script, it reached 43MB in 20
minutes.

My application uses stored procedure for all queries and updates. So
before I jump into modifying my app where it will not do any
insert/updates in SPs, I will appriciate if some expert can give me
some more ideas.

Gurus please hep me !!!!

JS


--- In firebird-support@yahoogroups.com, "jssahdra" <joga.singh@i...>
wrote:
>
> --- In firebird-support@yahoogroups.com, "Alan McDonald"
<alan@m...>
> wrote:
> > > > OK - so from this description, superserver should handle it
> > > handsomely. One
> > > > connection, 250 updates every 5 minutes.. piece of cake for
FB.
> > > > There must be some else happening..
> > > > you say multi threaded application. Are making sure you use a
> > > separate
> > > > connection for each thread?
> > > > You're kinda contradicting things here now... how many
threads -
> so
> > > how many
> > > > connections?
> > > > Alan
> > >
> > > Ok, I will give you the complete overview.
> > > It is a bandwidth manager (internet gateway) software which
> controls
> > > QoS policies. It is connected to a big-big LAN (250 or even
more
> PCs).
> > > All are trying to connect to the internet. When the application
> > > starts, it will capture the packets (pcap) and try to
authenticate
> > > (based on IP, MAC, VLAN etc.). If there is not session open for
a
> > > ip/mac, it will start a new thread for authentication. This
> > > authentication is done against firebird DB. Once authenticated,
> his
> > > session starts, which is updated to the db every five minutes.
> Only
> > > the authentication requests are multi-threaded, thread is
> terminated
> > > on authentication. There are no dead threads etc. Updates are
> done by
> > > a single thread one by one.
> > > Then it becomes a routine, somebody logs in, somebody logs out
> (idle
> > > time out etc.)
> > >
> > > Firebird handles the initial load (25-30 threads, thread pool)
> > > without any problem.
> > >
> > > On each request (authentication, update, close) I call a
function,
> > > which attach to the database, starts a transaction, updates,
> commits
> > > the transaction and then detaches from the database. Error
> checking
> > > is done for deadlock and any other errors. Transaction is
rolled
> back
> > > on a failure.
> > >
> > >
> > > JS
> >
> > yes - I'm familiar with all this - I wrote the MSSQL end of one
of
> these for
> > a radius server.
> > FB should have no issues at all with it. The updates are light
and
> there
> > should never be any hold up.
> > Something else is at play here - it's not Firebird - it has to be
> your
> > application somewhere.
> > Alan
>
> Here is the top command output.
>
> 15:52:12 up 4 days, 4:44, 3 users, load average: 0.36, 0.29,
0.29
> 76 processes: 72 sleeping, 3 running, 1 zombie, 0 stopped
> CPU states: 0.9% user 8.1% system 0.0% nice 0.0% iowait
> 90.8% idle
> Mem: 1031904k av, 456900k used, 575004k free, 0k shrd,
> 101888k buff
> 204256k active, 216820k inactive
> Swap: 2040244k av, 888k used, 2039356k free
> 287516k cached
>
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU
> COMMAND
> 25723 root 8 0 15520 15M 2720 S 1.1 1.5 0:20 0
> ssg200f
> 4296 firebird 9 0 10240 9M 2424 S 0.0 0.9 0:26 0
> fbserver
>
> ======
> I started firebird 15 minutes before and it is using only 9M. Now
it
> will keep increasing. After 4-5 hours it will reach 300MB. Then we
do
> a fb restart.
>
> In fact that reminds me, there is a web interface also, written in
> perl. I remember we don't care much about closing connections etc,
> becuase we assume that the perl will do it for us. Let me see if
that
> is the reason. It will take at least 2 hours to monitor.
>
> One more problem, may be you can help me. My application gives
> segfault sometimes, but from the core dump I am not able to find
the
> source of error. It does not show any function name, line number
etc.
> It is compiled with '-g' option for debugging information. Are
there
> any other options, which can give me some more info. Because It is
a
> multi-threaded app, logging also does not help much.
>
> here is the dump.
> ================
> Program terminated with signal 11, Segmentation fault.
> Cannot access memory at address 0x404f3000
> #0 0x40210780 in ?? ()
> (gdb) bt
> #0 0x40210780 in ?? ()
> Cannot access memory at address 0xbf7ff5c4
> ================
>
>
> JS