Maxdb session limit = Crash

[Former Member]

Hello,

our server crashed last week, admins said: it is due to: too many connections to MaxDB and that there was too many connection to MaxDB on status: TIME_WAIT!

i have written small script "with a loop" to make so many connection to the DB and i could realy make MaxDB crashes !!

Is it a security bug? is MaxDB bad configured? or what is the silution for this problem please?

session limit is set to 500!!

thanks alot

[former_member229109]

Hello slac ware ,

-> Could you please post your script.

-> Could you please check the knldiag.err < as of version 7.7 - KnlMsgArchive > located in database RUNDIRECTORY.

<Please see document at https://www.sdn.sap.com/irj/scn/wiki?path=/display/maxdb/main -> MaxDB HowTo -> "HowTo - New "knldiag" Message File Format in MaxDB 7.7">

What errors did you see, when you assumed that database was "crashed"?

-> Please update with output of the following commands:

sdbregview -l

dbmcli -s db_enum

dbmcli -s db_enum

What is OS of the database server?

What is the value of the MAXUSERTASKS database parameter?

As you know, if you increase the MAXUSERTASKS, the memory consumption increases by at least the value of the parameter MAXTASKSTACK for each user task added.

-> When you run your script, please run the command 'x_cons <database-name> show active' & post output.

Thank you and best regards, Natalia Khlopina

[Former Member]

thanks Natalia Khlopina btw. Markus Doehr,

we are running

MaxDB 7.6

on Centos 4.5

./sdbregview -l

Server Utilities /opt/sdb/programs 7.6.00.37 64 bit valid

DB Analyzer /opt/sdb/programs 7.6.00.37 64 bit valid

Base /opt/sdb/programs 7.6.00.37 64 bit valid

Redist Python /opt/sdb/programs 7.6.00.37 64 bit valid

JDBC /opt/sdb/programs 7.6.00.30 valid

Messages /opt/sdb/programs MSG 0.3951 valid

ODBC /opt/sdb/programs 7.6.00.37 64 bit valid

Database Kernel /opt/sdb/PDB 7.6.00.37 64 bit valid

Loader /opt/sdb/programs 7.6.00.37 64 bit valid

SQLDBC /opt/sdb/programs 7.6.00.37 64 bit valid

Webtools /opt/sdb/programs/web 7.6.00.37 64 bit valid

./dbmcli -s db_enum

PDB /opt/sdb/PDB 7.6.00.37 fast running

PDB /opt/sdb/PDB 7.6.00.37 quick offline

PDB /opt/sdb/PDB 7.6.00.37 slow offline

PDB /opt/sdb/PDB 7.6.00.37 test offline

*****************

btw. i have checked the knldiag, i couldnt find anything about unregular stops, it was only full with connections which are on wait status

MAXUSERTASKS = 500 "we have load on the server"

the script which i told you about is only an endless loop with connections to the DB and select *

and let me say:

DB didnt crash in that meaning but was Blocked ! since i could reserve all open sessions for my self !!

how can i avoide this please in the Futur?

thanks alot

regards

Edited by: slac ware on Feb 5, 2009 6:02 PM

Edited by: slac ware on Feb 5, 2009 6:03 PM

[markus_doehr2]

> ./dbmcli -s db_enum

> PDB /opt/sdb/PDB 7.6.00.37 fast running

> PDB /opt/sdb/PDB 7.6.00.37 quick offline

> PDB /opt/sdb/PDB 7.6.00.37 slow offline

> PDB /opt/sdb/PDB 7.6.00.37 test offline

Your software version is VERY old - I would update to the lastest version. However, this is not related to your "problem".

> how can i avoide this please in the Futur?

This is not a database problem but a problem with the application. Each database has a limit for open connections because each connection uses resources. Oracle does that and DB2 does that too.

What did you expect what the database should do once the 500 is reached?

Markus

[Former Member]

thanks again markus for your replay!

>

> What did you expect what the database should do once the 500 is reached?

to be blocked ?!

application is "apache" ! , that means others should have had such problems before too maybe ?

anyway we have load but not that we have 500 session at the same time, it is about 50 only, so i will change it to 100 maybe.

Edited by: slac ware on Feb 17, 2009 4:41 PM

[markus_doehr2]

> >

> > What did you expect what the database should do once the 500 is reached?
> 

>

> to be blocked ?!

You wrote some posts ago when I asked how you found out that the database crashed:

> and let me say:

> DB didnt crash in that meaning but was Blocked ! since i could reserve all open sessions for my self !!

So it was apparently exactly doing what you were expecting, no?

> application is "apache" ! , that means others should have had such problems before too maybe ?

Again: this is not a "problem" but a design issue with your application. You may need to pool connections through a middleware and not let each request open a separate connection.

> anyway we have load but not that we have 500 session at the same time, it is about 50 only, so i will change it to 100 maybe.

yes - ok - that's a good thing

Markus

[Former Member]

thanks for your help

[markus_doehr2]

> our server crashed last week, admins said: it is due to: too many connections to MaxDB and that there was too many connection to MaxDB on status: TIME_WAIT!

Which version of MaxDB are you running?

How did they find out it "crashed"? If it actually did, please post the relating knldiag and/or knldiag.err file.

Markus