--- 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