MaxDB on OpenSolaris 2008.11 resources problem

[Former Member]

Hello,

I have installed MaxDB 7.6.05.09 on a server with OpenSolaris 2008.11, an Intel Core Quad CPU, 8GB RAM and have other two PCs with JBoss connected to the database. After some time running (less than three hours) and the connections used when arriving at 80 (out of 400 available) database denied connections. When trying to access the MaxDB GUI console get the message '[...] cannot create semaphore".

These are some of database parameters:

MAXCPU = 4

MAXUSERTASKS = 400

MAXLOCKS = 32040

CACHE SIZE = 400000

Please, can someone help me with this problem?

Thanks in advance.

E. Lopez

[Former Member · Accepted solution]

Hi Markus:

This is the ouput of prjmod command with parameter '-A':

@opensolaris2:~# projmod -A maxdb
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LC_ALL = (unset),
        LC_CTYPE = "es_ES.UTF-8",
        LANG = "POSIX"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

and this the content of script file I executed to set the project 'maxdb':

opensolaris2:~/scripts# cat set_maxdb_project.sh
projadd -p 100 -c "Configuracion de MaxDB" -U sdb \
-K 'project.max-sem-ids=(priv,4096,deny)' \
-K 'process.max-sem-nsems=(priv,2048,deny)' \
-K 'process.max-file-descriptor=(priv,2048K,deny)' \
-K 'project.max-shm-ids=(priv,4096,deny)' \
-K 'project.max-shm-memory=(priv,7GB,deny)' \
maxdb

[markus_doehr2 · Accepted solution]

Looks good!

Now stop everything - including x_server (x_server stop) - logoff and re-logon, start the x_server and then try you action again.

Markus

[roland_mallmann · Accepted solution]

Hi,

in case the issue returns still; please check with which user the XServer was started. If it was root, that may be the cause for the IPC / semaphore resource issues, as it has different limits. Although a user switch is done automatically to sdb (from liveCache/MaxDB version >= 7.5), the limits are still inherited from root.

As a workaround, you could try restarting the XServer (and afterwards the db instance) using another user (one who has correct limits).

Regards,

Roland

[Former Member]

Eureka! The problem is solved.

Thank you very much to Markus Doehr and Roland Mallmann. Indeed it has been necessary to run XServer with the user sdb, I executed:

su - sdb -c "/opt/sdb/programs/bin/x_server start"

.

The problem has brought me a desperate time. Once again thanks.

E. Lopez (Xouxele).

[Former Member]

Hi Markus:

output of /etc/project:

@opensolaris2:~# cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::
maxdb:100:Configuracion de MaxDB:sdb::process.max-file-descriptor=(priv,2048000,deny);
process.max-sem-nsems=(priv,2048,deny);
project.max-sem-ids=(priv,4096,deny);
project.max-shm-ids=(priv,4096,deny);
project.max-shm-memory=(priv,7516192768,deny)

output of /etc/user_attr:

adm::::profiles=Log Management
dladm::::auths=solaris.smf.manage.wpa,solaris.smf.modify
lp::::profiles=Printer Management
postgres::::type=role;profiles=Postgres Administration,All
root::::type=role;auths=solaris.*,solaris.grant;profiles=All;
lock_after_retries=no;min_label=admin_low;clearance=admin_high
zfssnap::::type=role;auths=solaris.smf.manage.zfs-auto-snapshot;
profiles=ZFS File System Management
sdb::::project=maxdb

output of prjstat command:

@opensolaris2:~# prstat -cJ
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP       
   677 sdb      4024M 2176M sleep   59    0   0:43:23 0.4% kernel/59
   681 sdb        28M 6920K sleep   59    0   0:17:03 0.1% dbmsrv/1
   672 sdb        22M   13M sleep   59    0   0:12:56 0.1% dbmsrv/1
  5040 root     5708K 2924K cpu0    49    0   0:00:00 0.0% prstat/1
  5024 alnitak  9424K 4792K sleep   59    0   0:00:00 0.0% sshd/1
  5034 root     3408K 2340K sleep   49    0   0:00:00 0.0% bash/1
   639 gdm       128M   49M sleep   59    0   0:01:51 0.0% gdmgreeter/1
  5027 alnitak  3416K 2348K sleep   59    0   0:00:00 0.0% bash/1
   670 sdb        10M 4876K sleep   59    0   0:00:54 0.0% dbmevtdisp/1
   110 daemon   8748K 4556K sleep   59    0   0:00:00 0.0% kcfd/3
   582 root      323M   19M sleep   59    0   0:00:57 0.0% Xorg/1
   270 root     6728K 5352K sleep   59    0   0:00:00 0.0% hald/3
   606 root     3804K 1540K sleep   59    0   0:00:00 0.0% fbconsole/1
   396 root     2488K 1440K sleep   59    0   0:00:00 0.0% ttymon/1
   633 root     2624K 1080K sleep   59    0   0:00:00 0.0% in.ndpd/1
PROJID    NPROC  SWAP   RSS MEMORY      TIME  CPU PROJECT                     
     1       50 4115M 2198M    27%   1:14:24 0.6% user.root                   
    10        2 1768K 8848K   0.1%   0:00:00 0.0% group.staff                 
     0       54  115M  184M   2.3%   0:03:52 0.0% system                      
     3        1  248K 2720K   0.0%   0:00:00 0.0% default                     
Total: 107 processes, 310 lwps, load averages: 0.01, 0.01, 0.01

[Former Member]

Sorry Markus but problem continues. This is the content of 'Database errors' file:

15 ERR 11277 IPC create_sem: semget error, No space left on device

15 ERR 11000 d0_aopen Error during creating semaphore, resource problem

[markus_doehr2]

What´s the output of

cat /etc/project
cat /etc/user_attr

Markus

[markus_doehr2]

Did you create an /etc/project file to increase the limits?

Markus

[Former Member]

No. I do not have clear if I had to do with this version of OpenSolaris. Is there any recommendation regarding the most appropriate settings?. I'm new in Solaris.

[markus_doehr2]

We use for our systems the following configuration - those are just upper limits, no space is "reserved":

projadd -p <projectnumer> -c "<sap-system-name>" -U <application-user>,<database-user>,<database-owner> \
-K 'project.max-sem-ids=(priv,4096,deny)' \
-K 'process.max-sem-nsems=(priv,2048,deny)' \
-K 'process.max-file-descriptor=(priv,1024000,deny)' \
-K 'project.max-shm-ids=(priv,4096,deny)' \
-K 'project.max-shm-memory=(priv,18446744073709551615,deny)' \
<projectname>

Then you need to assign the users to the project in /etc/user_attr:

<username>::::project=<projectname>

Stop all processes (including x_server), logoff and log back on - then start the x_server.

Markus