Infrastructure at your Service

OFFERING EXPERTISE TRAINING NEWSROOM ABOUT DBI BLOG CONTACT

Documentum Increase the number of concurrent_sessions
By Morgan Patou April 1, 2017 Entreprise content management No Comments

In Documentum, there is a parameter named concurrent_sessions which basically defines how many sessions a
Content Server can open simultaneously. This parameter is defined in the server.ini file (or
server_<dm_server_config.object_name>.ini on a Remote Content Server) of each docbase and it has a default value
of 100.

An empty Content Server with an IndexAgent and D2 installed (without user using it) will usually take around 10
sessions for the jobs, for the searches, aso As soon as there are users in the environment, the number of
concurrent sessions will quickly grow and therefore depending on how many users you have, you may (will) need to
increase this limit. To be more precise, the concurrent_sessions controls the number of connections the server can
handle concurrently. This number must take into account not only the number of users who are using the repository
concurrently, but also the operations those users are executing. Some operations require a separate connection to
complete. For example:

Issuing an IDfQuery.execute method with the readquery flag set to FALSE causes an internal connection
request
Executing an apply method or an EXECUTE DQL statement starts another connection
When the agent exec executes a job, it generally requires two additional connections
Issuing a full-text query requires an additional connection
aso

Infrastructure at your Service
OFFERING EXPERTISE TRAINING NEWSROOM ABOUT DBI BLOG CONTACT
Do you already know how to increase the number of allowed concurrent sessions? Im sure you do, its pretty easy:

1. Calculate the appropriate number of concurrent sessions needed based on the information provided above
2. Openthe file $DOCUMENTUM/dba/config/DOCBASE/server.ini andreplace concurrent_sessions = 100 with
the desired value (concurrent_sessions = 500 for example)
3. Restart the docbase DOCBASE using your custom script of the default Documentum scripts under
$DOCUMENTUM/dba
4. Ensure that the Database used can handle the new number of sessions properly and see if you need to increase
the sessions/processes for that

To know how many sessions are currently used, its pretty simple, you can just execute the DQL execute
show_sessions but be aware that all sessions will be listed and thats not exactly what we want. Therefore you need
to keep only the ones with a dormancy_status that is Active in the final count otherwise the value will be wrong. The
number of active sessions is not only linked to a docbase butalso toa Content Server (to be more precise, it is only
linked toa dm_server_config object). This means that if you have a High Availability environment, each Content
Server (each dm_server_config object) will have its own number of active sessions. This also means that you need to
take this into account when calculating how many concurrent sessions you need.

For example if you calculated that you will need a total of 500 concurrent sessions (again its not the number of
concurrent users!) for a docbase, then:

If you have only one Content Server, you will need to set concurrent_sessions = 500 on the server.ini file of
this docbase.
If you have two Content Servers (two dm_server_config objects) for the docbase, then you can just set
concurrent_sessions = 275 on each server.ini files. Yes I know 2*275 isnt really equal to 500 but thats
because each Content Server will need its internal sessions for the jobs, searches, aso In addition to that,
the Content Servers might need to talk to each other so these 25 additional sessions wouldnt reallyhurt.

Now is the above procedure working for any value of the concurrent_sessions? Well the answer to this question is
actually the purpose of this blog: yes and no. From a logical point of view, there is no restriction to this value but
from a technical point of view, there is A few months ago at one of our customer, I was configuring a new
Application which had a requirement of 2150 concurrent_sessions accross a High Availability environment
composed of two Content Servers. Based on the information provided above, I started the configuration with 1100
Infrastructure at your Service
concurrent sessions on
OFFERING each Content Server
EXPERTISE to match the
TRAINING requirement.
NEWSROOMBut then when DBI
ABOUT I tried to start
BLOGthe docbase
CONTACT
again, I got the following error inside the docbase log file ($DOCUMENTUM/dba/log/DOCBASE.log):

1 ***********************************************************
2
3 Programerror:Illegalparametervalueforconcurrent_sessions:1100
4
5 ***********************************************************
6
7 Usage:./documentumdocbase_name<docbasename>init_file<filename>[o<option>]
8
9 docbase_name:nameofdocbase
10 init_file:nameofserver.inifile(includingpath)which
11 containstheserverstartupparameters
12
13 Usage:./documentumh

As you can see, the docbase refuses to start with a number of concurrent sessions set to 1100. Whats the reason
behind that? There is an artificial limit set to 1020. This is actually mentioned in the documentation:
The maximum number of concurrent sessions is dependent on the operating system of the server host machine.
The limit is:

3275 for Windows systems

1020 for Linux, Solaris, and AIX systems

So why is therea limit? Why 1020? This limit is linked to the FD_SETSIZE value. The documentation on FD_SETSIZE
says the following:

An fd_set is a fixed size buffer. Executing FD_CLR() or FD_SET() with a value of fd that is negative or is equal to or larger than F

Thus FD_SETSIZE doesnt explicitly limit the number of file descriptors that can be worked on with the system
select() call. Inside every UNIX process, for its PID, Documentum maintain a corresponding list (of pointers) of file
descriptors. In UNIX based systems, every Documentum session is created as a separate process. Since the number
of sessions created directly depends on the number of file descriptors in an OS, each of these processes will be
having a list of the file descriptors within their process which will be taking a good chunk of physical memory. With
this technical reasoning the value 1020 has been set to be the max concurrent sessions available by default in
Documentum.

Infrastructure
So basically this limit ofat your
1020 has Service
been set arbitrary by EMC to stay within the default OS (kernel) value which is set
OFFERING EXPERTISE
TRAINING NEWSROOM ABOUT DBI BLOG
CONTACT

to 1024 (can be checked with ulimit -Sa for example). An EMC internal task (CS-40186) was opened to discuss this
point and to discuss the possibility to increase this maximum number. Since the current default limit is set only in
regards to the default OS value of 1024, if this value is increased to 4096 for example (which was our case since the
beginning), then there is no real reason to be stuck at 1020 on Documentum side. The Engineering Team
implemented a change in the binaries that allows changing the limit. This is done by adding the environment
variable DM_FD_SETSIZE.

Therefore to change the concurrent sessions above 1020 (1100 in this example) and in addition to the steps already
mentioned before, you also need to do the following (depending on your OS, you might need to update the .bashrc or
.profile files instead):

1 echo"exportDM_FD_SETSIZE=1200">>~/.bash_profile
2 source~/.bash_profile
3 $DOCUMENTUM/dba/dm_start_DOCBASE

With this environment variable DM_FD_SETSIZE now set to 1200, we can use 1100 concurrent sessions without
issue. The value that will be used for the concurrent_sessions will be the one from the server.ini file. We just need to
define a DM_FD_SETSIZE variable with a value equal or bigger than what we want. Also, I didnt mention the ulimit
butof course, youalso need to set the limits ofyour OS accordingly (this is done in the file /etc/limits.conf or inside
any file under /etc/limits.d/).

Leave a Reply
Name *
 Email *
Infrastructure at your Service
OFFERING EXPERTISE TRAINING NEWSROOM ABOUT DBI BLOG CONTACT

Website

seven =2

SUBMITCOMMENT

Post view(s) : 1,392

Search...

CATEGORIES

Application integration & Middleware

Business Intelligence

Cloud

Database Administration & Monitoring

Database management

Infrastructure
Development at your Service
& Performance
OFFERING EXPERTISE TRAINING NEWSROOM ABOUT DBI BLOG CONTACT
Entreprise content management

Hardware & Storage

Operation systems

Technology Survey

RECENT ARTICLES

What is in a transportable tablespace dumpfile?

Oracle 12cR2 : Optimizer Statistics Advisor

PostgreSQL on a Pure Storage All Flash Array Populating PostgreSQL

Can you open PDB$SEED read write?

Testing new PostgreSQL features before alpha/beta/rc releases

TAG CLOUD

12.2 AlwaysOn Availability Groups Cloud Cloud Computing Cluster Data Guard Database DBA Documentum

Enterprisedb Exadata GoldenGate High Availability In-Memory Installation Integration Services Linux Linux/UNIX

Microsoft Migration Monitoring Multitenant Optimizer Oracle Oracle 11g Oracle 12c
Oracle Enterprise Manager Oracle Enterprise Manager Cloud 12c Oracle OpenWorld Oracle WebLogic Performance

PostgreSQL PowerShell Reporting Services RMAN Security SQL SQL Server SQL Server 2008

SQL Server 2012 SQL Server 2014 SQL Server 2016 Troubleshooting UKOUG

BLOG ROLL

Florian Haas' blog

Dirk Nachbar's blog on Oracle Fusion Middleware & Application Server


Infrastructure at your
Oracle Scratchpad - Jonathan Service
Lewis' blog
OFFERING EXPERTISE TRAINING NEWSROOM ABOUT DBI BLOG CONTACT
Martin Bach's blog

Striving for optimal performance - Chris Antognini's blog

The Tom Kyte Blog (Ask Tom)

Blog of Adar-Consult

Alex Gorbachev's blog

Marcus Mnnig's Oracle & Mumbai Blog

Morgan Patou
Senior Consultant

Name

Company

E-Mail

Phone Number