Embed Size (px)
Citation preview
IBM
Tivoli
Access
Manager
for
e-business
Performance
Tuning
Guide
Version
5.1
SC32-1351-00
���
IBM
Tivoli
Access
Manager
for
e-business
Performance
Tuning
Guide
Version
5.1
SC32-1351-00
���
Note:
Before
using
this
information
and
the
product
it
supports,
read
the
information
in
“Notices,”
on
page
69.
First
Edition
(November
2003)
©
Copyright
International
Business
Machines
Corporation
2001,
2003.
All
rights
reserved.
US
Government
Users
Restricted
Rights
–
Use,
duplication
or
disclosure
restricted
by
GSA
ADP
Schedule
Contract
with
IBM
Corp.
Contents
Preface
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. vii
Who
should
read
this
book
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. vii
What
this
book
contains
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. viii
Publications
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. viii
Release
information
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. viii
Base
information
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. ix
Web
security
information
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. ix
Developer
references
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. x
Technical
supplements
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. x
Related
publications
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. x
Accessing
publications
online
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiii
Accessibility
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiv
Contacting
software
support
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiv
Conventions
used
in
this
book
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiv
Typeface
conventions
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xiv
Operating
system
differences
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. xv
Chapter
1.
Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 1
High-level
performance
tuning
steps
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 1
Performance
tuning
tasks
for
master
IBM
Directory
server
.
.
.
.
.
.
.
. 2
Performance
tuning
tasks
for
replica
IBM
Directory
server
.
.
.
.
.
.
.
. 3
Disk
and
memory
requirements
for
the
IBM
Directory
server
.
.
.
.
.
.
.
. 3
Memory
requirements
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 3
Disk
requirements
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 3
CPU
and
disk
speed
requirements
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 4
Common
performance
tuning
tasks
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 5
Perform
the
full
set
of
performance
tuning
tasks
.
.
.
.
.
.
.
.
.
.
.
. 5
Perform
the
performance
tuning
tasks
to
prepare
for
the
loading
of
a
large
number
of
users
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 6
Perform
the
performance
tuning
tasks
after
a
large
number
of
updates
have
been
made
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 7
Restore
an
IBM
Directory
server
from
a
DB2
backup
.
.
.
.
.
.
.
.
.
. 7
UNIX
operating
system
tuning
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 8
Resource
limits
on
UNIX
systems
(ulimit)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 8
Solaris
operating
system
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 8
AIX
operating
system
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 9
AIX
environment
variable
performance
tuning
tasks
.
.
.
.
.
.
.
.
.
.
. 11
General
IBM
Directory
performance
tuning
tasks
.
.
.
.
.
.
.
.
.
.
.
. 11
Restart
the
IBM
Directory
server
to
finish
configuration
.
.
.
.
.
.
.
.
. 11
Verify
the
change
log
is
not
configured
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 11
Verify
that
the
IBM
Directory
server
audit
logging
is
turned
off
.
.
.
.
.
.
. 11
Stop
the
IBM
Directory
server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 12
Perform
DB2
parameter
tuning
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 12
Check
for
missing
and
extra
indexes
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 14
Tune
the
IBM
Directory
Server
configuration
file
.
.
.
.
.
.
.
.
.
.
.
. 15
Create
the
suffix
objects
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 17
Preparing
to
load
users
before
configuring
Tivoli
Access
Manager
.
.
.
.
.
. 18
Add
the
Tivoli
Access
Manager
schema
to
the
IBM
Directory
server
.
.
.
. 18
Create
a
minimum,
unconfigured
Tivoli
Access
Manager
directory
object
space
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 19
Create
a
minimum,
unconfigured
Tivoli
Access
Manager
subdomain
object
space
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 19
©
Copyright
IBM
Corp.
2001,
2003
iii
Check
and
add
Tivoli
Access
Manager
ACLs
to
all
suffix
objects
.
.
.
.
.
. 20
Perform
a
DB2
reorgchk
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 21
Preparing
to
expand
to
a
large
registry
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 21
Stop
the
IBM
Directory
server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 21
Force
all
DB2
connections
to
be
closed
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 22
Back
up
the
database
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 22
Create
the
(AEID,DEID)
index
on
the
DB2
LDAP_DESC
table
.
.
.
.
.
. 22
Disable
the
DB2
statistic
performance
tuning
tasks
.
.
.
.
.
.
.
.
.
. 23
Distribute
the
database
across
multiple
disk
drives
.
.
.
.
.
.
.
.
.
.
. 23
Adding
users
and
groups
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 25
Load
users
or
groups
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 25
Add
Tivoli
Access
Manager
ACLs
not
created
by
the
bulkload
utility
.
.
.
. 25
Perform
a
DB2
Backup
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 26
Tuning
after
a
large
number
of
updates
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 26
Redo
the
DB2
tuning
parameters
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 26
Recheck
for
missing
and
extra
indexes
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 27
Perform
a
DB2
reorgchk
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 27
Perform
DB2
statistics
performance
tuning
tasks
.
.
.
.
.
.
.
.
.
.
. 27
Start
the
IBM
Directory
server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 28
Test
performance
of
the
registry
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 28
Chapter
2.
IBM
Directory
information
and
utilities
.
.
.
.
.
.
.
.
.
.
. 31
Use
of
IBM
Directory
with
Tivoli
Access
Manager
.
.
.
.
.
.
.
.
.
.
.
. 31
Use
of
DB2
with
LDAP
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 32
Distributing
the
database
across
multiple
physical
disks
.
.
.
.
.
.
.
.
.
. 33
IBM
Directory
tablespaces
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 33
Create
file
systems
and
directories
on
the
target
disks
.
.
.
.
.
.
.
.
. 34
Backing
up
the
existing
database
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 35
Perform
a
redirected
restore
of
the
database
.
.
.
.
.
.
.
.
.
.
.
.
. 35
DB2
backup
and
restore
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 37
Monitoring
LDAP
performance
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 38
Concurrent
updates
on
Symmetric
Multi-Processor
systems
.
.
.
.
.
.
.
. 38
Creating
large
numbers
of
users
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 39
LDAP
bulkload
utility
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 39
Disk
space
requirements
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 40
Bulk
loading
and
ACLs
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 41
Using
the
Tivoli
Access
Manager
scripts
.
.
.
.
.
.
.
.
.
.
.
.
.
. 41
Adding
a
large
number
of
members
to
a
group
.
.
.
.
.
.
.
.
.
.
.
. 43
Adding
groups
and
the
transaction
log
parameters
.
.
.
.
.
.
.
.
.
.
. 45
Using
the
group
scripts
together
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 45
Limiting
the
number
of
users
returned
from
pdadmin
user
list
command
.
.
.
. 46
LDAP
cache
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 46
Setting
the
cache
parameters
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 47
Choosing
cache
values
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 47
Verifying
the
LDAP
cache
resources
usage
.
.
.
.
.
.
.
.
.
.
.
.
. 48
Analyzing
performance
problems
with
DB2
statement
monitoring
and
explain
48
Chapter
3.
Tuning
Tivoli
Access
Manager
WebSEAL,
plug-ins
for
Web
servers,
and
authorization
server
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 51
General
purpose
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 51
auth-using-compare
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 51
user-and-group-in-same-suffix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 51
policy-cache-minimum-size
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 52
Special
case
purposes
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 52
LDAP
root
administrator
account
(cn=root)
.
.
.
.
.
.
.
.
.
.
.
.
.
. 52
Load
balancing
between
LDAP
replicas
(WebSEAL
only)
.
.
.
.
.
.
.
. 53
iv
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
SSL
between
Tivoli
Access
Manager
and
LDAP
.
.
.
.
.
.
.
.
.
.
.
. 53
SSL
session
cache,
user
credential
cache,
and
memory
use
.
.
.
.
.
.
. 53
Number
of
worker
threads
for
WebSEAL
.
.
.
.
.
.
.
.
.
.
.
.
.
. 54
Optimal
heap
allocation
on
Solaris
SMP
systems
.
.
.
.
.
.
.
.
.
.
. 55
IRA
tuning
information
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 56
Process
the
WebSEAL
logs
for
throughput
information
.
.
.
.
.
.
.
.
. 60
Chapter
4.
Tuning
the
AIX
operating
system
for
Tivoli
Access
Manager
and
LDAP
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 61
Chapter
5.
Tuning
process
memory
size
limits
.
.
.
.
.
.
.
.
.
.
.
. 63
Increasing
the
operating
system
process
memory
size
limits
.
.
.
.
.
.
.
. 63
AIX-specific
process
size
limits
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 63
Setting
the
maximum
number
of
AIX
data
segments
.
.
.
.
.
.
.
.
.
. 63
AIX
data
segments
and
LDAP
process
DB2
connections
.
.
.
.
.
.
.
. 64
Verifying
process
data
segment
usage
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 64
Chapter
6.
Troubleshooting
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 65
Problem:
errors
when
starting
the
IBM
Directory
server
.
.
.
.
.
.
.
.
.
. 65
Problem:
the
wrong
number
of
processors
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 66
Problem:
LDAP
or
DB2
fails
to
start
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 66
Problem:
LDAP
or
DB2
fails
to
start
after
a
DB2
restore
.
.
.
.
.
.
.
.
.
. 66
Problem:
insufficient
size
for
the
maximum
shared
memory
.
.
.
.
.
.
.
. 66
Problem:
the
user
registry
is
not
available
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 66
Problem:
no
results
returned
when
results
are
expected
.
.
.
.
.
.
.
.
.
. 67
Problem:
the
DB2
runstat
command
fails
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 67
Problem:
the
server
stops
unexpectedly
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 67
Problem:
the
DB2
backup
fails
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 67
Problem:
the
database
transaction
log
is
full
.
.
.
.
.
.
.
.
.
.
.
.
.
. 68
Appendix.
Notices
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 69
Trademarks
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 71
Index
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 73
Contents
v
vi
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Preface
This
guide
provides
information
on
tuning
the
IBM
Tivoli
Directory
Server,
some
Tivoli
Access
Manager
servers
(including
the
authorization
server,
WebSEAL
and
the
plug-ins
for
Web
servers),
and
the
AIX
operating
system
for
best
performance
in
an
environment
where
Tivoli
Access
Manager
is
deployed.
With
respect
to
the
IBM
Tivoli
Directory
Server,
this
guide
provides
information
on
resource
planning,
configuring,
tuning,
and
loading
of
the
IBM
Tivoli
Directory
Server.
For
the
Tivoli
Access
Manager
servers,
WebSEAL,
and
the
plug-ins
for
Web
servers,
this
guide
provides
information
on
some
of
the
choices
for
tuning
and
the
implications
of
those
choices.
For
the
AIX
operating
system,
this
guide
recommends
some
settings
that
have
been
found
to
improve
performance
with
Tivoli
Access
Manager.
Information
on
how
to
trouble
shoot
common
problems
that
are
encountered
during
the
processes
of
tuning
a
Tivoli
Access
Manager
environment
is
also
provided.
Attention
Performance
tuning
sample
scripts
referred
to
in
this
guide
are
located
at:
http://www3.software.ibm.com/ibmdl/pub/software/tivoli_support/misc/Security/AMeB/am5.1/tuning_guide_scripts.tar.
Or,
you
can
FTP
the
files
from:
ftp://ftp.software.ibm.com/software/tivoli_support/misc/Security/AMeB/am5.1/tuning_guide_scripts.tar
This
Web
page
requires
a
registered
user
name
and
password.
The
tuning
guide
scripts
provide
examples
of
how
you
can
automate
tuning
in
the
IBM
Tivoli
Directory
Server
(IBM
Directory
server)
section
of
this
document.
The
scripts
are
provided
“as
is”
with
no
guarantee
that
the
scripts
will
work
properly
in
every
environment.
You
should
thoroughly
test
the
scripts
first
in
a
non-production
environment
before
you
use
the
scripts
on
machines
in
a
production
environment.
The
scripts
are
of
most
use
in
a
UNIX-like
environment
where
the
ksh
command
shell
exists
and
where
UNIX
utilities
such
as
awk,
grep,
and
other
utilities
are
present.
Who
should
read
this
book
This
guide
is
for
system
administrators
responsible
for
configuring,
tuning,
and
loading
IBM
Directory
servers
for
Tivoli
Access
Manager.
It
is
also
for
those
responsible
for
tuning
the
IBM
Directory
server,
WebSEAL,
Plug-in
for
Web
Servers,
or
the
AIX
operating
system
for
best
performance.
Readers
should
be
familiar
with
the
following:
v
Microsoft®
Windows®
and
UNIX®
operating
systems
v
Database
architecture
and
concepts
©
Copyright
IBM
Corp.
2001,
2003
vii
v
Security
management
v
Internet
protocols,
including
HTTP,
HTTPS,
TCP/IP,
File
Transfer
Protocol
(FTP),
and
Telnet
v
Lightweight
Directory
Access
Protocol
(LDAP)
and
directory
services
v
A
supported
user
registry
v
Authentication
and
authorization
v
Access
Manager
security
model
and
its
capabilities
If
you
are
enabling
Secure
Sockets
Layer
(SSL)
communication,
you
also
should
be
familiar
with
SSL
protocol,
key
exchange
(public
and
private),
digital
signatures,
cryptographic
algorithms,
and
certificate
authorities.
What
this
book
contains
This
guide
contains
the
following
sections:
v
Chapter
1,
“Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager”
v
Chapter
2,
“IBM
Directory
information
and
utilities”
v
Chapter
3,
“Tuning
Tivoli
Access
Manager
WebSEAL,
plug-ins
for
Web
servers,
and
authorization
server”
v
Chapter
4,
“Tuning
the
AIX
operating
system
for
Tivoli
Access
Manager
and
LDAP”
v
Chapter
5,
“Tuning
process
memory
size
limits”
v
Chapter
6,
“Troubleshooting”
Publications
Review
the
descriptions
of
the
Tivoli
Access
Manager
library,
the
prerequisite
publications,
and
the
related
publications
to
determine
which
publications
you
might
find
helpful.
After
you
determine
the
publications
you
need,
refer
to
the
instructions
for
accessing
publications
online.
Additional
information
about
the
IBM
Tivoli
Access
Manager
for
e-business
product
itself
can
be
found
at:
http://www.ibm.com/software/tivoli/products/access-mgr-e-bus/
The
Tivoli
Access
Manager
library
is
organized
into
the
following
categories:
v
“Release
information”
v
“Base
information”
on
page
ix
v
“Web
security
information”
on
page
ix
v
“Developer
references”
on
page
x
v
“Technical
supplements”
on
page
x
Release
information
v
IBM
Tivoli
Access
Manager
for
e-business
Read
This
First
(GI11-4155-00)
Provides
information
for
installing
and
getting
started
using
Tivoli
Access
Manager.
v
IBM
Tivoli
Access
Manager
for
e-business
Release
Notes
(GI11-4156-00)
viii
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Provides
late-breaking
information,
such
as
software
limitations,
workarounds,
and
documentation
updates.
Base
information
v
IBM
Tivoli
Access
Manager
Base
Installation
Guide
(SC32-1362-00)
Explains
how
to
install
and
configure
the
Tivoli
Access
Manager
base
software,
including
the
Web
Portal
Manager
interface.
This
book
is
a
subset
of
IBM
Tivoli
Access
Manager
for
e-business
Web
Security
Installation
Guide
and
is
intended
for
use
with
other
Tivoli
Access
Manager
products,
such
as
IBM
Tivoli
Access
Manager
for
Business
Integration
and
IBM
Tivoli
Access
Manager
for
Operating
Systems.
v
IBM
Tivoli
Access
Manager
Base
Administration
Guide
(SC32-1360-00)
Describes
the
concepts
and
procedures
for
using
Tivoli
Access
Manager
services.
Provides
instructions
for
performing
tasks
from
the
Web
Portal
Manager
interface
and
by
using
the
pdadmin
command.
Web
security
information
v
IBM
Tivoli
Access
Manager
for
e-business
Web
Security
Installation
Guide
(SC32-1361-00)
Provides
installation,
configuration,
and
removal
instructions
for
the
Tivoli
Access
Manager
base
software
as
well
as
the
Web
Security
components.
This
book
is
a
superset
of
IBM
Tivoli
Access
Manager
Base
Installation
Guide.
v
IBM
Tivoli
Access
Manager
Upgrade
Guide
(SC32-1369-00)
Explains
how
to
upgrade
from
Tivoli
SecureWay
Policy
Director
Version
3.8
or
previous
versions
of
Tivoli
Access
Manager
to
Tivoli
Access
Manager
Version
5.1.
v
IBM
Tivoli
Access
Manager
for
e-business
WebSEAL
Administration
Guide
(SC32-1359-00)
Provides
background
material,
administrative
procedures,
and
technical
reference
information
for
using
WebSEAL
to
manage
the
resources
of
your
secure
Web
domain.
v
IBM
Tivoli
Access
Manager
for
e-business
IBM
WebSphere
Application
Server
Integration
Guide
(SC32-1368-00)
Provides
installation,
removal,
and
administration
instructions
for
integrating
Tivoli
Access
Manager
with
IBM
WebSphere®
Application
Server.
v
IBM
Tivoli
Access
Manager
for
e-business
IBM
WebSphere
Edge
Server
Integration
Guide
(SC32-1367-00)
Provides
installation,
removal,
and
administration
instructions
for
integrating
Tivoli
Access
Manager
with
the
IBM
WebSphere
Edge
Server
application.
v
IBM
Tivoli
Access
Manager
for
e-business
Plug-in
for
Web
Servers
Integration
Guide
(SC32-1365-00)
Provides
installation
instructions,
administration
procedures,
and
technical
reference
information
for
securing
your
Web
domain
using
the
plug-in
for
Web
servers.
v
IBM
Tivoli
Access
Manager
for
e-business
BEA
WebLogic
Server
Integration
Guide
(SC32-1366-00)
Provides
installation,
removal,
and
administration
instructions
for
integrating
Tivoli
Access
Manager
with
BEA
WebLogic
Server.
v
IBM
Tivoli
Access
Manager
for
e-business
IBM
Tivoli
Identity
Manager
Provisioning
Fast
Start
Guide
(SC32-1364-00)
Preface
ix
Provides
an
overview
of
the
tasks
related
to
integrating
Tivoli
Access
Manager
and
Tivoli
Identity
Manager
and
explains
how
to
use
and
install
the
Provisioning
Fast
Start
collection.
Developer
references
v
IBM
Tivoli
Access
Manager
for
e-business
Authorization
C
API
Developer
Reference
(SC32-1355-00)
Provides
reference
material
that
describes
how
to
use
the
Tivoli
Access
Manager
authorization
C
API
and
the
Tivoli
Access
Manager
service
plug-in
interface
to
add
Tivoli
Access
Manager
security
to
applications.
v
IBM
Tivoli
Access
Manager
for
e-business
Authorization
Java
Classes
Developer
Reference
(SC32-1350-00)
Provides
reference
information
for
using
the
Java™
language
implementation
of
the
authorization
API
to
enable
an
application
to
use
Tivoli
Access
Manager
security.
v
IBM
Tivoli
Access
Manager
for
e-business
Administration
C
API
Developer
Reference
(SC32-1357-00)
Provides
reference
information
about
using
the
administration
API
to
enable
an
application
to
perform
Tivoli
Access
Manager
administration
tasks.
This
document
describes
the
C
implementation
of
the
administration
API.
v
IBM
Tivoli
Access
Manager
for
e-business
Administration
Java
Classes
Developer
Reference
(SC32-1356-00)
Provides
reference
information
for
using
the
Java
language
implementation
of
the
administration
API
to
enable
an
application
to
perform
Tivoli
Access
Manager
administration
tasks.
v
IBM
Tivoli
Access
Manager
for
e-business
Web
Security
Developer
Reference
(SC32-1358-00)
Provides
administration
and
programming
information
for
the
cross-domain
authentication
service
(CDAS),
the
cross-domain
mapping
framework
(CDMF),
and
the
password
strength
module.
Technical
supplements
v
IBM
Tivoli
Access
Manager
for
e-business
Command
Reference
(SC32-1354-00)
Provides
information
about
the
command
line
utilities
and
scripts
provided
with
Tivoli
Access
Manager.
v
IBM
Tivoli
Access
Manager
Error
Message
Reference
(SC32-1353-00)
Provides
explanations
and
recommended
actions
for
the
messages
produced
by
Tivoli
Access
Manager.
v
IBM
Tivoli
Access
Manager
for
e-business
Problem
Determination
Guide
(SC32-1352-00)
Provides
problem
determination
information
for
Tivoli
Access
Manager.
v
IBM
Tivoli
Access
Manager
for
e-business
Performance
Tuning
Guide
(SC32-1351-00)
Provides
performance
tuning
information
for
an
environment
consisting
of
Tivoli
Access
Manager
with
the
IBM
Tivoli
Directory
server
as
the
user
registry.
Related
publications
This
section
lists
publications
related
to
the
Tivoli
Access
Manager
library.
x
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
The
Tivoli
Software
Library
provides
a
variety
of
Tivoli
publications
such
as
white
papers,
datasheets,
demonstrations,
redbooks,
and
announcement
letters.
The
Tivoli
Software
Library
is
available
on
the
Web
at:
http://www.ibm.com/software/tivoli/library/
The
Tivoli
Software
Glossary
includes
definitions
for
many
of
the
technical
terms
related
to
Tivoli
software.
The
Tivoli
Software
Glossary
is
available,
in
English
only,
from
the
Glossary
link
on
the
left
side
of
the
Tivoli
Software
Library
Web
page
http://www.ibm.com/software/tivoli/library/
IBM
Global
Security
Kit
Tivoli
Access
Manager
provides
data
encryption
through
the
use
of
the
IBM
Global
Security
Kit
(GSKit)
Version
7.0.
GSKit
is
included
on
the
IBM
Tivoli
Access
Manager
Base
CD
for
your
particular
platform,
as
well
as
on
the
IBM
Tivoli
Access
Manager
Web
Security
CDs,
the
IBM
Tivoli
Access
Manager
Web
Administration
Interfaces
CDs,
and
the
IBM
Tivoli
Access
Manager
Directory
Server
CDs.
The
GSKit
package
provides
the
iKeyman
key
management
utility,
gsk7ikm,
which
is
used
to
create
key
databases,
public-private
key
pairs,
and
certificate
requests.
The
following
document
is
available
on
the
Tivoli
Information
Center
Web
site
in
the
same
section
as
the
IBM
Tivoli
Access
Manager
product
documentation:
v
IBM
Global
Security
Kit
Secure
Sockets
Layer
and
iKeyman
User’s
Guide
(SC32-1363-00)
Provides
information
for
network
or
system
security
administrators
who
plan
to
enable
SSL
communication
in
their
Tivoli
Access
Manager
environment.
IBM
Tivoli
Directory
Server
IBM
Tivoli
Directory
Server,
Version
5.2,
is
included
on
the
IBM
Tivoli
Access
Manager
Directory
Server
CD
for
the
desired
operating
system.
Note:
IBM
Tivoli
Directory
Server
is
the
new
name
for
the
previously
released
software
known
as:
v
IBM
Directory
Server
(Version
4.1
and
Version
5.1)
v
IBM
SecureWay
Directory
Server
(Version
3.2.2)
IBM
Directory
Server
Version
4.1,
IBM
Directory
Server
Version
5.1,
and
IBM
Tivoli
Directory
Server
Version
5.2
are
all
supported
by
IBM
Tivoli
Access
Manager
Version
5.1.
Additional
information
about
IBM
Tivoli
Directory
Server
can
be
found
at:
http://www.ibm.com/software/network/directory/library/
IBM
DB2
Universal
Database
IBM
DB2®
Universal
Database™
Enterprise
Server
Edition,
Version
8.1
is
provided
on
the
IBM
Tivoli
Access
Manager
Directory
Server
CD
and
is
installed
with
the
IBM
Tivoli
Directory
Server
software.
DB2
is
required
when
using
IBM
Tivoli
Directory
Server,
z/OS™,
or
OS/390®
LDAP
servers
as
the
user
registry
for
Tivoli
Access
Manager.
Additional
information
about
DB2
can
be
found
at:
http://www.ibm.com/software/data/db2/
Preface
xi
IBM
WebSphere
Application
Server
IBM
WebSphere
Application
Server,
Advanced
Single
Server
Edition
5.0,
is
included
on
the
IBM
Tivoli
Access
Manager
Web
Administration
Interfaces
CD
for
the
desired
operating
system.
WebSphere
Application
Server
enables
the
support
of
both
the
Web
Portal
Manager
interface,
which
is
used
to
administer
Tivoli
Access
Manager,
and
the
Web
Administration
Tool,
which
is
used
to
administer
IBM
Tivoli
Directory
Server.
IBM
WebSphere
Application
Server
Fix
Pack
2
is
also
required
by
Tivoli
Access
Manager
and
is
provided
on
the
IBM
Tivoli
Access
Manager
WebSphere
Fix
Pack
CD.
Additional
information
about
IBM
WebSphere
Application
Server
can
be
found
at:
http://www.ibm.com/software/webservers/appserv/infocenter.html
IBM
Tivoli
Access
Manager
for
Business
Integration
IBM
Tivoli
Access
Manager
for
Business
Integration,
available
as
a
separately
orderable
product,
provides
a
security
solution
for
IBM
MQSeries®,
Version
5.2,
and
IBM
WebSphere®
MQ
for
Version
5.3
messages.
IBM
Tivoli
Access
Manager
for
Business
Integration
allows
WebSphere
MQSeries
applications
to
send
data
with
privacy
and
integrity
by
using
keys
associated
with
sending
and
receiving
applications.
Like
WebSEAL
and
IBM
Tivoli
Access
Manager
for
Operating
Systems,
IBM
Tivoli
Access
Manager
for
Business
Integration,
is
one
of
the
resource
managers
that
use
the
services
of
IBM
Tivoli
Access
Manager.
Additional
information
about
IBM
Tivoli
Access
Manager
for
Business
Integration
can
be
found
at:
http://www.ibm.com/software/tivoli/products/access-mgr-bus-integration/
The
following
documents
associated
with
IBM
Tivoli
Access
Manager
for
Business
Integration
Version
5.1
are
available
on
the
Tivoli
Information
Center
Web
site:
v
IBM
Tivoli
Access
Manager
for
Business
Integration
Administration
Guide
(SC23-4831-01)
v
IBM
Tivoli
Access
Manager
for
Business
Integration
Problem
Determination
Guide
(GC23-1328-00)
v
IBM
Tivoli
Access
Manager
for
Business
Integration
Release
Notes
(GI11-0957-01)
v
IBM
Tivoli
Access
Manager
for
Business
Integration
Read
This
First
(GI11-4202-00)
IBM
Tivoli
Access
Manager
for
WebSphere
Business
Integration
Brokers
IBM
Tivoli
Access
Manager
for
WebSphere
Business
Integration
Brokers,
available
as
part
of
IBM
Tivoli
Access
Manager
for
Business
Integration,
provides
a
security
solution
for
WebSphere
Business
Integration
Message
Broker,
Version
5.0
and
WebSphere
Business
Integration
Event
Broker,
Version
5.0.
IBM
Tivoli
Access
Manager
for
WebSphere
Business
Integration
Brokers
operates
in
conjunction
with
Tivoli
Access
Manager
to
secure
JMS
publish/subscribe
applications
by
providing
password
and
credentials-based
authentication,
centrally-defined
authorization,
and
auditing
services.
Additional
information
about
IBM
Tivoli
Access
Manager
for
WebSphere
Integration
Brokers
can
be
found
at:
http://www.ibm.com/software/tivoli/products/access-mgr-bus-integration/
xii
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
The
following
documents
associated
with
IBM
Tivoli
Access
Manager
for
WebSphere
Integration
Brokers,
Version
5.1
are
available
on
the
Tivoli
Information
Center
Web
site:
v
IBM
Tivoli
Access
Manager
for
WebSphere
Business
Integration
Brokers
Administration
Guide
(SC32-1347-00)
v
IBM
Tivoli
Access
Manager
for
WebSphere
Business
Integration
Brokers
Release
Notes
(GI11-4154-00)
v
IBM
Tivoli
Access
Manager
for
Business
Integration
Read
This
First
(GI11-4202-00)
IBM
Tivoli
Access
Manager
for
Operating
Systems
IBM
Tivoli
Access
Manager
for
Operating
Systems,
available
as
a
separately
orderable
product,
provides
a
layer
of
authorization
policy
enforcement
on
UNIX
systems
in
addition
to
that
provided
by
the
native
operating
system.
IBM
Tivoli
Access
Manager
for
Operating
Systems,
like
WebSEAL
and
IBM
Tivoli
Access
Manager
for
Business
Integration,
is
one
of
the
resource
managers
that
use
the
services
of
IBM
Tivoli
Access
Manager.
Additional
information
about
IBM
Tivoli
Access
Manager
for
Operating
Systems
can
be
found
at:
http://www.ibm.com/software/tivoli/products/access-mgr-operating-sys/
The
following
documents
associated
with
IBM
Tivoli
Access
Manager
for
Operating
Systems
Version
5.1
are
available
on
the
Tivoli
Information
Center
Web
site:
v
IBM
Tivoli
Access
Manager
for
Operating
Systems
Installation
Guide
(SC23-4829-00)
v
IBM
Tivoli
Access
Manager
for
Operating
Systems
Administration
Guide
(SC23-4827-00)
v
IBM
Tivoli
Access
Manager
for
Operating
Systems
Problem
Determination
Guide
(SC23-4828-00)
v
IBM
Tivoli
Access
Manager
for
Operating
Systems
Release
Notes
(GI11-0951-00)
v
IBM
Tivoli
Access
Manager
for
Operating
Systems
Read
Me
First
(GI11-0949-00)
IBM
Tivoli
Identity
Manager
IBM
Tivoli
Identity
Manager
Version
4.5,
available
as
a
separately
orderable
product,
enables
you
to
centrally
manage
users
(such
as
user
IDs
and
passwords)
and
provisioning
(that
is
providing
or
revoking
access
to
applications,
resources,
or
operating
systems.)
Tivoli
Identity
Manager
can
be
integrated
with
Tivoli
Access
Manager
through
the
use
of
the
Tivoli
Access
Manager
Agent.
Contact
your
IBM
account
representative
for
more
information
about
purchasing
the
Agent.
Additional
information
about
IBM
Tivoli
Identity
Manager
can
be
found
at:
http://www.ibm.com/software/tivoli/products/identity-mgr/
Accessing
publications
online
The
publications
for
this
product
are
available
online
in
Portable
Document
Format
(PDF)
or
Hypertext
Markup
Language
(HTML)
format,
or
both
in
the
Tivoli
software
library:
http://www.ibm.com/software/tivoli/library
Preface
xiii
To
locate
product
publications
in
the
library,
click
the
Product
manuals
link
on
the
left
side
of
the
library
page.
Then,
locate
and
click
the
name
of
the
product
on
the
Tivoli
software
information
center
page.
Product
publications
include
release
notes,
installation
guides,
user’s
guides,
administrator’s
guides,
and
developer’s
references.
Note:
To
ensure
proper
printing
of
publications,
select
the
Fit
to
page
check
box
in
the
Adobe
Acrobat
window
(which
is
available
when
you
click
File
→
Print).
Accessibility
Accessibility
features
help
a
user
who
has
a
physical
disability,
such
as
restricted
mobility
or
limited
vision,
to
use
software
products
successfully.
With
this
product,
you
can
use
assistive
technologies
to
hear
and
navigate
the
interface.
You
also
can
use
the
keyboard
instead
of
the
mouse
to
operate
all
features
of
the
graphical
user
interface.
Contacting
software
support
Before
contacting
IBM
Tivoli
Software
Support
with
a
problem,
refer
to
the
IBM
Tivoli
Software
Support
site
by
clicking
the
Tivoli
support
link
at
the
following
Web
site:
http://www.ibm.com/software/support/
If
you
need
additional
help,
contact
software
support
by
using
the
methods
described
in
the
IBM
Software
Support
Guide
at
the
following
Web
site:
http://techsupport.services.ibm.com/guides/handbook.html
The
guide
provides
the
following
information:
v
Registration
and
eligibility
requirements
for
receiving
support
v
Telephone
numbers,
depending
on
the
country
in
which
you
are
located
v
A
list
of
information
you
should
gather
before
contacting
customer
support
Conventions
used
in
this
book
This
reference
uses
several
conventions
for
special
terms
and
actions
and
for
operating
system-dependent
commands
and
paths.
Typeface
conventions
The
following
typeface
conventions
are
used
in
this
reference:
Bold
Lowercase
commands
or
mixed
case
commands
that
are
difficult
to
distinguish
from
surrounding
text,
keywords,
parameters,
options,
names
of
Java
classes,
and
objects
are
in
bold.
Italic
Variables,
titles
of
publications,
and
special
words
or
phrases
that
are
emphasized
are
in
italic.
Monospace
Code
examples,
command
lines,
screen
output,
file
and
directory
names
that
are
difficult
to
distinguish
from
surrounding
text,
system
messages,
text
that
the
user
must
type,
and
values
for
arguments
or
command
options
are
in
monospace.
xiv
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Operating
system
differences
This
book
uses
the
UNIX
convention
for
specifying
environment
variables
and
for
directory
notation.
When
using
the
Windows
command
line,
replace
$variable
with
%variable%
for
environment
variables
and
replace
each
forward
slash
(/)
with
a
backslash
(\)
in
directory
paths.
If
you
are
using
the
bash
shell
on
a
Windows
system,
you
can
use
the
UNIX
conventions.
Preface
xv
xvi
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Chapter
1.
Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager
This
chapter
provides
both
general
and
Tivoli
Access
Manager-specific
performance
tuning
tasks
for
the
IBM
Tivoli
Directory
Server
(referred
to
in
this
guide
as
“IBM
Directory
server”).
These
performance
tuning
tasks
optimize
the
IBM
Directory
server’s
performance
when
used
by
Tivoli
Access
Manager.
This
chapter
also
provides
information
on
planning
for
the
configuration
and
loading
of
the
IBM
Directory
server
with
consideration
for
Tivoli
Access
Manager
usage.
The
information
in
this
chapter
is
only
for
the
IBM
Directory
server,
not
the
client.
The
client
requires
no
tuning.
It
is
assumed
that
the
IBM
Directory
server
has
been
installed
and
configured.
For
information
about
installing
and
configuring
IBM
Directory
server,
see
the
IBM
Tivoli
Access
Manager
for
e-business
Web
Security
Installation
Guide
or
the
IBM
Directory
documentation.
This
guide
assumes
a
basic
understanding
of
LDAP
and
of
the
design
and
deployment
of
a
user
namespace
on
LDAP.
This
knowledge
is
prerequisite
to
understanding
some
of
the
steps
in
this
document.
For
more
information,
see
the
following
IBM
Redbooks:
v
Understanding
LDAP
v
LDAP
Implementation
Cookbook
These
documents
are
located
at:
http://www.ibm.com/redbooks
High-level
performance
tuning
steps
Because
many
of
the
IBM
Directory
server
performance
tuning
tasks
are
dependent
upon
the
order
in
which
they
are
performed,
this
chapter
identifies
the
high-level
performance
tuning
steps.
This
chapter
also
provides
the
recommended
order
in
which
lower-level
performance
tuning
tasks
are
performed
within
each
high-level
performance
tuning
step.
Following
is
a
summary
of
the
four
high-level
performance
tuning
steps.
Each
of
these
high-level
steps
is
described
in
more
detail
in
“Common
performance
tuning
tasks”
on
page
5.
The
high-level
performance
tuning
steps
include:
1.
Perform
the
full
set
of
performance
tuning
tasks
This
step
is
recommended
after
the
IBM
Directory
server
has
just
been
configured
or
if
these
performance
tuning
tasks
have
never
been
performed.
2.
Perform
the
performance
tuning
tasks
to
prepare
for
the
loading
of
a
large
number
of
users
This
step
is
recommended
when
a
large
number
of
users
are
to
be
added
to
the
IBM
Directory
server,
particularly
if
the
IBM
Directory
server
bulkload
utility
is
to
be
used.
When
the
number
of
users
to
be
bulk
loaded
is
greater
than
10,000,
it
is
recommended
that
the
tuning
guide
scripts
described
in
“LDAP
bulkload
utility”
on
page
39
be
used.
3.
Perform
the
performance
tuning
tasks
after
a
large
number
of
updates
have
been
made
This
step
is
recommended
after
a
large
number
of
updates
have
been
made,
particularly
when
the
performance
tuning
tasks
to
prepare
for
the
loading
of
a
©
Copyright
IBM
Corp.
2001,
2003
1
large
number
of
users
has
been
performed
in
high-level
step
2
on
page
1.
These
performance
tuning
tasks
undo
some
of
the
performance
tuning
tasks
that
were
used
to
prepare
for
the
large
load
and
that
might
affect
the
performance
of
normal
IBM
Directory
server
usage.
4.
Restore
an
IBM
Directory
server
from
a
DB2
backup
Because
the
tuned
state
of
a
backed-up
database
might
not
be
known,
some
general
purposes
performance
tuning
tasks
are
recommended.
If
it
is
not
known
whether
the
full
set
of
performance
tuning
tasks
have
been
performed
on
the
backed-up
database,
it
is
recommended
that
they
be
performed
after
the
restore
(see
high-level
step
1
on
page
1).
The
am_tune_ldap.sh
tuning
guide
script
provides
an
example
of
the
automation
of
the
these
four
high-level
performance
tuning
steps.
The
tuning
guide
script
must
be
run
as
the
root
user
and
run
from
the
same
directory
as
the
remaining
tuning
guide
scripts.
The
am_tune_ldap.sh
script
makes
calls
to
many
of
the
other
tuning
scripts.
There
are
no
arguments
to
this
script.
To
start
the
script,
enter:
./am_tune_ldap.sh
The
script
prompts
for
confirmation
before
proceeding
with
each
performance
tuning.
Note
on
the
tuning
guide
scripts:
The
tuning
guide
scripts
provide
examples
of
how
these
performance
tuning
tasks
could
be
automated.
The
scripts
are
provided
“as
is”
with
no
guarantee
that
the
scripts
will
work
properly
in
every
environment.
You
should
thoroughly
test
the
scripts
first
in
a
non-production
environment
before
you
use
the
scripts
on
machines
in
a
production
environment.
The
scripts
are
of
most
use
in
a
UNIX-like
environment
where
the
ksh
command
shell
exists
and
where
UNIX
utilities
such
as
awk,
grep,
su,
and
others
exist.
Performance
tuning
tasks
for
master
IBM
Directory
server
If
a
master
IBM
Directory
server
is
being
configured
and
loaded
with
users
and
groups,
the
following
order
of
configuration
and
performance
tuning
tasks
is
recommended:
Step
Performance
Tuning
Task
See
page
1.
Configure
the
IBM
Directory
server.
See
the
IBM
Director
Server
documentation
for
information
on
how
to
configure
the
server.
–
2.
Perform
the
full
set
of
performance
tuning
tasks
(see
1
on
page
1).
5
3.
Perform
the
performance
tuning
tasks
to
prepare
for
the
loading
of
a
large
number
of
users
(see
high-level
step
2
on
page
1).
6
4.
Load
the
users
and
groups.
Note:
If
more
than
10,000
users
are
to
be
loaded,
it
is
recommended
that
the
tuning
guide
scripts
described
in
“LDAP
bulkload
utility”
on
page
39
be
used.
25
5.
Perform
the
performance
tuning
tasks
after
a
large
number
of
updates
have
been
made
(see
high-level
step
3
on
page
1).
7
2
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Performance
tuning
tasks
for
replica
IBM
Directory
server
If
a
replica
IBM
Directory
server
is
being
configured,
the
following
order
of
actions
are
recommended:
Step
Performance
Tuning
Task
See
page
1.
Back
up
the
master
IBM
Directory
server
using
the
db2
backup
command.
37
2.
Configure
the
replica
IBM
Directory
server.
See
the
IBM
Director
Server
documentation
for
information
on
how
to
configure
the
server.
—
3.
Perform
the
full
set
of
performance
tuning
tasks
(see
high-level
step
1
on
page
1).
5
4.
Restore
the
replica
IBM
Directory
server
from
the
db2
backup
(see
high-level
step
4
on
page
2).
7
Disk
and
memory
requirements
for
the
IBM
Directory
server
The
disk
and
memory
requirements
for
the
IBM
Directory
server
increase
when
the
bulkload
utility
is
used.
It
is
recommended
that
the
bulkload
utility
be
used
on
a
single
IBM
Directory
server
machine
so
that
the
additional
disk
and
memory
requirements
are
isolated
to
a
single
machine.
When
multiple
IBM
Directory
servers
are
deployed,
the
bulk
loaded
IBM
Directory
server’s
DB2
database
should
be
backed
up
on
the
bulk
loaded
server
and
restored
on
all
other
IBM
Directory
servers.
For
more
information
on
the
bulkload
utility
and
the
tuning
guide
scripts
to
help
with
bulkload,
refer
to
the
“LDAP
bulkload
utility”
on
page
39.
Memory
requirements
The
memory
requirements
for
the
IBM
Directory
server
alone,
not
including
the
bulkload
utility,
follow.
For
an
IBM
Directory
server
with
less
than
a
million
Tivoli
Access
Manager
users,
the
minimum
memory
requirement
is
256
MB
and
the
optimum
is
512
MB
to
1
GB.
For
an
IBM
Directory
server
with
more
than
one
million
Tivoli
Access
Manager
users,
the
minimum
memory
requirement
is
512
MB
and
the
optimum
is
1
to
2
GB.
The
memory
requirements
for
using
the
bulkload
utility
to
load
500
thousand
Tivoli
Access
Manager
users,
or
equivalently
2
million
LDAP
objects,
are
about
750
MB.
The
memory
requirements
for
using
the
bulkload
utility
to
load
a
group
with
3
million
members
are
about
1
GB.
These
memory
requirements
vary
linearly
with
the
number
of
users
or
members
that
are
to
be
loaded.
Splitting
up
a
large
load
of
users
into
multiple
smaller
loads
is
one
way
to
control
the
memory
requirements
for
the
bulkload
utility.
Disk
requirements
The
home
directory
of
the
IBM
Directory
server’s
DB2
instance
owner,
typically
the
ldapdb2
user,
initially
holds
the
entire
DB2
database.
Part
of
that
home
directory
holds
the
DB2
tablespace
files,
and
the
remainder
holds
accounting
and
temporary
data
files.
The
disk
space
requirements
for
the
IBM
Directory
server
alone,
not
including
the
bulkload
utility,
include:
v
Accounting
and
temporary
files:
Chapter
1.
Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager
3
The
relatively
fixed-sized
portion
of
these
home
directory
files
requires
about
35-100
MB
of
disk
space,
depending
upon
the
size
of
the
DB2
transaction
log
file
defaults.
The
variable
portion
depends
upon
the
DB2
transaction
log
limits
and
various
directory
operations
that
can
use
up
this
transaction
log
space.
The
operations
that
use
up
transaction
log
space
typically
are
associated
with
bulkload.
One
operation
that
is
not
associated
with
bulkload
is
the
propagation
of
LDAP
ACLs
to
many
children
of
a
subtree.
The
IBM
Directory
server
must
perform
this
ACL
propagation
whenever
an
ACL
is
attached
to
a
parent
object
of
a
subtree
that
previously
had
no
ACLs
or
whenever
all
ACLs
are
removed
from
an
object
that
previously
had
ACLs.
Although
this
situation
should
be
rare
and
avoided,
it
is
recommended
that
disk
space
be
reserved
for
this
possible
transaction
log
growth.
Having
1.2
GB
of
reserve
disk
space
for
transaction
log
growth
allows
ACLs
to
be
propagated
to
a
subtree
containing
3
million
Tivoli
Access
Manager
users.
Running
out
of
disk
space
because
of
transaction
log
growth
might
result
in
database
corruption
that
requires
special
recovery
procedures
or
requires
restoring
from
a
backup.
v
DB2
tablespace
files:
Because
all
database
files
initially
start
out
in
the
IBM
Directory
database
instance
owner’s
home
directory,
the
DB2
tablespace
files
hold
the
actual
DB2
database
tables.
These
files
can
be
spread
across
multiple
disk
drives
or
file
systems
by
using
a
redirected
restored
discussed
later
in
this
book.
The
disk
requirements
for
the
database
tables
depend
upon
the
number
of
Tivoli
Access
Manager
users
loaded
into
the
server
and
are
about
10
KB
per
user.
Note
that
non-Tivoli
Access
Manager
users’
disk
requirements
are
lower.
For
more
information
on
DB2
tablespace
requirements,
see
“Disk
space
requirements”
on
page
40.
The
disk
space
requirements
for
the
bulkload
utility
are
in
addition
to
those
of
the
IBM
Directory
server,
and
include:
v
Bulkload
temporary
files:
In
addition
to
any
disk
space
requirements
for
LDAP
Information
File
(LDIF)
input
to
the
bulkload
utility,
the
bulkload
utility
itself
requires
about
5.5
KB
per
Tivoli
Access
Manager
user,
which
is
about
1.4
KB
per
LDAP
object.
The
temporary
space
that
is
used
by
bulkload
is
defined
by
the
–L
option
for
a
bulk
load
of
500
thousand
Tivoli
Access
Manager
users,
the
temporary
disk
space
requirements
are
2.75
GB.
This
space
is
for
DB2
load
files
that
contain
the
DB2
tables
to
be
loaded.
Splitting
the
users
to
be
loaded
into
multiple
uses
of
the
bulkload
utility
is
one
way
to
control
the
bulkload
disk
space
requirements.
The
incremental_bulkload.sh
tuning
guide
script
described
in
“incremental_bulkload.sh”
on
page
42
provides
an
increment
variable
for
splitting
up
the
load.
For
the
incremental_bulkload.sh
script,
it
is
the
directory
from
which
the
load
is
run.
v
incremental_bulkload.sh
script
temporary
files
The
incremental_bulkload.sh
script
makes
a
copy
of
the
LDIF
input
in
the
directory
from
which
it
is
run.
Using
the
incremental_bulkload.sh
script
defaults,
the
disk
requirements
for
the
temporary
LDIF
copy
are
1.6
KB
per
Tivoli
Access
Manager
user
(390
bytes
per
LDAP
object)
but
not
more
than
780
MB.
Refer
to
“LDAP
bulkload
utility”
on
page
39
for
more
information.
CPU
and
disk
speed
requirements
CPU
and
disk-speed
requirements
vary
depending
on
the
load.
You
can
follow
these
general
guidelines:
v
Many
slow
machines
can
perform
as
well
as
one
single
fast
machine.
4
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
v
CPU
speed
improves
authentication
performance.
v
Disk
speed
improves
update
or
administration
performance
(for
example,
creating
users).
Common
performance
tuning
tasks
This
section
provides
the
order
in
which
the
tasks
are
recommended
for
each
of
the
common
low-level
performance
tuning
tasks.
The
low-level
performance
tuning
tasks
are
individually
described
in
this
chapter.
Perform
the
full
set
of
performance
tuning
tasks
Follow
these
steps
if
the
IBM
Directory
server
is
not
being
restored
from
a
db2
backup
command:
Step
Performance
Tuning
Task
See
page
1.
If
the
IBM
Directory
server
has
never
been
started,
start
it
now
to
complete
the
IBM
Directory
server
configuration.
The
initial
DB2
database
tables
are
not
created
until
the
first
startup
of
the
IBM
Directory
server.
11
2.
Optionally,
back
up
the
IBM
Directory
server
using
db2
backup.
It
is
always
a
good
idea
to
back
up
the
IBM
Directory
server
before
you
make
any
major
change.
In
this
case,
the
change
is
performance
tuning.
37
3.
Check
the
UNIX
operating
system
performance
tuning
tasks.
These
performance
tuning
tasks
vary
by
operating
system
but
they
are
mostly
related
to
system
resource
limits.
8
4.
Check
whether
the
IBM
Directory
server
change
log
is
configured.
Performance
is
faster
without
the
change
log.
11
5.
Check
whether
the
IBM
Directory
server
audit-log
is
turned
off.
Performance
is
faster
with
the
audit-log
turned
off.
11
6.
Perform
the
DB2
parameter
performance
tuning
tasks.
12
7.
Optionally,
create
the
(AEID,DEID)
index
on
the
DB2
LDAP_DESC
table.
22
8.
If
not
already
done,
apply
the
Tivoli
Access
Manager
schema
to
the
IBM
Directory
server.
18
9.
Tune
the
IBM
Directory
server
configuration
file.
15
10.
Only
if
changes
were
made
to
the
IBM
Directory
server
configuration
file,
recycle
the
IBM
Directory
server.
17
11.
Verify
the
order
in
which
suffixes
are
returned
by
the
IBM
Directory
server.
17
12.
When
new
suffixes
are
added
to
the
IBM
Directory
server
configuration
file,
add
the
corresponding
LDAP
objects
to
the
IBM
Directory
server.
16
13.
When
users
are
to
be
loaded
into
the
IBM
Directory
server
before
Tivoli
Access
Manager
is
configured
into
it,
create
a
minimum,
unconfigured
Tivoli
Access
Manager
object
space.
19
14.
When
users
are
to
be
loaded
into
the
IBM
Directory
server
as
members
of
one
or
more
Tivoli
Access
Manager
domains
before
those
domains
are
configured
into
Tivoli
Access
Manager,
create
a
minimum,
unconfigured
Tivoli
Access
Manager
domain
object
space
for
each
of
those
domains.
19
Chapter
1.
Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager
5
Step
Performance
Tuning
Task
See
page
15.
Check
the
LDAP
ACLs
on
suffix
objects.
If
the
LDAP
ACLs
on
suffix
object
do
not
already
exist,
modify
them
to
contain
Tivoli
Access
Manager
ACLs.
20
16.
When
Tivoli
Access
Manager
has
not
been
configured
into
the
IBM
Directory
server
or
when
there
are
fewer
than
50
objects,
add
some
temporary
Tivoli
Access
Manager
objects,
perform
a
db2
reorgchk,
and
then
delete
the
temporary
objects.
Otherwise,
perform
a
db2
reorgchk
without
adding
objects.
21
17.
Check
for
missing
DB2
indexes.
14
18.
Perform
the
DB2
statistics
performance
tuning
tasks.
27
19.
Optionally,
back
up
the
tuned
IBM
Directory
server
using
db2
backup.
37
Follow
these
steps
if
the
IBM
Directory
server
is
being
restored
from
a
db2
backup
command
(for
example,
if
you
want
to
restore
the
master
IBM
Directory
server
onto
a
replica
IBM
Directory
server):
Step
Performance
Tuning
Task
See
page
1.
Check
the
UNIX
operating
system
performance
tuning
tasks.
These
performance
tuning
tasks
vary
by
operating
system
but
they
are
mostly
related
to
system
resource
limits.
8
2.
Check
whether
the
IBM
Directory
server
change
log
is
configured.
Performance
is
faster
without
the
change
log.
11
3.
Check
whether
the
IBM
Directory
server
audit-log
is
turned
off.
Performance
is
faster
with
the
audit-log
turned
off
11
4.
If
not
already
done,
apply
the
Tivoli
Access
Manager
schema
to
the
IBM
Directory
server.
18
5.
Tune
the
IBM
Directory
server
configuration
file.
15
6.
Restart
the
IBM
Directory
server
only
if
changes
were
made
to
the
IBM
Directory
server
configuration
file.
17
7.
Verify
the
order
in
which
suffixes
are
returned
by
the
IBM
Directory
server.
17
8.
Stop
the
IBM
Directory
server.
12
9.
Perform
a
db2
restore
either
directly
or
redirected
to
spreading
the
data
across
multiple
directories.
37
10.
Check
for
missing
DB2
indexes.
14
11.
Perform
a
db2
reorgchk.
27
12.
Perform
the
DB2
statistics
performance
tuning
tasks.
27
Perform
the
performance
tuning
tasks
to
prepare
for
the
loading
of
a
large
number
of
users
Perform
these
tuning
steps
to
prepare
for
the
loading
of
a
large
number
of
users:
Step
Performance
Tuning
Task
See
page
1.
Optionally,
back
up
the
IBM
Directory
server
using
db2
backup.
It
is
always
a
good
idea
to
back
up
the
IBM
Directory
server
before
you
make
any
major
change.
In
this
case,
the
change
is
to
add
a
large
number
of
users.
37
6
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Step
Performance
Tuning
Task
See
page
2,
Optionally,
check
for
and
create
the
(AEID,DEID)
index
on
the
DB2
LDAP_DESC
table.
This
step
is
particularly
important
if
the
bulkload
utility
is
to
be
used
to
load
users.
22
3.
When
users
are
to
be
loaded
into
the
IBM
Directory
server
before
Tivoli
Access
Manager
is
configured
into
it,
create
a
minimum,
unconfigured
Tivoli
Access
Manager
object
space.
19
4.
When
users
are
to
be
loaded
into
the
IBM
Directory
server
as
members
of
one
or
more
Tivoli
Access
Manager
domains
before
those
domains
are
configured
into
Tivoli
Access
Manager,
create
a
minimum,
unconfigured
Tivoli
Access
Manager
domain
object
space
for
each
of
those
domains.
19
5.
When
Tivoli
Access
Manager
has
not
been
configured
into
the
IBM
Directory
server
or
when
there
are
fewer
than
50
objects,
add
some
temporary
Tivoli
Access
Manager
objects,
perform
a
db2
reorgchk,
and
then
delete
the
temporary
objects.
This
step
disables
the
system
statistic
performance
tuning
tasks.
Otherwise,
disable
the
system
statistic
performance
tuning
tasks
directly.
21
6.
Disable
the
DB2
statistic
performance
tuning
tasks.
23
7.
Optionally,
distribute
the
database
across
multiple
disk
drives
if
disk
space
requirements
make
it
necessary.
23
8.
Load
users,
groups,
and
any
other
LDAP
objects.
25
9.
When
the
load
is
complete,
complete
the
performance
tuning
tasks
after
a
large
number
of
updates
have
been
made.
7
Perform
the
performance
tuning
tasks
after
a
large
number
of
updates
have
been
made
Follow
these
steps
to
perform
the
performance
tuning
tasks
after
a
large
number
of
updates
have
been
made:
Step
Performance
Tuning
Task
See
page
1.
Optionally,
back
up
the
IBM
Directory
server
using
db2
backup.
It
is
always
a
good
idea
to
back
up
the
IBM
Directory
server
before
you
make
any
major
change.
In
this
case,
the
change
is
to
performance
tune
and
to
preserve
the
just-completed
load.
37
2.
Optionally,
check
for
and
create
the
(AEID,DEID)
index
on
the
DB2
LDAP_DESC
table.
22
3.
Perform
a
db2
reorgchk.
27
4.
Perform
the
DB2
statistics
performance
tuning
tasks.
27
5.
Optionally,
back
up
the
tuned
IBM
Directory
server
using
db2
backup.
37
Restore
an
IBM
Directory
server
from
a
DB2
backup
Follow
thee
steps
to
restore
an
IBM
Directory
server
from
a
db2
backup:
Step
Performance
Tuning
Task
See
page
1.
Perform
the
db2
restore
either
directly
or
redirected
to
spreading
the
data
across
multiple
directories.
37
Chapter
1.
Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager
7
Step
Performance
Tuning
Task
See
page
2.
Perform
a
db2
reorgchk.
27
3.
Perform
the
DB2
statistics
performance
tuning
tasks.
27
UNIX
operating
system
tuning
This
section
describes
changes
to
the
UNIX
operating
system
that
are
necessary
to
support
large
registries.
Resource
limits
on
UNIX
systems
(ulimit)
On
UNIX
systems,
the
ulimit
command
controls
the
limits
on
system
resource,
such
as
process
data
size,
process
virtual
memory,
and
process
file
size.
Specifically:
v
On
Solaris
systems,
by
default,
the
root
user
has
unlimited
access
to
these
resources
(for
example,
unlimited).
v
On
AIX,
some
limits
might
apply
to
the
root
user.
On
UNIX
systems,
each
user
can
either
inherit
resource
limits
from
the
root
user
or
have
specific
limits
defined.
When
setting
resource
limits
for
a
process,
it
is
important
to
know
that
the
limits
that
apply
are
those
that
are
in
effect
for
the
parent
process
and
not
the
limits
for
the
user
under
which
the
process
runs.
For
example,
the
IBM
Directory
server
runs
under
the
ldap
user
account
that
was
created
at
install
time.
However,
the
IBM
Directory
server
is
typically
started
while
logged
in
as
the
root
user.
Starting
while
logged
in
as
the
root
user
means
that
any
limits
that
are
in
effect
for
the
ldap
user
have
no
effect
on
the
IBM
Directory
server
process
unless
the
IBM
Directory
server
process
is
started
while
logged
in
as
the
ldap
user.
Solaris
operating
system
This
section
includes
the
following
topics:
v
“Increase
the
shared
memory
maximum
(shmmax)”
v
“Increase
process
memory
size
limit”
on
page
9
v
“Increase
file
size
limits”
on
page
9
Increase
the
shared
memory
maximum
(shmmax)
You
must
increase
the
shared
memory
maximum
to
allow
DB2
processes
to
allocate
the
buffer
pool
space.
In
a
later
step,
you
can
change
the
buffer
pool
settings
to
sizes
that
might
be
too
large
for
the
default
shared
memory
maximum.
It
is
recommended
that
the
shared
memory
size
be
set
to
the
size
of
the
physical
memory
on
the
machine.
For
example,
if
the
IBM
Directory
server
machine
contains
512
MB
of
physical
memory,
set
the
shared
memory
maximum
size
to
540000000.
On
Solaris
systems,
update
the
shared
memory
maximum
in
the
/etc/system
file
by
changing
the
following
line:
set
shmsys:shminfo_shmmax
=
physical_memory
where
physical_memory
is
the
size
of
the
physical
memory
on
the
system
in
bytes.
After
changing
the
shared
memory
maximum,
reboot
the
system
for
changes
to
take
effect.
8
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Examining
the
contents
of
the
/etc/system
file
is
not
a
reliable
way
to
determine
the
operating
system
setting
for
the
shared
memory
maximum.
For
that
purpose,
enter
the
following
command:
sysdef
|
grep
–i
shmmax
The
following
message
indicates
that
the
shared
memory
maximum
has
not
been
set
large
enough
for
the
DB2
cache:
SQL1478W
The
database
has
been
started
but
only
one
buffer
pool
has
been
activated.
SQLSTATE=01626
An
insufficient
size
for
the
shared
memory
maximum
can
also
prevent
DB2
from
starting.
In
this
case,
the
following
message
is
displayed:
SQL1220N
The
database
manager
shared
memory
set
cannot
be
allocated.
These
messages
also
appear
when
starting
the
IBM
Directory
server
or
running
the
following
DB2
command:
db2
connect
to
ldapdb2
Increase
process
memory
size
limit
Enter
the
following
command
to
check
the
current
process
data
size
and
virtual
memory
size
limits:
ulimit
-d
ulimit
-v
It
is
recommended
that
the
process
data
size
and
virtual
memory
size
be
set
to
unlimited.
Setting
to
unlimited
can
be
done
with
the
following
commands:
ulimit
-d
unlimited
ulimit
-v
unlimited
At
minimum,
set
these
size
limits
to
256
MB,
which
is
the
value
of
256000
on
the
ulimit
command.
Increase
these
limits
when
a
larger-than-default
IBM
Directory
server
cache
is
to
be
used.
For
more
information,
see
the
IBM
Directory
Server
documentation.
Increase
file
size
limits
Enter
the
following
command
to
check
the
current
file
size
limits:
ulimit
-f
It
is
recommended
that
the
file
size
limit
be
set
to
unlimited.
Setting
to
unlimited
can
be
done
by
entering
the
following
command:
ulimit
-f
unlimited
The
following
types
of
files
grow
with
the
size
of
the
IBM
Directory
server
and
are
a
reason
for
setting
the
file
size
option
to
unlimited.
v
DB2
table
and
index
files
v
Temporary
files
used
by
bulkload
and
as
part
of
a
bulk
load
(for
example,
the
input
LDIF
file)
AIX
operating
system
This
section
includes
the
following
topics:
v
“Increase
process
memory
size
limit”
on
page
10
v
“Increase
file
size
limits”
on
page
10
v
“Create
file
systems
with
large
file
support”
on
page
10
Chapter
1.
Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager
9
Increase
process
memory
size
limit
Enter
the
following
command
to
check
the
current
process
data
size
and
virtual
memory
size
limits:
ulimit
-d
ulimit
-m
It
is
recommended
that
the
process
data
size
and
virtual
memory
size
be
set
to
unlimited.
Setting
to
unlimited
can
be
done
by
modifying
the
following
lines
in
the
/etc/security/limits
file:
default:
data
=
-1
rss
=
-1
For
changes
to
the
/etc/security/limits
file
to
take
effect,
the
user
must
log
out
of
the
current
login
session
and
log
back
in.
At
minimum,
set
these
size
limits
to
256
MB,
which
is
the
value
of
256000
in
the
/etc/security/limits
file.
Increase
these
limits
when
a
larger-than-default
IBM
Directory
server
cache
is
to
be
used.
For
more
information,
see
the
IBM
Directory
Server
documentation.
In
addition
to
the
/etc/security/limits
file,
the
process
virtual
memory
size
is
limited
by
the
number
of
segments
that
a
process
can
use.
By
default,
a
process
can
only
use
one
memory
segment,
which
limits
a
process
to
128
MB.
AIX
support
a
large
memory
model
that
is
enabled
through
the
LDR_CNTRL
environment
variable.
See
Chapter
5,
“Tuning
process
memory
size
limits,”
on
page
63
for
more
information
on
setting
the
LDR_CNTRL
environment
variable.
Increase
file
size
limits
Enter
the
following
command
to
check
the
current
file
size
limits:
ulimit
-f
It
is
recommended
that
the
file
size
limit
be
set
to
unlimited.
Setting
to
unlimited
can
be
done
by
modifying
the
following
lines
in
the
/etc/security/limits
file:
default:
fsize
=
-1
For
changes
to
the
/etc/security/limits
file
to
take
effect,
the
user
must
log
out
of
the
current
login
session
and
log
back
in.
The
following
types
of
files
grow
with
the
size
of
the
Directory
server
and
are
a
reason
setting
the
file
size
option
to
unlimited.
v
DB2
table
and
index
files
v
Temporary
files
used
by
bulkload
and
as
part
of
a
bulk
load
(for
example,
the
input
LDIF
file)
Create
file
systems
with
large
file
support
The
standard
file
system
on
AIX
has
a
2
GB
file
size
limit,
regardless
of
the
ulimit
setting.
One
way
to
enable
files
larger
than
the
2
GB
limit
is
to
create
the
file
system
with
the
Large
File
Enabled
option.
This
option
can
be
found
through
the
Add
a
Journaled
File
System
option
of
the
smit
menu.
Refer
to
AIX
documentation
for
additional
information
and
file
system
options.
10
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
AIX
environment
variable
performance
tuning
tasks
For
AIX
environment
variable
performance
tuning
tasks
for
LDAP,
refer
to
Chapter
4,
“Tuning
the
AIX
operating
system
for
Tivoli
Access
Manager
and
LDAP,”
on
page
61.
General
IBM
Directory
performance
tuning
tasks
This
section
describes
general
IBM
Directory
tuning
tasks
that
are
applicable
to
most
uses
of
the
IBM
Directory
server.
The
information
is
relevant
to
the
initial
setup
of
an
empty
database
as
well
as
an
existing
database.
Restart
the
IBM
Directory
server
to
finish
configuration
After
the
IBM
Directory
server
has
been
configured,
it
is
necessary
to
complete
the
database
configuration
by
restarting
the
server.
Database
tables
and
indexes
are
not
defined
until
the
first
time
the
server
is
started.
To
start
the
IBM
Directory
server,
do
one
of
the
following:
v
On
UNIX
systems
with
IDS
v4.1,
enter
the
following
command:
slapd
ON
UNIX
systems
with
IDS
v5.1
or
later,
enter
the
following
command:
ibmslapd
v
On
Windows
systems,
start
the
IBM
Directory
Server
service.
Verify
the
change
log
is
not
configured
The
IBM
Directory
server
change
log
significantly
slows
down
update
performance.
The
change
log
causes
all
directory
updates
to
be
recorded
in
a
separate
change
log
DB2
database,
separate
from
the
IBM
Directory
database.
Other
applications
can
also
use
the
change
log
database
to
track
updates.
Tivoli
Access
Manager
does
not
use
change
log
functionality.
To
determine
the
change
log
configuration,
search
for
the
CN=CHANGELOG
pseudo
suffix
as
follows:
ldapsearch
-h
ldap_host
-D
cn=root
-w
ldap_password
-s
base
-b
""
"objectclass=*"
|
grep
"CN=CHANGELOG"
where
ldap_password
is
the
password
for
the
directory
administrator.
To
verify
that
the
IBM
Directory
Change
Log
option
is
not
configured,
attempt
to
unconfigure
this
option
as
follows:
ldapucfg
-g
The
following
message
appears:
The
Change
Log
is
not
currently
enabled.
Verify
that
the
IBM
Directory
server
audit
logging
is
turned
off
The
IBM
Directory
server
audit
logging
feature
significantly
slows
down
many
aspects
of
the
IBM
Directory
server
performance,
depending
upon
which
audit
logging
features
are
turned
on.
It
is
recommended
that
all
audit
logging
features
be
turned
off.
Chapter
1.
Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager
11
To
check
the
status
of
the
audit
logging
feature,
run
the
following
ldapsearch
command:
ldapsearch
–D
cn=root
–w
ldap_passwd
–s
base
–b
cn=audit,cn=localhost
"objectclass=*"
ibm-audit
where
cn=root
is
the
IBM
Directory
server
root
administrator
user,
and
ldap_passwd
is
the
IBM
Directory
server
root
administrator’s
password.
An
example
output
from
this
command
is,
as
follows:
cn=audit,cn=localhost
ibm-audit=false
where
ibm-audit=false
indicates
that
audit
logging
is
turned
off.
If
this
value
is
true,
issue
the
following
command
to
turn
it
off:
cat
<<EOF
|
ldapadd
-D
cn=root
-w
ldap_passwd
dn:
cn=audit,cn=localhost
changetype:
modify
replace:
ibm-audit
ibm-audit:
false
EOF
Stop
the
IBM
Directory
server
To
stop
the
IBM
Directory
server,
do
one
of
the
following:
v
On
UNIX
systems,
enter
the
following:
ps
–ef
|
grep
slapd
#
find
the
slapd
or
ibmslapd
process
id
kill
-9
slapd
or
ibmslapd
process
id
ps
–ef
|
grep
slapd
#
repeat
this
until
slapd
or
ibmslapd
is
gone
v
On
Windows
systems,
stop
the
IBM
Directory
Server
service.
Perform
DB2
parameter
tuning
Before
you
begin,
stop
the
IBM
Directory
server.
Switch
context
to
the
IBM
Directory
server
DB2
instance
owner,
typically
the
ldapdb2
user.
For
example:
v
On
UNIX
systems,
enter
the
following:
su
-
ldapdb2
v
On
Windows
systems,
enter
the
following:
db2cmd
set
DB2INSTANCE=ldapdb2
To
tune
DB2
parameters,
run
the
db2–tunings.sh
script.
You
can
download
the
tuning_guide_scripts.tar
file
at:
http://www3.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar.
Or,
you
can
FTP
the
files
from:
ftp://ftp.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar
This
Web
page
requires
a
registered
user
name
and
password.
The
file
system
owner
of
this
script
should
be
the
DB2
instance
owner,
typically
the
ldapdb2
user.
The
file
system
group
should
be
the
same
as
that
of
the
instance
owner
(typically
dbsysadm).
These
scripts
must
be
run
under
the
context
of
the
DB2
instance
owner.
12
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
The
ibmdefaultbp
and
ldapbp
parameters
in
this
script
control
the
size
of
DB2
buffer
pools.
The
db2_tunings.sh
script,
among
other
things,
sets
the
recommend
sizes
of
the
DB2
buffer
pools.
Some
alternative
settings
are
provided
as
comments
in
the
script.
The
performance
of
the
IBM
Directory
server
improves
as
the
DB2
buffer
pools
increases.
However,
in
most
cases,
you
can
expect
no
more
than
a
10%
improvement
from
increasing
the
buffer
pool
settings
beyond
the
values
in
the
script.
DB2
buffer
pools
are
where
DB2
caches
database
tables
and
indexes.
DB2
uses
indexes
to
quickly
identify
which
table
rows
to
retrieve
during
a
search.
For
more
information,
see
the
IBM
Directory
Server
Tuning
Guide.
Displaying
and
verifying
the
current
settings
Enter
the
following
commands
to
display
the
current
setting
of
the
DB2
tuning
parameters
of
concern:
db2
get
database
configuration
for
ldapdb2
|
\
egrep
’DBHEAP|SORTHEAP|MAXLOCKS|MINCOMMIT|UTIL_HEAP_SZ|APPLHEAPSZ’
db2
connect
to
ldapdb2
db2
"select
bpname,npages,pagesize
from
syscat.bufferpools"
db2
terminate
Functional
problems
can
occur
if
one
of
the
heap
configuration
parameters
is
too
low.
To
display
the
current
heap
parameter
settings,
enter
the
following
command:
db2
get
db
cfg
for
ldapdb2
|
grep
HEAP
The
following
is
an
example
of
output
showing
the
recommended
values
for
the
various
heap
parameters:
Database
heap
(4KB)
(DBHEAP)
=
1200
Utilities
heap
size
(4KB)
(UTIL_HEAP_SZ)
=
5000
Max
appl.
control
heap
size
(4KB)
(APP_CTL_HEAP_SZ)
=
128
Sort
list
heap
(4KB)
(SORTHEAP)
=
2500
SQL
statement
heap
(4KB)
(STMTHEAP)
=
2048
Default
application
heap
(4KB)
(APPLHEAPSZ)
=
2048
Statistics
heap
size
(4KB
)
(STAT_HEAP_SZ)
=
4384
If
a
heap
parameter
is
less
that
the
minimum,
enter
the
following
command
to
increase
it
to
the
minimum:
db2
update
db
cfg
for
ldapdb2
using
parm_name
parm_value
where
parm_name
is
the
name
on
the
third
to
last
column
of
the
above
output
(without
the
parenthesis)
and
the
parm_value
is
the
value
of
the
parameter
given
in
the
last
column.
If
the
heap
parameters
are
set
too
low
or
too
high,
the
IBM
Directory
server
fails
in
ways
that
might
not
indicate
the
cause
of
the
problem.
In
these
situations,
it
is
useful
to
view
the
cli.error
for
IBM
Directory
Server
version
4.1
(IDS
4.1)
or
the
db2cli.log
for
IBM
Tivoli
Directory
Server
version
5.2
(IDS
v5.2)
or
later
file.
On
systems
with
IDS
v4.1,
the
default
location
of
this
file
is
/var/ldap
for
Solaris
and
/tmp
for
AIX.
On
systems
with
IDS
v5.1
or
later,
the
default
location
is
/var/ldap
for
both
Solaris
and
AIX.
Note
that
the
db2look
utility
can
also
provide
considerable
information
about
the
database
and
its
configuration
in
one
command.
An
example
of
its
use
is
as
follows:
db2look
-d
ldapdb2
-u
ldapdb2
–p
–o
outpu_file
where
output_file
is
a
file
location
for
storing
the
results.
Chapter
1.
Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager
13
Warning
when
IBM
Directory
server
is
running
DB2
parameter
tuning
commands
make
use
of
db2
terminate.
If
the
IBM
Directory
server
slapd
or
ibmslapd
process
is
running
when
this
command
is
issued,
it
will
render
the
server
partially
functional.
Any
cached
searches
appear
to
respond
correctly.
Other
searches
might
simply
return
with
no
results
or
error
messages
might
appear.
The
recovery
is
to
recycle
the
IBM
Directory
server.
It
is
best
to
stop
the
IBM
Directory
server
when
changing
the
DB2
tuning
parameters.
Warnings
about
buffer
pool
memory
usage
If
any
of
the
buffer
pools
are
set
too
high,
DB2
can
fail
to
start
due
to
insufficient
memory.
If
this
occurs
there
might
be
a
core
dump
file,
but
usually
there
is
no
error
message.
On
AIX
systems,
the
system
error
log
might
report
a
memory
allocation
failure.
To
view
this
log,
enter
the
following;
errpt
–a
|
more
Restoring
a
database
that
was
backed
up
on
a
system
with
buffer
pool
sizes
that
are
too
large
for
the
target
system
might
cause
the
restoration
to
fail.
See
Chapter
6,
“Troubleshooting”
for
information
on
how
to
work
around
this
problem.
If
DB2
fails
to
start
due
to
buffer
pool
sizes
being
too
large,
redo
the
DB2
tuning
parameters.
Warning
about
MINCOMMIT
Do
not
set
the
MINCOMMIT
DB2
tuning
to
anything
other
than
1.
The
latest
version
of
the
db2_tunings.sh
script
correctly
sets
the
MINCOMMIT
parameter
to
1.
Previous
versions
of
this
script
set
the
MINCOMMIT
parameter
to
25.
A
setting
other
than
1
might
cause
timeouts
on
update
operations
and
might
slow
down
the
performance
of
these
updates.
Check
for
missing
and
extra
indexes
Run
the
check_indexes.sh
script.
To
tune
DB2
parameters,
run
one
of
the
db2_tuning
scripts
located
at:
http://www3.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar.
Or,
you
can
FTP
the
files
from:
ftp://ftp.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar
The
file
system
owner
of
this
script
should
be
the
IBM
Directory
server
instance
owner,
typically
the
ldapdb2
user.
The
file
system
group
should
be
the
same
as
that
of
the
instance
owner
(typically
dbsysadm).
The
script
must
be
run
under
the
context
of
the
DB2
instance
owner.
These
examples
assume
the
instance
owner
is
the
ldapdb2
user:
v
On
UNIX
systems,
enter
the
following:
su
–
ldapdb2
v
On
Windows
systems,
enter
the
following:
db2cmd
set
DB2INSTANCE=ldapdb2
14
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
In
rare
cases,
the
IBM
Directory
server
can
drop
one
or
more
of
its
DB2
table
indexes.
Because
DB2
table
indexes
are
critical
to
IBM
Directory
server
performance,
you
should
check
for
missing
and
extra
indexes
periodically.
The
check_indexes.sh
script
checks
for
the
existence
of
DB2
table
indexes
that
are
imported
for
IBM
Directory
server
and
Tivoli
Access
Manager
performance.
The
script
assumes
that
it
is
being
used
against
an
ldapdb2
database
in
which
Tivoli
Access
Manager
has
been
configured.
If
Tivoli
Access
Manager
has
not
been
configured
into
the
database,
the
script
reports
several
missing
indexes.
The
script
prints
out
a
suggested
DB2
create
command
for
any
missing
indexes.
The
script
also
prints
out
a
colon-separated
index
definition
when
it
finds
indexes
that
are
not
expected.
These
unexpected
indexes
could
come
from
other
products
using
LDAP.
The
second
field
of
the
colon-separated
list
of
extra
indexes
is
the
name
of
the
index.
If
the
unexpected
indexes
are
not
desired,
enter
the
following
command
to
delete
them:
db2
drop
index
index_name
db2look
is
a
useful
utility
that
also
displays
information
about
database
indexes.
For
example:
db2look
-d
ldapdb2
-u
ldapdb2
–p
–o
output_file
where
output_file
is
the
location
for
file
for
storing
the
results.
Tune
the
IBM
Directory
Server
configuration
file
Note:
On
Windows
systems,
the
\etc\slapd32.conf
or
\etc\ibmslapd.conf
file
is
not
located
at
the
root
of
the
disk
drive.
You
must
search
each
disk
to
find
it.
Change
the
slapd
size
limit
for
LDAP
searches
Edit
either
the
slapd32.conf
or
the
ibmslapd.conf
configuration
file,
and
then
change
the
ibm-slapdSizeLimit
parameter
to
a
number
other
than
0
(unlimited).
Setting
this
value
affects
all
LDAP
searches.
If
this
value
is
set
to
unlimited
(0),
the
time
to
compile
and
list
all
users
increases,
thus
affecting
system
performance.
Tune
this
parameter
so
that
a
reasonable
number
is
used
for
all
LDAP
searches.
For
example,
setting
ibm-slapdSizeLimit
parameter
affects
the
number
of
users
that
are
listed
by
using
the
Tivoli
Access
Manager
pdadmin
user
list
command.
The
final
output
from
the
pdadmin
user
list
command
is
restricted
by
the
lesser
of
these
three
values:
1.
The
ibm-slapdSizeLimit
parameter
in
the
IBM
Directory
server
slapd32.conf
or
ibmslapd.conf
configuration
file.
2.
The
pdadmin
user
list
pattern
max-return
command.
The
pattern
max-return
argument
of
2
in
the
following
example
would
list
only
2
users:
pdadmin>
user
list
*luca*
2
3.
The
max-search-size
=
{0|number}
stanza
entry
in
the
[ldap]
stanza
of
the
Tivoli
Access
Manager
ldap.conf
configuration
file,
where
0
indicates
there
is
no
limit.
Increase
the
number
of
IBM
Directory
server
connections
to
DB2
Edit
the
slapd32.conf
or
ibmslapd.conf
file
and
increase
the
ibm-slapdDbConnections
parameter
to
15for
AIX
or
30
for
all
other
operating
systems.
Chapter
1.
Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager
15
The
number
of
DB2
connections
determines
the
amount
of
processing
concurrency
between
the
IBM
Directory
server
and
DB2.
If
the
number
of
DB2
connections
is
increased
beyond
its
maximum
value,
the
IBM
Directory
server
will
revert
to
the
maximum
value.
Add
suffix
information
to
the
IBM
Directory
Server
configuration
file
If
you
have
not
already
done
so,
you
must
add
suffix-distinguished
names
(DNs)
to
the
slapd32.conf
or
ibmslapd.conf
file.
Preferably,
add
only
one
suffix
for
all
user
directory
objects.
You
must
then
add
another
suffix
for
the
Tivoli
Access
Manager
secauthority=default
object,
which
is
required
to
configure
Tivoli
Access
Manager.
Example
lines
are
as
follows:
dn:
cn=Directory,cn=RDBM
Backends,cn=IBMDirectory,cn=Schemas,cn=Configuration
ibm-slapdSuffix:
secauthority=default
ibm-slapdSuffix:
user
suffix
where
user
suffix
is
the
suffix
to
be
used
for
user
objects.
Place
these
lines
next
to
existing
ibm-slapdSuffix
lines
in
the
file
and
order
them
as
indicated
in
“Order
the
suffixes
in
the
IBM
Directory
Server
configuration
file.”
Note
that
it
is
recommended
that
only
one
suffix
be
used
for
user
objects.
You
can
separate
the
user
namespace
within
the
suffix
by
using
multiple
directory
container
objects.
If
more
than
one
suffix
is
used,
additional
directory
searches
are
necessary
to
find
user
objects,
which
slows
down
IBM
Directory
server
performance.
For
one
or
two
additional
suffixes,
the
performance
slows
down
by
approximately
10
percent.
For
more
information
about
suffixes,
see
the
IBM
Directory
Server
documentation.
Order
the
suffixes
in
the
IBM
Directory
Server
configuration
file
After
the
set
of
suffixes
to
be
added
has
been
determined,
order
them
in
the
slapd32.conf
or
ibmslapd.conf
file
for
best
performance.
The
goal
is
to
get
the
IBM
Directory
server
to
return
suffixes
that
are
most
likely
to
contain
authenticating
users
first.
Tivoli
Access
Manager
searches
suffixes
in
the
order
in
which
the
IBM
Directory
server
returns
them.
Tivoli
Access
Manager
always
searches
the
secauthority=default
suffix
last,
regardless
of
its
order.
Access
Manager
ignores
configuration-related
suffixes,
such
as
the
following:
cn=localhost
cn=pwdpolicy
cn=ibmpolicies
Note
that
cn=ibmpolicies
is
ignored
explicitly
by
default
through
an
ignore-suffix
stanza
entry
setting
in
the
/opt/PolicyDirector/etc/ldap.conf
file.
The
configuration
file
can
be
found
at:
UNIX:
/opt/PolicyDirector/etc/ldap.conf
Windows:
pd_install_dir\etc\ldap.conf
If
there
are
any
other
suffixes
that
do
not
contain
Tivoli
Access
Manager
users
or
groups,
the
suffixes
can
be
added
as
additional
suffixes
to
be
ignored
with
the
ignore-suffix
stanza
entry.
The
following
discusses
the
order
in
which
suffixes
are
returned
from
the
IBM
Directory
Server
version
4.1
versus
version
5.1
or
later,
and
also
discusses
how
the
version
relates
to
their
order
in
the
configuration
file.
v
For
IDS
4.x,
suffixes
are
returned
in
the
reverse
order
as
they
appear
in
the
configuration
file.
16
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
v
For
IDS
5.x,
suffixes
are
returned
in
the
same
order
as
they
appear
in
the
configuration
file.
Typically,
users
are
not
stored
in
the
Tivoli
Access
Manager
secauthority=default
suffix.
In
this
case,
list
the
secauthority=default
suffix
first.
Recycle
the
IBM
Directory
server
To
recycle
the
IBM
Directory
server
to
make
it
aware
of
any
changes,
do
one
of
the
following:
v
For
IBM
Directory
Server
version
4.1:
–
slapd.errors
–
cli.error
v
On
UNIX
systems,
enter
the
following.
For
example,
if
using
the
slapd
process
for
IBM
Directory
Server
version
4.1,
enter:
ps
–ef
|
grep
slapd
#
find
the
slapd
process
id
kill
-9
slapd
process
id
slapd
v
On
UNIX
systems,
enter
the
following.
For
example,
if
using
the
ibmslapd
process
for
IBM
Directory
Server
version
5.1
or
5.2,
enter:
ps
–ef
|
grep
ibmslapd
#
find
the
ibmslapd
process
id
kill
-9
ibmslapd
process
id
ibmslapd
v
On
Windows
systems,
stop
and
start
the
IBM
Directory
Server
service.
Verify
suffix
order
To
verify
that
the
suffixes
are
ordered
for
performance,
enter
the
following
on
one
line:
ldapsearch
-h
ldap_host
-D
cn=root
-w
ldap_passwd
-s
base
-b
""
"objectclass=*"
|
grep
namingcontexts
where
cn=root
is
the
IBM
Directory
server
root
administrator
user,
ldap_host
is
the
host
name
of
the
IBM
Directory
server,
and
ldap_passwd
is
the
IBM
Directory
server
root
administrator’s
password.
The
following
suffixes
are
ignored
by
Tivoli
Access
Manager
either
implicitly
or
using
the
ignore-suffix
stanza
entry
in
the
/opt/PolicyDirector/etc/ldap.conf
file:
cn=localhost
cn=pwdpolicy
cn=ibmpolicies
The
configuration
file
can
be
found
at:
UNIX:
/opt/PolicyDirector/etc/ldap.conf
Windows:
pd_install_dir\etc\ldap.conf
Create
the
suffix
objects
Note:
If
the
directory
is
to
be
restored
from
a
backup,
skip
this
section.
A
replica
server
is
typically
loaded
from
a
backup
copy
of
the
master
IBM
Directory
server.
Use
the
IBM
Directory
db2ldif
and
ldif2db
utilities
or
db2
backup
and
db2
restore
utilities
for
these
purposes.
Chapter
1.
Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager
17
If
you
have
not
already
done
so,
create
the
IBM
Directory
objects
for
all
suffixes,
except
the
Tivoli
Access
Manager
secauthority=default
suffix.
The
following
example
creates
a
suffix
object
named
o=ibm.com
using
the
IBM
Directory
ldapadd
command
and
an
LDAP
Information
File
(LDIF)-encoded
definition
of
that
suffix
object:
cat
<<EOF
|
ldapadd
-h
ldap_host
-D
cn=root
-w
ldap_passwd
dn:
o=ibm.com
objectClass:
organization
objectclass:
top
o:
ibm.com
EOF
where
cn=root
is
the
IBM
Directory
server
root
administrator
user,
ldap_host
is
the
host
name
of
the
IBM
Directory
server,
and
ldap_passwd
is
the
IBM
Directory
server
root
administrator’s
password.
Note
that
this
example
does
not
assign
any
access
control
lists
(ACLs)
to
the
suffix
object.
You
can
assign
any
ACL;
however,
keep
in
mind
that
Tivoli
Access
Manager
adds
its
own
ACLs
to
these
objects
and
enables
ACL
propagation.
Tivoli
Access
Manager
makes
these
ACL
changes
to
allow
its
servers
to
access
all
objects
in
the
directory
tree.
If
an
ACL
design
is
chosen
that
conflicts
with
Tivoli
Access
Manager’s
ACL
model,
Tivoli
Access
Manager
cannot
operate
on
the
affected
user
objects.
Preparing
to
load
users
before
configuring
Tivoli
Access
Manager
The
following
section
describes
how
to
set
up
the
IBM
Directory
server
with
Tivoli
Access
Manager
users
before
configuring
Tivoli
Access
Manager.
Sometimes
it
is
convenient
to
set
up
an
IBM
Directory
server
with
many
users
before
configuring
Tivoli
Access
Manager.
Note:
If
Tivoli
Access
Manager
is
already
configured
into
the
directory,
you
can
skip
this
section.
Add
the
Tivoli
Access
Manager
schema
to
the
IBM
Directory
server
To
add
Tivoli
Access
Manager
objects
to
the
IBM
Directory
server,
the
Tivoli
Access
Manager
schema
must
be
added
to
the
IBM
Directory
server.
Enter
the
following
ldapadd
command
to
accomplish
this
task:
ldapadd
-h
ldap_host
-D
cn=root
-w
ldap_passwd
-f
secschema.def
where
cn=root
is
the
IBM
Directory
server
root
administrator
user,
ldap_host
is
the
host
name
of
the
IBM
Directory
server,
and
ldap_passwd
is
the
IBM
Directory
server
root
administrator’s
password.
The
secschema.def
file
can
be
found
either
in
the
/opt/PolicyDirector/etc
directory
on
a
system
with
the
Tivoli
Access
Manager
installed
or
with
the
scripts
located
at:
http://www3.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar.
Or,
you
can
FTP
the
files
from:
ftp://ftp.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar
18
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
If
a
previous
version
of
the
Tivoli
Access
Manager
schema
has
already
been
added
to
the
IBM
Directory
server,
a
different
schema
definition
file
should
be
used
to
upgrade
the
schema,
instead
of
adding
it.
For
more
information,
see
the
IBM
Tivoli
Access
Manager
Base
Installation
Guide.
Create
a
minimum,
unconfigured
Tivoli
Access
Manager
directory
object
space
Note:
If
the
directory
is
to
be
restored
from
a
backup
version,
skip
this
section.
Replica
servers
are
typically
set
up
this
way.
If
Tivoli
Access
Manager
has
never
been
configured
into
the
IBM
Directory
server,
create
the
directory
objects
for
a
minimum,
unconfigured
Tivoli
Access
Manager
registry.
These
objects
include
container
objects
needed
to
hold
users
and
groups.
Configuring
the
Tivoli
Access
Manager
policy
server
into
the
IBM
Directory
server
is
the
standard
way
of
providing
these
objects.
It
is
often
convenient
not
to
configure
Tivoli
Access
Manager
in
order
to
complete
the
setup
of
an
IBM
Directory
server.
For
this
reason,
the
following
information
is
provided.
To
add
the
Tivoli
Access
Manager
objects
to
the
IBM
Directory
server,
enter
the
following
command:
ldapadd
-h
ldap_host
-D
cn=root
-w
ldap_passwd
-f
am_min_unconfig.ldif
where
cn=root
is
the
IBM
Directory
server
root
administrator
user,
ldap_host
is
the
host
name
of
the
IBM
Directory
server,
ldap_passwd
is
the
IBM
Directory
server
root
administrator’s
password,
and
where
am_min_unconfig.ldif
is
the
name
of
the
file
containing
the
LDAP
Information
File
(LDIF)
input
for
defining
the
Tivoli
Access
Manager
objects.
You
can
download
the
file
at:
http://www3.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar.
Or,
you
can
FTP
the
files
from:
ftp://ftp.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar
Create
a
minimum,
unconfigured
Tivoli
Access
Manager
subdomain
object
space
Create
a
minimum,
unconfigured
Tivoli
Access
Manager
subdomain
if
users
are
to
be
loaded
into
a
subdomain
before
Access
Manager
is
configured
into
the
Directory
server.
Refer
to
the
IBM
Tivoli
Access
Manager
Base
Administration
Guide
for
more
information
on
Tivoli
Access
Manager
subdomains.
To
create
the
subdomain
object
space,
run
the
following
tuning
guide
script
piped
to
the
ldapadd
command:
mk_am_min_unconfig_dom_ldif.sh
dom
|
ldapadd
ldap_cred
where
dom
is
name
of
the
subdomain
and
ldap_cred
is
the
LDAP
credential,
for
example:
-D
cn=root
-w
myldappaswd
Chapter
1.
Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager
19
Check
and
add
Tivoli
Access
Manager
ACLs
to
all
suffix
objects
Note:
Skip
this
section
if
the
IBM
Directory
server
is
to
be
restored
from
a
backup
or
Tivoli
Access
Manager
is
to
be
configured
into
the
IBM
Directory
server
before
users
are
added.
A
replica
server
is
typically
restored
from
a
backup.
Perform
this
step
if
you
added
new
suffixes
and
Tivoli
Access
Manager
is
already
configured
into
the
IBM
Directory
server,
or
if
you
are
unsure
whether
this
is
the
case.
To
check
or
add
Tivoli
Access
Manager
ACLs
on
all
suffix
objects,
you
can
use
the
check_ldap_acls.sh
script
located
at:
http://www3.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar.
Or,
you
can
FTP
the
files
from:
ftp://ftp.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar
Run
this
script
under
the
context
of
any
user.
The
file
system
owner
and
the
group
must
enable
the
user
permission
to
run
the
file.
To
use
this
script
to
check
ACLs,
run
it
as
follows:
check_ldap_acls.sh
ldap_host
ldap_passwd
where
ldap_host
is
the
host
name
of
the
IBM
Directory
server,
and
ldap_passwd
is
the
IBM
Directory
server
root
administrator’s
password.
To
use
this
script
to
add
the
missing
ACLs
reported
on
the
check,
enter
on
one
line
the
following:
check_ldap_acls.sh
ldap_host
ldap_passwd
|
ldapadd
-h
ldap_host
-D
cn=root
-w
ldap_passwd
where
cn=root
is
typically
the
IBM
Directory
server
root
administrator
user.
This
script
duplicates
the
changes
that
Tivoli
Access
Manager
makes
to
the
ACLs
on
suffix
objects
when
it
configures
into
an
IBM
Directory
server.
To
prevent
timeouts
at
Tivoli
Access
Manager
configuration
time,
it
is
important
to
add
these
ACLs
before
bulk
loading
a
large
number
of
users.
Do
this
by
either
running
this
script
or
by
configuring
Tivoli
Access
Manager
into
the
IBM
Directory
server
before
performing
the
bulkload.
The
script
modifies
all
suffix
objects
to
enable
ACL
propagation
and
allows
Tivoli
Access
Manager
servers
to
access
all
objects
in
the
directory
tree.
An
example
of
a
hypothetical
suffix
object
after
being
modified
is
as
follows:
dn:
o=ibm.com
objectClass:
organization
objectclass:
top
o:
ibm.com
aclpropagate:
TRUE
aclentry:
group:CN=IVACLD-SERVERS,
CN=SECURITYGROUPS,SECAUTHORITY=DEFAULT:
normal:rsc
aclentry:
group:CN=REMOTE-ACL-USERS,
CN=SECURITYGROUPS,SECAUTHORITY=DEFAULT:
normal:rsc
20
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
aclentry:
group:
CN=SECURITYGROUP,SECAUTHORITY=DEFAULT:
object:ad:normal:rwsc:sensitive:rwsc:critical:rwsc
Perform
a
DB2
reorgchk
If
fewer
than
50
objects
exist
in
the
IBM
Directory
server,
add
some
temporary
objects
before
doing
the
reorgchk,
as
follows:
ldapadd
ldap_cred
-f
am_tuning.ldif
where
ldap_cred
is
the
LDAP
credential,
for
example:
-D
cn=root
-w
myldappasswd
To
run
the
reorgchk
command,
do
one
of
the
following:
v
On
UNIX
systems,
enter
the
following:
su
–
ldapdb2
db2
connect
to
ldapdb2
db2
reorgchk
update
statistics
on
table
all
db2
terminate
v
On
Windows
systems,
enter
the
following:
db2cmd
set
DB2INSTANCE=ldapdb2
db2
reorgchk
update
statistics
on
table
all
db2
terminate
If
temporary
objects
were
added
before
the
reorgchk,
delete
them
by
using
the
following
command:
ldapdelete
ldap_cred
-f
am_tuning.delete
To
add
some
temporary
objects
or
delete
temporary
objects
that
were
added,
you
can
find
the
am_tuning.ldif
and
am_tuning.delete
files
with
the
tuning
guide
scripts
located
at:
http://www3.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar.
Or,
you
can
FTP
the
files
from:
ftp://ftp.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar
Preparing
to
expand
to
a
large
registry
This
section
explains
how
to
prepare
an
existing
registry
to
load
many
users.
Before
you
begin,
ensure
that
you
have
tuned
the
registry
as
instructed
in
“UNIX
operating
system
tuning”
on
page
8
and
“General
IBM
Directory
performance
tuning
tasks”
on
page
11.
Note:
Skip
this
section
if
the
registry
is
not
to
be
expanded.
Stop
the
IBM
Directory
server
To
stop
the
IBM
Directory
server,
do
one
of
the
following:
v
On
UNIX
systems,
enter
the
following:
ps
–ef
|
grep
slapd
#
find
the
slapd
or
ibmslapd
process
id
kill
-9
slapd
or
ibmslapd
process
id
ps
–ef
|
grep
slapd
#
repeat
this
until
slapd
or
ibmslapd
is
gone
Chapter
1.
Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager
21
v
On
Windows
systems,
stop
and
start
the
IBM
Directory
Server
service.
Force
all
DB2
connections
to
be
closed
On
UNIX
systems,
switch
to
the
DB2
instance
owner,
typically
the
ldapdb2
user.
Then,
enter
the
following:
su
-
ldapdb2
db2
force
applications
all
Back
up
the
database
Note:
If
you
are
configuring
a
replica
server
from
a
backup
of
the
master
server,
skip
this
section.
Follow
these
steps
to
back
up
the
database:
1.
Assuming
ldapdb2
is
the
DB2
instance
owner,
run
the
db2
backup
command,
as
follows:
su
-
ldapdb2
db2
backup
db
ldapdb2
to
[file
system
|
tape
device]
2.
When
the
database
has
been
backed
up
successfully,
a
message
similar
to
the
following
is
displayed:
Backup
successful.
The
timestamp
for
this
backup
image
is
:
2000042020405
Note:
Ensure
that
the
backup
is
successful
before
proceeding.
The
next
step
destroys
the
existing
database
in
order
to
recreate
it.
If
the
backup
was
not
successful,
the
existing
database
is
lost.
It
is
recommended
that
you
verify
the
success
of
the
backup
by
restoring
to
a
separate
system.
Create
the
(AEID,DEID)
index
on
the
DB2
LDAP_DESC
table
Creation
of
the
LDAP_DESC
table
(AEID,DEID)
index
is
one
performing
tuning
task
that
improves
the
performance
of
bulkload,
small
subtree
searches,
propagation
of
ACLs
created
at
the
branch
of
a
large
subtree,
and
the
fixacls_propagate_parents_once.sh
tuning
guide
script
described
in
“Add
Tivoli
Access
Manager
ACLs
not
created
by
the
bulkload
utility”
on
page
25.
This
index
could
result
in
performance
problems
for
some
searches,
but
it
is
recommended
during
a
bulkload
and
running
of
the
fixacls_propagate_parents_once.sh
script.
If
problems
are
found
during
a
normal
IBM
Directory
server
operation,
drop
this
index
as
one
course
of
problem
determination.
Note
that
if
the
IBM
Directory
server
has
many
objects,
the
creation
of
this
index
can
take
a
long
time.
One
measurement
is
35
minutes
to
create
the
index
on
an
IBM
Directory
server
with
3
million
users
(12
million
LDAP
objects).
For
UNIX
systems,
create
the
index
by
using
the
following
command,
assuming
ldapdb2
is
the
DB2
instance
owner
for
the
IBM
Directory
database:
cat
<<EOF
|
su
–
ldapdb2
-c
sh
db2
connect
to
ldapdb2
db2
"create
index
LDAP_DESC_DEID
on
LDAP_DESC(AEID,DEID)"
db2
terminate
EOF
For
Windows
systems,
use
the
following
commands:
22
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
db2cmd
set
DB2INSTANCE=ldapdb2
db2
connect
to
ldapdb2
db2
"create
index
LDAP_DESC_DEID
on
LDAP_DESC(AEID,DEID)"
db2
terminate
If
performance
problems
are
found
during
normal
IBM
Directory
server
operations,
drop
this
index
by
replacing
the
create
command
in
the
above
example
with
the
following
drop
command:
db2
"drop
index
LDAP_DESC_DEID"
Disable
the
DB2
statistic
performance
tuning
tasks
The
DB2
statistic
performance
tuning
tasks
described
in
“Perform
DB2
statistics
performance
tuning
tasks”
on
page
27
slow
down
certain
load
type
operations,
particularly
the
running
of
the
bulkload
utility
and
the
propagation
of
LDAP
ACLs.
If
users
are
being
added
to
an
already
tuned
IBM
Directory
server,
the
DB2
statistics
performance
tuning
tasks
are
likely
to
be
enabled.
Disable
them
using
the
following
command,
which
assumes
ldapdb2
is
the
DB2
instance
owner:
For
UNIX
systems:
su
-
ldapdb2
-c
$PWD/sysstat_tune.sh
disable
For
Windows
systems:
db2cmd
set
DB2INSTANCE=ldapdb2
sysstat_tune.sh
disable
In
an
earlier
step,
the
IBM
Directory
server
was
stopped.
For
IBM
Directory
Server
Version
5.1
and
later,
it
is
important
that
the
IBM
Directory
Server
remain
stopped
when
disabling
the
DB2
statistics
performance
tuning
tasks.
The
reason
is
the
IBM
Directory
server,
while
started,
periodically
re-enables
one
of
the
performance
tuning
tasks
that
is
disabled
during
this
task.
When
it
becomes
necessary
to
restart
the
IBM
Directory
server
during
the
bulk
load
of
users
and
groups,
it
is
recommended
that
the
IBM
Directory
server
be
started
in
the
following
way
to
prevent
it
from
re-enabling
the
DB2
statistic
performance
tasks.
Otherwise,
the
performance
of
the
bulk
load
suffers.
For
UNIX
systems:
LDAP_MAXCARD=NO
ibmslapd
For
Windows
systems:
Add
ibm-slapdSetenv:LDAP_MAXCARD=NO
to
the
"dn:
cn=Front
End,cn=Configuration"
stanza
entry
of
the
ibmsladp.conf
configuration
file.
Then,
start
the
IBM
Directory
Server
service.
It
is
not
recommended
that
the
IBM
Directory
server
normally
run
with
LDAP_MAXCARD=NO
environment
variable.
Doing
so
might
disable
performance
tuning
tasks
that
improve
performance.
LDAP_MAXCARD=NO
should
only
be
used
when
bulk
loading
users
and
groups.
Distribute
the
database
across
multiple
disk
drives
Assuming
that
the
database
does
not
fit
on
a
single
disk,
you
can
perform
a
redirected
restore
to
distribute
it
among
multiple
disks.
Chapter
1.
Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager
23
The
information
in
this
section
is
a
summary
of
“Distributing
the
database
across
multiple
physical
disks”
on
page
33.
If
the
information
in
this
section
is
not
sufficiently
detailed
to
perform
the
steps,
refer
to
the
more
detailed
section.
To
begin,
create
clean
directories
on
the
disks
that
you
want
to
use.
Create
two
directories
on
each
disk;
one
for
the
user
tablespace
(2)
and
the
other
for
the
LDAP
tablespace
(3).
Do
not
use
the
root
of
a
file
system,
such
as
one
with
the
lost+found
file.
Also
ensure
that
the
DB2
instance
owner,
typically
the
ldapdb2
user,
can
write
to
the
directories.
Before
you
begin,
switch
context
to
the
DB2
instance
owner.
These
examples
assume
that
the
DB2
instance
owner
is
ldapdb2:
v
On
UNIX
systems,
enter
the
following:
su
-
ldapdb2
v
On
Windows
systems,
enter
the
following:
db2cmd
set
DB2INSTANCE=ldapdb2
To
start
the
restore,
enter
a
command
similar
to
the
following:
db2
restore
db
ldapdb2
from
[location
of
backup]
replace
existing
redirect
This
command
prepares
for
the
restore
but
does
not
actually
perform
the
restore.
The
command
returns
with
a
message
indicating
that
the
restore
was
complete
but
waits
for
the
next
step.
The
next
step
is
to
define
the
DB2
tablespace
containers.
The
DB2
commands
to
define
the
tablespace
containers
can
become
very
long.
To
make
running
long
commands
easier,
you
can
add
the
long
DB2
commands
to
a
file
and
then
run
the
commands
from
that
file.
When
running
the
commands
from
a
file,
make
sure
that
the
file
is
run
by
using
the
dot
UNIX
shell
syntax.
For
example,
assume
the
commands
are
placed
in
a
file
named
set_tablespaces.
The
commands
must
be
run
by
using
the
following
syntax:
.
set_tablespaces
The
commands
will
fail
if
the
syntax
is
not
followed.
Enter
commands
similar
to
the
following:
db2
"set
tablespace
containers
for
2
using
\
(path
’/dir1-2’,
path
’/dir2-2’,
...,
\
path
’/dirn-2’)"
db2
"set
tablespace
containers
for
3
using
\
(path
’/dir1-3’
path
’/dir2-3’,...,
\
path
’/dirn-3’)"
where
dir1-2
through
dirn-2
and
dir1-3
through
dirn-3
are
directories
defined
to
contain
the
tablespace
data.
To
continue
the
restore
after
the
tablespaces
are
defined,
enter
the
following:
db2
restore
db
ldapdb2
continue
Note:
If
the
database
was
restored
from
a
backup,
as
in
the
case
of
setting
up
a
replica
server,
skip
“Adding
users
and
groups”
on
page
25
and
go
to
“Tuning
after
a
large
number
of
updates”
on
page
26.
24
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Adding
users
and
groups
Note:
If
setting
up
a
replica
server
or
tuning
an
existing
server,
skip
this
section.
This
section
explains
how
to
add
users
and
groups
to
an
already-tuned
IBM
Directory
server.
Load
users
or
groups
Use
the
bulkload
utility
to
load
a
large
number
of
users
(more
than
10,000).
For
more
information,
see
“LDAP
bulkload
utility”
on
page
39.
To
add
a
large
number
of
members
to
a
group,
use
bulkload
if
the
group
does
not
already
exist.
If
the
group
already
exists,
use
the
group-add
scripts
described
in
“Adding
a
large
number
of
members
to
a
group”
on
page
43.
To
load
fewer
than
10,000
users,
use
the
Tivoli
Access
Manager
pdadmin
command
line
interface
or
the
IBM
Directory
ldapadd
or
ldif2db
utilities.
Add
Tivoli
Access
Manager
ACLs
not
created
by
the
bulkload
utility
To
fix
up
the
ACLs
on
LDAP
objects
after
running
the
bulkload
utility
with
ACL
processing
turned
off,
use
the
fixacls_propagate_parents_once.sh
script.
The
following
example
assumes
that
ldapdb2
is
the
DB2
instance
owner
for
the
IBM
Directory
database:
su
-
ldapdb2
-c
$PWD/fixacls_propagate_parents_once.sh
For
Windows
systems
with
an
appropriate
UNIX-like
shell
environment,
enter
the
following:
db2cmd
set
DB2INSTANCE=ldapdb2
fixacls_propagate_parents_once.sh
You
can
find
the
fixacls_propagate_parents_once.sh
script
at
the
following
location:
http://www3.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar.
Or,
you
can
FTP
the
files
from:
ftp://ftp.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar
The
fixacls_propagate_parents_once.sh
script
should
be
run
after
the
IBM
Directory
server
bulkload
utility
has
been
run
to
create
Tivoli
Access
Manager
users.
Because
creating
ACLs
with
the
bulkload
utility
is
a
very
slow
process,
you
should
run
bulkload
with
ACL
support
disabled.
The
fixacls_propagate_parents_once.sh
script
adds
the
missing
ACLs
that
are
not
created
by
the
bulkload
utility.
Note:
Skip
this
step
if
some
utility
other
than
bulkload
is
used
to
create
the
users
in
the
directory
or
if
ACLs
are
not
necessary,
such
as
in
the
case
where
the
IBM
Directory
server
is
to
be
accessed
only
by
the
IBM
Directory
server
administrator.
After
ACLs
have
been
fixed
up
by
using
the
fixacls_propagate_parents_once.sh
script,
future
migrations
that
include
the
db2ldif
utility
of
the
IBM
Directory
server
Chapter
1.
Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager
25
must
include
the
rerunning
of
this
script.
The
reason
for
this
is
in
the
way
the
ACLs
are
fixed
up
by
IBM
Directory
server
for
Tivoli
Access
Manager
user
objects.
Instead
of
creating
an
ACL
on
every
Tivoli
Access
Manager
user
object
as
is
done
by
pdadmin
user
create,
this
script
sets
the
LDAP
ACL
source
of
Tivoli
Access
Manager
user
objects
to
inherit
from
the
appropriate
secAuthority=Default
domain
or
secAuthority=subdomain
object.
Because
the
Tivoli
Access
Manager
user
objects
inherit,
instead
of
own
their
own
ACLs,
the
db2ldif
utility
assumes
the
ACL
is
inherited
from
a
parent
in
the
same
subtree
and
fails
to
dump
any
ACL
information
for
these
objects.
In
fact,
the
inheritance
is
across
LDAP
subtrees,
which
is
one
reason
that
a
migration
using
the
db2ldif
utility
requires
rerunning
of
the
script.
Another
reason
is
that
the
migration
will
likely
include
another
bulkload
with
ACL
processing
turned
off.
Note
that
this
script
makes
its
update
in
few
commands,
which
update
many
DB2
table
entries.
This
script
makes
heavy
use
of
DB2
transaction
logs.
Be
sure
to
tune
the
transaction
log
parameters
as
indicated
in
the
db2_tunings.sh
tuning
guide
script
and
provide
enough
disk
space
in
the
DB2
instance
owner’s
home
directory
for
the
successful
completion
of
this
script.
For
example,
running
this
script
against
3
million
Tivoli
Access
Manager
users
requires
about
1.2
GB
of
transaction
log
space.
The
fixacls_propagate_parents_once.sh
script
finds
all
of
the
bulk
loaded
objects
that
were
loaded
with
ACL
processing
turned
off.
These
objects
are
identified
in
the
DB2
source
table
with
aclsrc
entries
of
–1.
The
script
then
determines
the
set
of
distinct
parents
of
these
objects.
For
each
parent,
it
issues
a
db2
update
command
to
propagate
the
appropriate
ACL
and
owner
to
all
of
its
child
objects.
To
complete
fix
up,
for
each
of
the
parents
it
updates
and
Tivoli
Access
Manager
child
objects
to
inherit
their
ACL
from
the
appropriate
secAuthority
domain.
Only
child
objects
that
have
been
bulk
loaded
and
not
yet
fixed
up
are
updated.
For
optimum
results
Complete
the
tasks
in
“Tuning
after
a
large
number
of
updates.”
Perform
a
DB2
Backup
Run
the
db2
backup
utility
of
choice.
For
example,
enter
the
following
commands:
su
–
ldapdb2
db2
backup
db
ldapdb2
to
[file
system
|
tape
device]
Alternatively,
you
can
use
the
IBM
db2ldif
utility.
Tuning
after
a
large
number
of
updates
After
a
large
number
of
updates,
such
as
following
updates
using
the
bulkload
utility,
you
should
perform
the
performance
tuning
tasks
discussed
in
this
section.
You
should
also
perform
these
performance
tuning
tasks
if
they
were
never
done
previously.
Redo
the
DB2
tuning
parameters
To
tune
DB2
tuning
parameters,
see
“Perform
DB2
parameter
tuning”
on
page
12.
It
is
a
good
idea
to
check
the
DB2
tuning
parameters.
The
DB2
tuning
parameters
26
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
can
change
as
a
result
of
the
bulk
load
process
or
the
db2
restore
command.
DB2
tuning
parameters
are
restored
to
their
backed-up
values
when
you
run
the
db2
restore.
Recheck
for
missing
and
extra
indexes
To
check
for
missing
and
extra
indexes,
run
the
check_indexes.sh
script.
For
more
information,
see
“Check
for
missing
and
extra
indexes”
on
page
14.
Note
that
the
file
system
owner
of
this
script
should
be
the
DB2
instance
owner,
typically
the
ldapdb2
user.
The
file
system
group
should
be
the
same
as
that
of
the
instance
owner
(typically
dbsysadm).
The
script
must
be
run
under
the
context
of
the
DB2
instance
owner.
Perform
a
DB2
reorgchk
The
db2
reorgchk
command
is
one
of
the
most
important
and
often
overlooked
DB2
tuning
commands.
The
db2
reorgchk
command
is
overlooked
because
it
is
not
a
one-time
tuning
item.
As
updates
are
performed
on
the
DB2
database,
the
statistical
information
about
the
tables
will
not
be
up
to
date.
The
db2
reorgchk
command
updates
the
important
statistics
that
are
used
by
the
DB2
optimizer.
It
is
recommended
that
the
db2
reorgchk
command
be
repeated
after
approximately
every
10,000
updates.
Before
running
the
db2
reorgchk
command,
you
should
stop
the
IBM
Directory
server
to
prevent
any
DB2
queries
or
updates
from
occurring
while
the
command
is
in
progress.
Although
this
is
optional,
database
queries
and
updates
can
be
very
slow
and
may
time
out.
To
run
the
db2
reorgchk
command,
do
one
of
the
following.
These
examples
assume
that
ldapdb2
is
the
DB2
instance
owner:
v
On
UNIX
systems,
enter
the
following:
su
–
ldapdb2
db2
connect
to
ldapdb2
db2
reorgchk
update
statistics
on
table
all
db2
terminate
v
On
Windows
systems,
enter
the
following:
db2cmd
set
DB2INSTANCE=ldapdb2
db2
connect
to
ldapdb2
db2
reorgchk
update
statistics
on
table
all
db2
terminate
It
takes
about
20
minutes
to
do
a
db2
reorgchk
command
on
a
400
MHz
Solaris
system
with
three
million
users.
Note
that
the
performance
benefit
from
running
the
db2
reorgchk
command
is
immediate.
It
is
not
necessary
to
restart
DB2
following
a
db2
reorgchk
command.
In
addition
to
improving
performance,
the
db2
reorgchk
command
reports
statistics
on
all
of
the
tables
and
indexes
in
the
database.
The
db2
reorgchk
command
also
reports
statistics
on
the
organization
of
DB2
tables.
Perform
DB2
statistics
performance
tuning
tasks
After
any
db2
reorgchk
or
runstats
command,
run
the
sysstat_tune.sh
script.
The
follow
examples
assumes
that
ldapdb2
is
the
DB2
instance
owner.
Chapter
1.
Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager
27
For
UNIX
systems,
enter
the
following:
su
-
ldapdb2
-c
$PWD/systat_tune.sh
For
Windows
systems,
enter
the
following:
db2cmd
set
DB2INSTANCE=ldapdb2
sysstat_tune.sh
This
script
updates
certain
DB2
statistics
so
that
the
DB2
optimizer
is
efficient
during
IBM
Directory
server
searches.
These
updates
are
disabled
by
the
db2
reorgchk
or
runstats
utilities.
Because
the
updates
are
disabled,
the
script
must
be
repeated
in
the
event
those
utilities
are
run.
The
sysstat_tune.sh
script
can
be
passed
an
optional
argument
that
specifies
to
disable
the
performance
tuning
tasks
or
to
check
the
current
performance
tuning
values.
The
following
examples
shows
how
to
disable
the
performance
tuning
tasks:
For
UNIX
systems,
enter
the
following:
su
-
ldapdb2
-c
$PWD/systat_tune.sh
disable
For
Windows
systems,
enter
the
following:
db2cmd
set
DB2INSTANCE=ldapdb2
disable
sysstat_tune.sh
You
can
find
the
sysstat_tune.sh
script
at
the
following
location:
http://www3.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar.
Or,
you
can
FTP
the
files
from:
ftp://ftp.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar
Start
the
IBM
Directory
server
To
start
the
IBM
Directory
server,
do
one
of
the
following:
v
On
UNIX
systems
with
IDS
v4.1,
enter
the
following:
slapd
On
UNIX
systems
with
IDS
v5.1
or
later,
enter
the
following:
ibmslapd
v
On
Windows
systems,
start
the
IBM
Directory
Server
service.
Test
performance
of
the
registry
The
test_registry_perf.sh
performs
IBM
Directory
server
searches
similar
to
the
searches
performed
by
Tivoli
Access
Manager.
You
can
find
the
test_registry_perf.sh
script
at
the
following
location:
http://www3.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar.
Or,
you
can
FTP
the
files
from:
ftp://ftp.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar
28
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Run
the
following
script
under
the
context
of
any
user
to
verify
the
search
performance
of
the
IBM
Directory
server:
test_registry_perf.sh
ldap_host
ldap_port
ldap_admin_dn
ldap_admin_passwd
user_suffix
user_principalname
user_passwd
[domain]
where
ldap_host
is
the
host
name
of
the
IBM
Directory
server
ldap_port
is
the
port
number
of
the
IBM
Directory
server
ldap_admin_dn
is
the
DN
of
the
IBM
Director
server
root
administrator
(cn=root)
ldap_admin_passwd
is
the
IBM
Directory
server
root
administrator’s
password
user_suffix
is
a
suffix
containing
a
user
to
be
tested
user_principalname
is
the
principal
name
of
the
user
to
be
tested
user_passwd
is
the
password
of
the
user
to
be
tested
domain
is
an
optional
domain
name
This
script
should
run
quickly
(less
than
one
second)
even
with
randomly
chosen
users.
If
it
does
not
run
quickly,
review
the
performance
tuning
tasks
in
this
chapter.
The
file
system
owner
and
group
must
be
such
that
the
logged-in
user
has
the
proper
permissions
to
run
the
script.
Chapter
1.
Tuning
the
IBM
Directory
server
to
be
optimized
for
Tivoli
Access
Manager
29
30
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Chapter
2.
IBM
Directory
information
and
utilities
Use
of
IBM
Directory
with
Tivoli
Access
Manager
Figure
1.
User
Data
Figure
2.
Default
Policy
Data
©
Copyright
IBM
Corp.
2001,
2003
31
Use
of
DB2
with
LDAP
The
following
Web
site
contains
information
on
IBM
LDAP
use
of
DB2:
http://www.ibm.com/software/network/directory/library/
The
key
to
understanding
LDAP
use
of
DB2
is
the
entry
ID,
or
EID.
Every
LDAP
object
is
identified
in
DB2
by
its
EID.
The
following
lists
various
commands
for
finding
entries
and
attributes
based
on
EIDs
and
finding
EIDs
based
on
entries
and
attributes.
To
list
the
full
name
of
the
table
(src
table):
db2
list
tables
|
grep
-i
src
To
describe
the
table
(src
table):
db2
describe
table
ldapdb2.src
To
find
the
last
EID
in
LDAP:
db2
"select
max(eid)
from
ldap-entry
To
find
a
user’s
EID
if
given
DN:
db2
"select
ldap_entry.eid,dn_trunc
from
ldap_entry
where
dn_trunc
=
’CN=TESTUSER1,C=US,O=IBM’"
To
find
a
Tivoli
Access
Manager
user’s
EID
if
given
a
principalname
attribute:
db2
"select
eid
from
ldapdb2.principalname
where
principalname
=
’TESTUSER1’
To
find
the
user’s
DN
given
an
EID:
db2
"select
ldap_entry.dn_trunc
from
ldap_entry
where
eid
=
100"db2
"select
ldap_entry.eid,dn_trunc
from
ldap_entry
where
eid
=
100"
#also
displays
the
eid
The
following
lists
the
search
commands
for
the
ACL/owner
source
table:
To
display
the
ACL
source
table
for
EID
100:
db2
"select
*
from
src
where
eid
=
100"
Figure
3.
Tivoli
Access
Manager’s
use
of
IBM
LDAP
ACLs
32
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
To
display
the
ACL
source
table
for
EIDs
between
100
and
110:
db2
"select
*
from
src
where
eid
<
110
and
eid
>
100"
To
find
the
EIDs
that
do
not
have
a
default
ACL
inheritance
(ACL
source
is
–1)
from
the
first
100
entries:
db2
"select
*
from
src
where
aclsrc
=
-1
and
eid
<
100
and
eid
>
2"
To
find
EIDs
in
the
ACL
source
table
that
are
not
suffixes
and
do
not
have
a
default
ACL
inheritance
(from
the
first
60
entries):
db2
"select
eid
from
src
where
aclsrc
=
-1
and
eid
>
1
and
eid
<
60
and
eid
not
in
(select
ldap_entry.eid
from
ldap_entry
where
peid
=
-1)"
To
find
the
EIDs
in
the
ACL/owner
source
table
that
do
not
have
a
default
ACL
source
and
are
descendants
of
suffix
with
EID
3:
db2
"select
src.eid
from
src,ldap_desc,ldap_entry
where
aclsrc
=
-1
and
src.eid
>
1
and
src.eid
<
60
and
deid
=
src.eid
and
aeid=3
and
peid
!=
-1
and
ldap_entry.eid
=
src.eid"
To
find
in
the
ACL/owner
source
table
for
the
first
ten
users
who
are
descendants
of
EID
4
(secauthority=default):
db2
"select
*
from
src
where
src.eid
in
(select
deid
from
ldapdb2.ldap_desc
where
(aeid=
4
and
deid
<10
and
deid
!=
4))"
To
show
the
ancestors
of
an
EID
(from
the
descendent
table):
db2
"select
*
from
ldap_desc
where
deid
=
100"
To
find
the
EID
for
all
suffixes:
db2
"select
ldap_entry.eid
from
ldap_entry
where
peid
=
-1"db2
"select
ldap_entry.eid,dn_trunc
from
ldap_entry
where
peid
=
-1"
The
following
lists
update
commands
for
the
ACL/owner
source
table
update
commands:
To
update
the
ACL
source
table
for
EID
100:
db2
"update
src
set
aclsrc
=
3
where
eid
=
100"
To
update
the
ACL
source
table
for
all
EIDs
that
are
not
suffixes
and
do
not
have
a
default
ACL
inheritance
(from
the
first
60
entries):
db2
"update
src
set
aclsrc
=
3
where
eid
in
(select
eid
from
src
where
aclsrc
=
-1
and
eid
>
1
and
eid
<
60
and
eid
not
in
(select
ldap_entry.eid
from
ldap_entry
where
peid
=
-1))"
Distributing
the
database
across
multiple
physical
disks
As
the
database
grows,
it
becomes
necessary
and
desirable
to
distribute
the
database
across
multiple
physical
disk
drives.
You
can
achieve
better
performance
by
spreading
entries
across
multiple
disks.
In
terms
of
performance,
one
20
GB
disk
is
not
as
good
as
two
10
GB
disks.
The
following
sections
describe
how
to
configure
DB2
to
distribute
the
ldapdb2
database
across
multiple
disks.
IBM
Directory
tablespaces
When
IBM
Directory
creates
a
database
for
the
directory,
it
uses
the
db2
create
database
command
to
create
a
database
named
ldapdb2.
IBM
Directory
server
creates
this
database
with
four
System
Managed
Space
(SMS)
tablespaces.
You
can
view
the
tablespaces
by
using
the
following
DB2
commands
run
under
the
context
of
the
DB2
instance
owner,
typically
the
ldapdb2
user:
db2
connect
to
ldapdb2
db2
list
tablespaces
Chapter
2.
IBM
Directory
information
and
utilities
33
The
following
examples
show
UNIX
tablespace
output
for
IBM
Directory:
Tablespaces
for
Current
Database
Tablespace
ID
=
0
Name
=
SYSCATSPACE
Type
=
System
managed
space
Contents
=
Any
data
State
=
0x0000
Detailed
explanation:
Normal
Tablespace
ID
=
1
Name
=
TEMPSPACE1
Type
=
System
managed
space
Contents
=
Temporary
data
State
=
0x0000
Detailed
explanation:
Normal
Tablespace
ID
=
2
Name
=
USERSPACE1
Type
=
System
managed
space
Contents
=
Any
data
State
=
0x0000
Detailed
explanation:
Normal
Tablespace
ID
=
3
Name
=
LDAPSPACE1
Type
=
System
managed
space
Contents
=
Any
data
State
=
0x0000
Detailed
explanation:
Normal
IBM
Directory
is
stored
in
the
user
tablespace
(USERSPACE1)
and
in
the
IBM
Directory
tablespace
(LDAPSPACE).
By
default,
there
is
only
one
container
or
directory
for
the
user
tablespace.
To
view
the
details
about
the
user
tablespace,
enter
a
DB2
command
similar
to
the
following:
db2
list
tablespace
containers
for
2
Example
output
is
as
follows:
Tablespace
Containers
for
Tablespace
2
Container
ID
=
0
Name
=
/ldapdb2/NODE0000/SQL00001/SQLT0002.0
Type
=
Path
The
container
or
directory
that
DB2
uses
for
tablespace
2
is
/ldapdb2/SQL00001/SQLT0002.0.
It
contains
some
of
the
ldapdb2
database
tables.
Tablespace
3
contains
the
remainder
of
the
database
tables,
the
biggest
of
which
is
the
ldap_entry
table.
The
ldap_entry
table
contains
the
majority
of
the
IBM
Directory
data.
Create
file
systems
and
directories
on
the
target
disks
The
first
step
in
distributing
the
DB2
database
across
multiple
disk
drives
is
to
create
and
format
the
file
systems
and
directories
on
the
physical
disks
that
the
database
is
to
be
distributed
among.
Guidelines
are
as
follows:
34
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
v
Because
DB2
distributes
the
database
equally
across
all
directories,
it
is
a
good
idea
to
make
all
of
the
file
systems,
directories,
or
both,
the
same
size.
v
All
directories
to
be
used
for
the
DB2
database
must
be
completely
empty.
AIX
and
Solaris
systems
create
a
lost+found
directory
at
the
root
of
any
file
system.
Instead
of
deleting
the
lost+found
directory,
create
a
subdirectory
at
the
root
of
each
file
system
to
be
used
for
distributing
the
database.
For
example,
create
a
subdirectory
named
c
in
each
filesystem
where
the
DB2
database
is
to
be
stored.
v
Create
two
additional
directories
under
the
c
directory:
one
for
holding
tablespace
2
and
the
other
for
tablespace
3.
For
example,
these
directories
might
be
named
2
and
3.
Then
specify
these
directories
on
the
set
tablespace
commands
as
discussed
in
“Perform
a
redirected
restore
of
the
database.”
v
The
DB2
instance
user
must
have
Write
permission
on
the
created
directories.
For
AIX
and
Solaris
systems,
the
following
command
gives
the
proper
permissions:
chown
ldapdb2
directory_name
The
following
are
platform-specific
guidelines:
v
For
the
AIX
operating
system,
create
the
file
system
with
the
Large
File
Enabled
option.
This
option
is
one
of
the
options
on
the
Add
a
Journaled
File
System
smit
menu.
v
For
AIX
and
Solaris
systems,
set
the
file
size
limit
to
unlimited
or
to
a
size
large
enough
to
allow
for
the
creation
of
a
file
as
large
as
the
file
system.
On
AIX
systems,
the
/etc/security/limits
file
controls
system
limits
and
–1
means
unlimited.
On
Solaris
systems,
the
ulimit
command
controls
system
limits.
Backing
up
the
existing
database
To
back
up
the
existing
database,
follow
these
steps:
1.
Stop
the
IBM
Directory
server
process
(slapd
or
ibmslapd).
2.
To
close
all
DB2
connections,
enter
the
following:
db2
force
applications
all
db2
list
applications
A
message
similar
to
the
following
is
displayed:
SQL1611W
No
data
was
returned
by
Database
System
Monitor.
3.
To
initiate
the
backup
process,
enter
the
following:
db2
backup
db
ldapdb2
to
[file
system
|
tape
device]
When
the
database
has
been
backed
up
successfully,
a
message
similar
to
the
following
is
displayed:
Backup
successful.
The
timestamp
for
this
backup
image
is
:
20000420204056
Note:
Ensure
that
the
backup
process
was
successful
before
proceeding.
The
next
step
destroys
the
existing
database
in
order
to
recreate
it.
If
the
backup
was
not
successful,
the
existing
database
is
lost.
You
can
verify
the
success
of
the
backup
by
restoring
to
a
separate
system.
Perform
a
redirected
restore
of
the
database
A
DB2
redirected
restore
restores
the
specified
database
tablespace
to
multiple
containers
or
directories.
In
the
following
example,
assume
that
the
following
directories
for
containing
tablespace
2
were
created,
are
empty,
and
have
the
correct
permissions
to
allow
write
access
by
the
DB2
instance
owner,
typically
the
ldapdb2
user:
Chapter
2.
IBM
Directory
information
and
utilities
35
/disks/1/c/2
/disks/2/c/2
/disks/3/c/2
/disks/4/c/2
/disks/5/c/2
In
the
following
example,
assume
the
following
directories
for
tablespace
3
were
created:
/disks/1/c/3
/disks/2/c/3
/disks/3/c/3
/disks/4/c/3
/disks/5/c/3
Follow
these
steps
for
a
redirected
restore:
1.
To
start
the
DB2
restore
process,
enter
the
following:
db2
restore
db
ldapdb2
from
[location
of
backup]
replace
existing
redirect
Messages
similar
to
the
following
are
displayed:
SQL2539W
Warning!
Restoring
to
an
existing
database
that
is
the
same
as
the
backup
image
database.
The
database
files
will
be
deleted.
SQL1277N
Restore
has
detected
that
one
or
more
tablespace
containers
are
inAccessible,
or
has
set
their
state
to
’storage
must
be
defined’.
DB20000I
The
RESTORE
DATABASE
command
completed
successfully.
2.
To
define
the
containers
for
tablespace
2
and
for
tablespace
3,
enter
the
following:
db2
"set
tablespace
containers
for
2
using
(path
\
’/disks/1/c/2’,
path
’/disks/2/c/2’,
path
’/disks/3/c/2’,
\
path
’/disks/4/c/2’,
path
’/disks/5/c/2’)"
db2
"set
tablespace
containers
for
3
using
(path
\
’/disks/1/c/3’,
path
’/disks/2/c/3’,
path
’/disks/3/c/3’,
\
path
’/disks/4/c/3’,
path
’/disks/5/c/3’)"
Note:
If
many
containers
are
defined,
these
commands
can
become
so
long
as
to
not
fit
within
the
limits
of
a
shell
command.
In
this
case,
you
can
put
the
command
in
a
file
and
run
within
the
current
shell
using
the
dot
notation.
For
example,
assume
that
the
commands
are
in
a
file
named
set_containers.sh.
The
following
command
runs
it
in
the
current
shell:
.
set_containers.sh
After
completion
of
the
DB2
set
tablespace
command,
a
message
similar
to
the
following
is
displayed:
DB20000I
The
SET
TABLESPACE
CONTAINERS
command
completed
successfully.
If
you
receive
the
following
message:
SQL0298N
Bad
container
path.
SQLSTATE=428B2
This
indicates
that
one
of
the
containers
is
not
empty,
or
that
Write
permission
is
not
enabled
for
the
DB2
instance
owner,
typically
the
ldapdb2
user:
Note:
A
newly
created
file
system
on
AIX
and
Solaris
contains
a
directory
named
lost+found.
You
should
create
a
directory
at
the
same
level
as
lost+found
to
hold
the
tablespace
and
then
reissue
the
set
tablespace
command.
If
you
experience
problems,
see
the
DB2
documentation.
The
following
files
might
also
be
of
interest:
36
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
ldapdb2_home_dir
/sqllib/Readme/en_US/Release.Notes
ldapdb2_home_dir
/sqllib/db2dump/db2diag.log
Note
that
the
db2diag.log
file
contains
some
fairly
low-level
details
that
can
be
difficult
to
interpret.
3.
Continue
the
restore
to
new
tablespace
containers.
This
step
takes
the
most
time
to
complete.
The
time
varies
depending
on
the
size
of
the
directory.
To
continue
the
restore
to
the
new
tablespace
containers,
enter
the
following:
db2
restore
db
ldapdb2
continue
If
problems
occur
with
the
redirected
restore
and
you
want
to
restart
the
restore
process,
it
might
be
necessary
to
enter
the
following
command
first:
db2
restore
db
ldapdb2
abort
DB2
backup
and
restore
The
fastest
way
to
back
up
and
restore
the
database
is
to
use
DB2
backup
and
restore
commands.
LDAP
alternatives,
such
as
db2ldif
and
ldif2db,
are
generally
much
slower
in
comparison.
The
only
disadvantage
to
using
the
db2
backup
and
db2
restore
commands
is
that
the
backed-up
database
cannot
be
restored
across
dissimilar
hardware
platforms.
For
example,
you
cannot
back
up
an
AIX
database
and
restore
the
database
to
a
Solaris
system.
An
alternative
to
the
db2
backup
and
db2
restore
commands
is
an
LDAP
Information
File
(LDIF)
export
and
import.
These
commands
work
across
dissimilar
hardware
platforms,
but
the
process
is
slower.
For
more
information
about
the
use
of
these
commands,
see
the
DB2
documentation.
An
important
advantage
of
using
db2
backup
and
db2
restore
commands
is
the
preservation
of
DB2
configuration
parameters
and
db2
reorgchk
database
optimizations
in
the
backed-up
database.
The
restored
database
has
the
same
performance
tuning
tasks
as
the
backed-up
database.
This
is
not
the
case
with
LDAP
db2ldif
and
ldif2db.
Be
aware
that
if
you
restore
over
an
existing
database,
any
performance
tuning
tasks
on
that
existing
database
are
lost.
Check
all
DB2
configuration
parameters
after
performing
a
restore.
Also,
if
you
do
not
know
whether
a
db2
reorgchk
was
performed
before
the
database
was
backed
up,
run
db2
reorgchk
after
the
restore.
The
DB2
commands
to
perform
backup
and
restore
operations
are
as
follows:
db2
force
applications
all
db2
backup
db
ldapdb2
to
directory_or_device
db2
restore
db
ldapdb2
from
directory_or_device
replace
existing
where
directory_or_device
is
the
name
of
a
directory
or
device
where
the
backup
is
stored.
The
most
common
error
that
occurs
on
a
restore
is
a
file
permission
error.
Following
are
some
reasons
why
this
error
might
occur:
v
The
DB2
instance
owner
does
not
have
permission
to
access
the
specified
directory
and
file.
One
way
to
solve
this
is
to
change
directory
and
file
ownership
to
the
DB2
instance
owner.
For
example,
enter
the
following:
chown
ldapdb2
fil_or_dev
v
The
backed-up
database
is
distributed
across
multiple
directories,
and
those
directories
do
not
exist
on
the
target
system
of
the
restore.
Distributing
the
Chapter
2.
IBM
Directory
information
and
utilities
37
database
across
multiple
directories
is
accomplished
with
a
redirected
restore.
To
solve
this
problem,
either
create
the
same
directories
on
the
target
system
or
perform
a
redirected
restore
to
specify
the
proper
directories
on
the
new
system.
If
creating
the
same
directories,
ensure
that
the
owner
of
the
directories
is
the
DB2
instance
owner
typically
the
ldapdb2
user.
For
more
information
about
redirected
restore,
see
“Distributing
the
database
across
multiple
physical
disks”
on
page
33.
Backup
and
restore
operations
are
required
to
initially
synchronize
an
LDAP
replica
with
an
LDAP
master
or
whenever
the
master
and
replica
get
out
of
sync.
A
replica
can
get
out
of
sync
if
it
is
not
defined
to
the
master.
In
this
case,
the
master
does
not
know
about
the
replica
and
does
not
save
updates
on
a
propagation
queue
for
that
replica.
If
a
newly-configured
master
LDAP
directory
is
to
be
loaded
with
initial
data,
you
can
use
bulk-loading
utilities
to
speed
up
the
process.
This
is
another
case
in
which
the
replica
is
not
informed
of
updates
and
a
manual
backup
and
restore
is
required
to
get
the
replica
synchronized
with
the
master.
Monitoring
LDAP
performance
To
monitor
performance
for
IBM
Directory
and
Sun
ONE
Server
Directory,
enter
the
ldapsearch
command
as
follows:
ldapsearch
-h
ldap_host
-s
base
-b
cn=monitor
"objectclass=*"
where
ldap_host
is
the
name
of
the
LDAP
host.
This
command
returns
several
statistics.
An
interesting
statistic
in
terms
of
monitoring
performance
is
opsinitiated,
which
indicates
the
number
of
LDAP
operations
that
were
initiated
after
the
IBM
Directory
server
started.
The
ldapsearch
command
itself
accounts
for
three
of
these
operations.
Therefore,
for
any
given
interval,
the
throughput
for
that
interval
is
the
difference
between
opsinitiated
at
the
start
and
end
of
that
interval,
less
three
for
the
ldapsearch,
divided
by
the
length
of
the
interval.
Following
is
a
more
precise
description
of
this
calculation:
tput
=
(opsinitiated(at
stop
time)
-
opsinitiated(at
start
time)
-
3)
/
(stop_time
-
start_time)
Concurrent
updates
on
Symmetric
Multi-Processor
systems
Better
update
performance,
particularly
on
Symmetric
Multi-Processor
(SMP)
systems,
is
typically
achieved
by
making
updates
concurrently
(for
example,
with
multiple
concurrent
update
clients).
In
some
cases,
update
performance
might
not
improve
with
concurrent
updates,
specifically
when
the
LDAP
propagation
queue
grows
very
large.
This
can
happen
when
the
LDAP
master
server
does
updates
faster
than
those
updates
can
be
propagated
to
the
LDAP
replica
servers.
Because
propagation
is
done
serially,
concurrent
updates
on
the
master
are
likely
to
result
in
a
growth
of
the
propagation
queue.
Some
testing
is
required
in
a
master/replica
environment
to
determine
how
much
performance
improvement,
if
any,
comes
from
concurrent
updates.
38
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Creating
large
numbers
of
users
You
can
add
users
to
Tivoli
Access
Manager
in
a
number
of
ways.
The
suggested
method
depends
on
the
number
of
users
that
you
need
to
add.
The
following
table
is
useful
for
determining
the
preferred
method
of
adding
Tivoli
Access
Manager
users:
Table
1.
Preferred
Methods
for
Adding
Users
Number
of
Users
to
Create
Preferred
Method
Less
than
10,000
Tivoli
Access
Manager
pdadmin
command
More
than
10,000
LDAP
bulkload
utility
with
customized
Tivoli
Access
Manager
tuning
guide
scripts
As
reflected
in
Table
1,
when
small
numbers
of
users
are
to
be
added,
the
preferred
method
is
to
use
the
Tivoli
Access
Manager
pdadmin
command
line
utility.
For
pdadmin
command
syntax,
see
the
IBM
Tivoli
Access
Manager
for
e-business
Command
Reference.
During
this
process,
Tivoli
Access
Manager
adds
users
to
the
IBM
Directory
server
and
in
turn,
the
IBM
Directory
server
adds
the
user
to
the
DB2
database.
Note:
Because
the
overhead
of
Tivoli
Access
Manager
and
the
IBM
Directory
server
is
relatively
high
compared
to
DB2,
this
method
is
not
recommended
when
more
than
10,000
users
are
to
be
added.
The
alternative
is
to
bypass
Tivoli
Access
Manager
and
the
IBM
Directory
server
and
to
load
users
directly
into
the
DB2
database
using
the
bulkload
utility
supplied
with
IBM
Directory
server.
The
bulkload
utility
is
supplied
with
the
IBM
Directory
server.
Similar
tools
exist
on
other
user
registry
servers,
such
as
Microsoft
Active
Directory
and
Sun
ONE
Server
Directory.
Some
of
the
scripts
contained
in
this
section
might
be
useful
in
bulk
loading
users
on
these
alternative
directory
servers,
particularly
those
that
generate
LDIF
output.
The
IBM
Directory
server
ldapadd
and
ldif2db
utilities
are
slower
alternatives
to
the
bulkload
utility.
Before
attempting
any
of
the
following
procedures,
it
is
recommended
that
you
back
up
all
critical
Tivoli
Access
Manager
files
as
well
as
the
user
information
in
the
DB2
database
in
the
event
of
failure
or
undesired
results.
The
backup
and
restore
procedures
of
a
DB2
database
are
discussed
in
detail
in
“DB2
backup
and
restore”
on
page
37.
LDAP
bulkload
utility
The
IBM
Directory
server
comes
with
an
executable
called
bulkload,
which
provides
the
function
of
loading
information
directly
into
LDAP
from
an
LDAP
Information
File
(LDIF).
The
bulkload
utility
parses
the
LDIF,
creates
files
used
by
the
DB2
loader
program,
and
then
proceeds
to
load
the
data
directly
into
the
DB2
database,
bypassing
LDAP.
There
are
disadvantages
using
the
bulkload
utility
as
opposed
to
the
Tivoli
Access
Manager
pdadmin
command.
Before
using
the
utility
and
the
associated
scripts,
consideration
should
be
given
to
the
following:
v
The
LDAP
bulkload
utility
and
custom
bulk-loading
scripts
require
LDAP
to
be
down
during
their
operation.
Chapter
2.
IBM
Directory
information
and
utilities
39
v
The
LDAP
bulkload
utility
and
custom
bulk-loading
scripts
do
not
handle
LDAP
replication.
Replication
must
be
done
manually
by
backing
up
the
master
IBM
Directory
server
and
restoring
on
the
replica
IBM
Directory
server.
v
The
LDAP
bulkload
utility
and
the
associated
Tivoli
Access
Manager
scripts
can
be
difficult
to
use.
v
The
bulkload
utility
does
not
support
the
creation
of
a
larger
number
of
ACLs.
Use
the
fixacls_propagate_parents_once.sh
script
to
handle
the
ACLs.
For
more
information
on
the
bulkload
utility,
see
the
IBM
Directory
Installation
and
Configuration
Guide.
Disk
space
requirements
DB2,
the
bulkload
utility,
and
the
incremental_bulkload.sh
tuning
guide
script
require
a
significant
amount
of
disk
space,
some
of
this
disk
space
is
temporary.
Space
is
required
for
LDIF,
DB2
import
tables,
DB2
indexing,
and
DB2
tables.
The
following
table
shows
DB2
tablespace
requirements
for
a
bulkload
of
500,000
Tivoli
Access
Manager
users.
Note
that
the
incremental_bulkload.sh
tuning
guide
script
defaults
to
loading
Tivoli
Access
Manager
500,000
users
(2
million
LDAP
objects)
at
one
time.
Table
2.
Loading
Tivoli
Access
Manager
500,000
users
Description
Tablespace
Typical
default
location
Approx.
disk
space
reqm’ts
ID
Name
incremental_bulkload.sh
script
temporary
LDIF
file
—
—
Directory
from
which
the
script
is
run
780
MB
bulkload
utility
temporary
DB2
load
tables
—
—
Directory
from
which
the
incremental_bulkload.sh
is
run,
or
the
–L
option
if
the
bulkload
utility
is
invoked
directly
2.75
GB
DB2
temporary
indexes
and
transaction
logs
1
TEMPSPACE1
DB2
instance
owner’s
home
directory
1
GB
DB2
permanent
attribute
tables
2
USERSPACE1
DB2
instance
owner’s
home
directory,
if
not
redirected
700
MB
DB2
permanent
LDAP_ENTRY
table
3
LDAPSPACE
DB2
instance
owner’s
home
directory,
if
not
redirected
400
MB
Tablespace
1
is
typically
the
DB2
instance
owner’s
home
directory
and
is
used
for
temporary
space.
DB2
builds
indexes
in
this
temporary
space.
Using
the
guidelines
in
the
table,
tablespace
1
will
be
large
enough
to
hold
the
largest
index.
For
fewer
than
500,000
Tivoli
Access
Manager
users
(2
million
LDAP
objects),
use
the
following
per
Tivoli
Access
Manager
user
(4
LDAP
objects)
formula:
v
incremental_bulkload.sh
script
temporary
LDIF
file:
1.6
KB
per
Tivoli
Access
Manager
user
v
bulkload
utility
temporary
DB2
load
tables:
5.5
KB
per
Tivoli
Access
Manager
user
v
DB2
temporary
indexes
and
transaction
logs:
2
KB
per
Tivoli
Access
Manager
user
v
DB2
permanent
attribute
tables:
6.4
KB
per
Tivoli
Access
Manager
user
v
DB2
permanent
LDAP_ENTRy
table:
3.6
KB
per
Tivoli
Access
Manager
user
40
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Note:
These
estimates
might
vary,
depending
upon
the
number
and
size
of
the
attributes
in
the
user
definition.
For
example,
the
requirements
will
be
greater
if
the
user
object
is
defined
with
an
attribute
that
is
not
used
by
Tivoli
Access
Manager
such
as
postalAddress.
To
get
more
information
about
a
tablespace,
enter
the
following:
su
-
ldapdb2
db2
connect
to
ldapdb2
db2
list
tablespace
containers
for
ID
The
variable
ID
is
the
tablespace
ID
number.
The
resulting
output
reveals
the
path
to
the
tablespace
directory.
To
obtain
the
available
capacity
of
the
tablespace
directory
on
AIX
or
Solaris
systems,
enter
the
following:
df
-k
tablespace_directory
Enter
the
directory
or
entire
path
for
the
tablespace_directory
variable.
Bulk
loading
and
ACLs
To
create
LDAP
ACLs,
use
the
fixacls_propagate_parents_once.sh
script
described
in
“Add
Tivoli
Access
Manager
ACLs
not
created
by
the
bulkload
utility”
on
page
25.
Due
to
the
slow
performance
of
bulk
loading
with
ACLs,
do
not
use
the
bulkload
utility
to
create
LDAP
ACLs.
Using
the
Tivoli
Access
Manager
scripts
Certain
directory
attributes
and
objects
must
exist
for
a
user
to
be
defined
as
a
Tivoli
Access
Manager
user.
The
purpose
of
the
bulkload
scripts
is
to
take
an
existing
LDIF
definition
of
LDAP
users
and
add
Tivoli
Access
Manager
attributes
and
objects
for
each.
The
resulting
LDIF
is
then
passed
to
the
LDAP
bulkload
utility
for
loading
into
the
IBM
Directory
server.
This
section
describes
the
use
of
three
Tivoli
Access
Manager
bulk-loading
scripts
located
at:
http://www3.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar.
Or,
you
can
FTP
the
files
from:
ftp://ftp.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar
Consider
these
scripts
as
examples
from
which
usable
scripts
are
derived.
To
make
the
scripts
usable,
you
must
customize
them
for
the
particular
environment
in
which
they
are
to
be
used.
v
mk_test_users_ldif.sh
v
add_am_to_testusers_ldif.sh
v
incremental_bulkload.sh
These
scripts
are
designed
to
be
piped
together,
so
that
any
piece
can
easily
be
replaced.
Note
that
the
scripts
have
very
little
error
checking
and
should
be
read
thoroughly
before
being
used.
Modifications
are
required.
mk_test_users_ldif.sh
The
mk_test_users_ldif.sh
script
generates
sample
directory
users
without
any
Tivoli
Access
Manager
attributes
or
objects.
This
script
could
be
replaced
with
one
that
gets
users
from
another
IBM
Directory
server
or
from
the
same
IBM
Directory
server.
Users
could
come
from
the
same
directory.
In
that
case,
they
would
be
Chapter
2.
IBM
Directory
information
and
utilities
41
imported
to
Tivoli
Access
Manager.
Users
could
come
from
some
other
database,
such
as
a
database
containing
employees,
customers,
or
both.
The
script
could
also
be
replaced
by
a
cat
of
a
file
containing
the
LDIF
definition
of
users
obtained
in
one
of
the
previously
mentioned
ways.
You
can
use
this
script
as
a
model
of
the
minimum
information
needed
to
define
a
directory
user
or
to
generate
users
for
testing
purposes.
This
script
has
the
following
usage:
mk_test_users_ldif.sh
start_user_number
end_user_number
user_prefix_dn
password
The
output
from
this
script
is
directed
to
the
standard
output
device
and
contains
the
LDIF
definition
of
the
range
of
users
requested
on
input.
The
script
must
be
modified
to
indicate
the
LDAP
suffix
under
which
the
users
are
to
be
located
in
the
directory
tree.
add_am_to_testusers_ldif.sh
The
add_am_to_testusers_ldif.sh
script
adds
the
Tivoli
Access
Manager
attributes
and
objects
to
the
input
set
of
users.
The
input
set
of
users
is
read
from
the
standard
input
device.
The
original
user
LDIF
definition,
along
with
the
added
LDIF
attributes
and
objects,
is
output
to
the
standard
output
device.
You
can
modify
the
script
to
exclude
the
original
user
LDIF
definition,
in
which
case
it
can
be
used
to
perform
an
import
of
existing
users
to
Tivoli
Access
Manager.
Note:
This
script
has
a
dependency
on
either
the
uuidgen
or
pduuidgen
utility,
the
latter
which
is
included
with
Tivoli
Access
Manager.
You
must
modify
this
script
for
your
particular
directory
tree
structure.
You
must
also
set
the
following
variables
within
the
script:
v
sechaspolicy
v
secpwdvalid
(recommend
changing
this
to
false)
v
secpwdlastchanged
v
secacctvalid
For
more
information
about
the
use
of
pduuidgen,
see
the
IBM
Tivoli
Access
Manager
Base
Administrator’s
Guide.
This
script
might
also
need
to
be
modified
to
identify
where
the
Tivoli
Access
Manager
principalname
attribute
can
be
obtained.
As
written,
the
script
gets
the
principalname
attribute
from
the
directory
user’s
uid
attribute.
An
alternative
is
to
get
the
principalname
attribute
from
the
cn
attribute,
assuming
all
users
have
a
cn
attribute.
This
script
can
takes
two
arguments,
as
follows:
add_am_to_testusers_ldif.sh
domain
[acls]
where
domain
is
either
Default
or
a
subdomain
name,
and
acls
is
an
optional
keyword
that
causes
ACLs
to
be
generated.
incremental_bulkload.sh
This
script
invokes
the
bulkload
utility
repetitively
until
all
objects
are
loaded.
The
frequency
of
invocation
is
determined
by
an
increment
variable
within
the
script
file
that
determines
the
number
of
directory
objects
to
group
together
per
invocation.
The
loading
of
users
is
faster
as
the
number
of
directory
objects
loaded
together
in
one
invocation
increases.
42
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Note
that
the
number
of
Tivoli
Access
Manager
objects
per
user,
including
the
LDAP
user
object
is
four.
An
increment
variable
of
200000
loads
Tivoli
Access
Manager
users
in
increments
of
one-half
million.
Be
careful
about
the
2
GB
file
size
limit.
You
might
have
to
increase
file
system
and
operating
system
limits
to
accommodate
files
larger
than
2
GB.
The
bulkload
utility
itself
does
not
support
files
larger
than
2
GB.
The
default
increment
in
the
script
avoids
reaching
the
2
GB
file
size
limit.
The
script
usage
is
as
follows:
incremental_bulkload.sh
drop_indexes
|
with_indexes
The
only
command
line
parameter
is
either
drop_indexes
or
with_indexes.
The
drop_indexes
parameter
indicates
that
indexes
are
to
be
dropped
before
doing
DB2
table
loads.
In
this
case,
the
indexes
are
recreated,
either
on
the
next
invocation
of
bulkload
or
the
next
time
the
slapd
or
ibmslapd
process
is
started.
The
with_indexes
parameter
does
not
drop
indexes
before
the
load.
The
with_indexes
parameter
is
the
fastest
and
is
recommended
in
all
cases.
The
script
obtains
input
from
the
standard
input
device.
Input
is
the
LDIF
definition
of
the
objects
to
be
loaded.
You
can
replace
the
script
with
ldapadd
or
some
other
utility
that
provides
fast
loading
capabilities
on
some
other
directory
product.
The
script
writes
to
the
standard
output
device
for
progress
messages
and
timings.
The
Tivoli
Access
Manager
bulkload
scripts
should
be
run
on
the
system
on
which
the
LDAP
and
DB2
servers
are
installed.
The
scripts
are
ksh
scripts
and
should
be
run
inside
a
ksh
shell.
You
can
use
the
example
scripts
in
the
following
way
to
load
10,000
test
users:
mk_test_users_ldif.sh
1
10000
cn=testuser,o=ibm,c=us
test1pass
|
add_am_to_testusers_ldif.sh
dom1
|
incremental_bulkload.sh
with_indexes
When
running
this
script,
do
not
be
alarmed
if
it
appears
to
hang.
The
parsing
phase
of
the
bulkload
utility
is
a
lengthy
process
and
grows
linearly
with
the
size
of
the
LDIF.
The
files
are
located
at:
http://www3.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar.
Or,
you
can
FTP
the
files
from:
ftp://ftp.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar
After
completing
the
bulk-loading
process,
do
the
following:
1.
Perform
the
performance
tuning
tasks
described
in
“Tuning
after
a
large
number
of
updates”
on
page
26.
2.
If
there
are
any
replicas,
manually
synchronize
them
with
the
updated
database.
LDAP
replicas
do
not
automatically
detect
the
changes
made
by
the
bulkload
utility.
The
DB2
backup
and
restore
procedure
on
page
37
is
a
good
way
to
perform
the
manual
synchronization.
Adding
a
large
number
of
members
to
a
group
To
add
a
large
number
of
members
to
a
group,
use
the
incremental_bulkload.sh
script
if
the
group
does
not
exist
or
use
the
incremental_group.sh
script
if
it
does
exist.
By
default,
the
incremental_group.sh
script
uses
ldapadd
with
increments
of
10,000
users
at
a
time.
The
reason
for
separating
them
into
increments
is
the
Chapter
2.
IBM
Directory
information
and
utilities
43
potential
for
running
out
of
disk
space
for
the
DB2
transaction
log,
which
is
another
part
of
the
DB2
database
that
is
stored
in
tablespace
1.
The
DB2
transaction
log
is
used
to
back
out
any
changes
to
an
entry
in
the
event
that
a
failure
occurs
before
the
changes
are
complete
and
committed
to
the
database.
The
transaction
log
contains
a
record
of
the
progress
of
the
ldapadd.
If
more
than
10,000
members
are
added
at
a
time,
this
log
can
become
very
large.
If
the
file
system
for
tablespace
1
runs
out
of
space,
the
ldapmodify
fails.
You
should
perform
a
DB2
backup
before
adding
a
large
group.
Running
out
of
disk
space
can
put
the
database
in
an
unrecoverable
state.
This
section
describes
the
use
of
three
Tivoli
Access
Manager
scripts,
which
aid
in
the
adding
of
a
large
number
of
members
to
a
group.
These
scripts
are
located
at:
http://www3.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar.
Or,
you
can
FTP
the
files
from:
ftp://ftp.software.ibm.com/.../Security/AMeB/am5.1/tuning_guide_scripts.tar
Consider
these
scripts
as
samples
from
which
usable
scripts
are
derived.
To
make
the
scripts
usable,
you
must
customize
them
for
the
particular
environment
in
which
they
will
be
used.
v
mk_ldap_group_ldif_stdin.sh
v
add_am_to_groups_ldif.sh
v
incremental_group.sh
These
scripts
are
designed
to
be
piped
together,
so
that
any
piece
can
easily
be
replaced.
Note
that
these
scripts
have
very
little
error-checking
and
should
be
read
thoroughly
before
being
used.
Modifications
are
required.
mk_ldap_group_ldif_stdin.sh
The
mk_ldap_group_ldif_stdin.sh
script
creates
or
adds
members
to
a
test
group
taken
from
users
read
from
the
standard
input
device.
The
group
does
not
contain
the
Tivoli
Access
Manager
attributes
and
objects.
It
is
a
group
as
defined
by
the
IBM
Directory
server.
The
DN
of
the
group
to
be
created
is
an
argument
to
the
script.
The
groups
and
group
membership
could
come
from
some
other
source.
This
script
could
be
replaced
with
a
cat
of
a
file
containing
the
LDIF
definition
of
the
directory
group
object.
The
script
could
be
used
to
create
a
test
group
with
many
members.
The
usage
is
as
follows:
mk_ldap_group_ldif_stdin.sh
{create|add}
dn_of_group
where
the
first
option
is
either
create
or
add,
and
dn_of_group
is
the
distinguished
name
(DN)
of
the
group
to
be
created.
The
create
option
generates
the
LDIF
to
create
a
directory
group
object
without
the
Tivoli
Access
Manager
attributes
and
objects.
The
group
is
created
with
the
specified
number
of
members.
The
add
option
adds
the
specified
members
to
an
already
existing
group.
44
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
The
script
directs
the
LDIF
output
of
the
group
definition
to
the
standard
output
device.
add_am_to_groups_ldif.sh
The
add_am_to_groups_ldif.sh
script
adds
the
Tivoli
Access
Manager
attributes
and
objects
to
the
input
group
or
set
of
groups.
The
input
group
or
groups
is
read
from
the
standard
input
device.
The
original
group
LDIF
definition
along
with
the
added
LDIF
attributes
and
objects
is
output
to
the
standard
output
device.
You
can
modify
the
script
to
exclude
the
original
group
LDIF
definition,
in
which
case
it
could
be
used
to
perform
an
import
of
existing
groups
to
Tivoli
Access
Manager.
The
script
accepts
any
LDIF
data
from
the
input
stream
but
acts
on
only
the
LDIF
that
creates
group
objects.
All
other
LDIF
data
is
simply
passed
unchanged
through
to
the
standard
output
device.
For
example,
LDIF
data
that
adds
members
to
an
existing
group
or
creates
non-group
objects
is
echoed
to
the
standard
output
device
without
change.
This
script
might
also
need
to
be
modified
to
identify
where
the
Tivoli
Access
Manager’s
cn
attribute
is
obtained.
The
cn
attribute
is
the
Tivoli
Access
Manager’s
definition
of
the
group
name.
As
written,
the
script
assumes
directory
groups
are
named
by
the
cn
attribute.
This
script
requires
one
argument,
domain,
which
is
the
name
of
the
domain
in
which
the
group
belongs,
either
Default
or
a
subdomain
name.
The
script
can
take
an
optional
second
argument,
which
is
the
keyword
acl.
If
specified,
the
script
generates
ACL
entries
for
the
added
objects.
incremental_groups.sh
The
incremental_groups.sh
script
divides
the
input
LDIF
group
membership
definition
into
the
increments
that
are
loaded
separately
into
the
IBM
Directory
using
the
ldapadd
utility.
The
size
of
each
increment
is
defined
in
the
script
and
defaults
to
10,000.
Each
incremental
set
of
members
is
loaded
in
a
separate
invocation
of
ldapadd.
All
non-group
objects
are
passed,
unchanged,
to
the
ldapadd
utility.
Adding
groups
and
the
transaction
log
parameters
For
a
slight
improvement
in
the
performance
of
this
utility,
you
can
increase
the
increment
variable.
This
results
in
a
larger
number
of
members
being
loaded
on
each
incremental
load
and
fewer
total
number
of
loads.
When
the
increment
variable
is
increased,
ensure
that
DB2
transaction
log
parameters
and
the
transaction
log
file
space
is
sufficient
to
handle
the
larger
transaction
size.
For
more
information
on
setting
the
transaction
log
refer
to
the
comments
in
the
db2_tunings.sh
tuning
guide
script,
the
section
“Disk
and
memory
requirements
for
the
IBM
Directory
server”
on
page
3
and
the
section
“Perform
DB2
parameter
tuning”
on
page
12
of
this
book.
If
DB2
transaction
log
parameters
or
the
transaction
log
file
space
is
too
low,
the
ldapadd
utility
will
fail
and
the
IBM
Directory
server
cli.error
(IDS
4.1)
or
db2cli.log
(IDS
5.2
or
later)
might
contain
a
message
similar
to
the
following:
03/08/02
12:16:43
PM
native
retcode
=
-964;
state
=
"57011";
message
=
"[IBM][CLI
Driver][DB2/SUN]
SQL0964C
The
transaction
log
for
the
database
is
full.
SQLSTATE=57011’
Using
the
group
scripts
together
You
can
use
the
example
scripts
in
the
following
way
to
load
a
group
containing
10,000
users:
Chapter
2.
IBM
Directory
information
and
utilities
45
mk_test_users_ldif.sh
1
10000
cn=testusers,o=ibm,c=us
test1pass
|
mk_ldap_group_ldif_stdin.sh
create
cn=testgroup,o=ibm,c=us
|
add_am_to_groups_ldif.sh
dom1
|
incremental_bulkload.sh
You
can
also
combine
the
example
scripts
in
the
following
way
to
add
10000
additional
members
to
the
group
created
in
the
first
example:
mk_test_users_ldif.sh
10000
20000
cn=testusers,o=ibm,c=us
test1pass
|
mk_ldap_group_ldif_stdin.sh
add
cn=testgroup,o=ibm,c=us
|
add_am_to_groups_ldif.sh
dom1
|
incremental_group.sh
The
invocation
of
add_am_to_groups_ldif.sh
is
not
necessary
in
the
previous
example,
so
it
could
be
replaced
with
the
following:
mk_test_users_ldif.sh
10000
20000
cn=testusers,o=ibm,c=us
test1pass
|
mk_ldap_group_ldif_stdin.sh
add
cn=testgroup,o=ibm,c=us
|
incremental_group.sh
Limiting
the
number
of
users
returned
from
pdadmin
user
list
command
Three
conditions
affect
the
maximum
number
of
users
that
can
be
returned
by
the
pdadmin
user
list
command:
1.
The
pattern
max-return
argument
for
the
pdadmin
user
list
command:
pdadmin>
user
list
pattern
max-return
For
example:
pdadmin>user
list
*luca*
2
would
list
only
2
users.
2.
The
max-search-size
stanza
entry
in
the
[ldap]
stanza
of
the
Tivoli
Access
Manager
ldap.conf
configuration
file.
To
indicate
there
is
no
limit,
set
the
maximum
search
size
to
0.
For
example:
max-search-size
=
0
3.
The
ibm-slapdSizeLimit
parameter
in
the
IBM
Directory
server
slapd32.conf
or
ibmslapd.conf
configuration
file.
To
indicate
there
is
no
limit,
set
the
size
limit
to
0.
For
example:
ibm-slapdSizeLimit
=
0
Note:
This
parameter
affects
all
LDAP
searches.
The
final
result
or
output
from
the
pdadmin
user
list
command
is
restricted
by
the
lesser
of
these
three
values.
LDAP
cache
This
section
contains
performance
tuning
tasks
that
are
not
normally
recommended;
however,
there
may
be
some
environments
where
these
performance
tuning
tasks
are
useful.
The
LDAP
cache
is
more
efficient
in
memory
usage
and
faster
than
the
DB2
cache,
yet
not
as
efficient
as
the
Tivoli
Access
Manager
credential
cache.
Disadvantages
to
the
LDAP
cache
are
that
it
becomes
invalidated
on
most
update
operations
and
can
take
a
long
time
to
load.
The
environments
that
benefit
the
most
from
LDAP
caching
are
those
with
small
registry
sizes
and
few
updates.
Keep
in
mind
that
increasing
the
LDAP
cache
size
can
cause
the
slapd
or
the
ibmslapd
process
memory
size
to
exceed
system
limits.
For
information
about
increasing
these
limits,
see
Chapter
5,
“Tuning
process
memory
size
limits,”
on
page
63.
46
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Setting
the
cache
parameters
The
LDAP
cache
parameters
that
are
recommended
for
use
with
Tivoli
Access
Manager
are
RDBM_CACHE_SIZE
and
RDBM_FCACHE_SIZE.
These
parameters
are
defined
to
LDAP
with
environment
variables.
v
To
define
the
LDAP
cache
environment
variables
in
the
command
shell
(before
starting
the
slapd
or
ibmslapd
process),
enter
the
following:
stop
LDAP
#
(slapd
or
ibmslapd
process)
export
RDBM_CACHE_SIZE=value
export
RDBM_FCACHE_SIZE=value
start
LDAP
#
(slapd
or
ibmslapd
process)
v
To
define
the
LDAP
cache
environment
variables
in
the
slap32.conf
or
ibmslapd.conf
configuration
file,
add
the
following
entries
to
the
file:
dn:
cn=Front
End,cn=Configuration
objectclass:
top
objectclass:
ibm-slapdFrontEnd
ibm-slapdSetEnv:
RDBM_CACHE_SIZE=value
ibm-slapdSetEnv:
RDBM_FCACHE_SIZE=value
For
information
on
the
definition
of
these
and
other
LDAP
cache
parameters,
see
the
IBM
Directory
Server
documentation.
Choosing
cache
values
The
primary
use
of
the
LDAP
cache
is
for
caching
authenticated
users.
Ways
to
choose
values
for
the
LDAP
cache
parameters
include
the
following:
v
Base
the
choice
on
the
number
of
users
to
be
cached.
v
Base
the
choice
on
the
amount
of
memory
available
for
caching.
Note:
Both
ways
require
information
on
the
memory
usage
per
cached
user
and
the
number
of
cache
entries
used
per
cached
user.
For
Tivoli
Access
Manager,
the
memory
usage
per
cached
user
is
approximately
3
KB
and
the
number
of
cache
entries
used
(per
cached
user)
is
four
for
the
entry
cache
and
five
for
the
filter
cache.
The
entry
cache
is
controlled
by
RDBM_CACHE_SIZE
and
the
filter
cache
is
controlled
by
RDBM_FCACHE_SIZE.
These
approximations
vary
greatly
with
the
various
Tivoli
Access
Manager
configuration
settings
and
usage.
The
following
conditions
affect
Tivoli
Access
Manager
use
of
LDAP
cache
resources:
v
User-and-group-in-same-suffix
setting
in
the
webseald.conf
and
pdwebpi.conf
files
v
Ordering
and
number
of
LDAP
suffixes
in
the
slapd32.conf
or
ibmslapd.conf
file
v
Authenticating
through
GSO
junctions
Choose
cache
values
based
on
either
the
number
of
users
you
plan
to
create
or
on
the
amount
of
memory
available.
v
To
choose
the
LDAP
cache
settings
based
on
the
number
of
users
created,
use
the
following
formulas:
LDAP
entry
cache
size
=
(number
of
AM
users)
*
4
LDAP
filter
cache
size
=
(number
of
AM
users)
*
5
Memory
requirements
=
(number
of
AM
users)
*
3
KB
Chapter
2.
IBM
Directory
information
and
utilities
47
v
To
choose
the
LDAP
cache
settings
based
on
the
amount
of
memory
available,
use
the
following
formulas:
number
of
AM
users
cached
=
desired
memory
usage
/
3
KB
LDAP
cache
size
=
(number
of
AM
users)
*
4
LDAP
filter
cache
size
=
(number
of
AM
users)
*
5
Table
3
provides
guidelines
for
cache
size
settings.
Because
these
settings
might
not
apply
in
every
case,
make
certain
to
verify
them
(as
explained
in
“Verifying
the
LDAP
cache
resources
usage”).
Table
3.
Cache
Size
Settings
Number
of
AM
Users
Entry
Cache
Size
Filter
Cache
Size
Memory
Usage
Additional
Data
Segments
Needed
(AIX)
10,000
40000
50000
30
MB
0
50,000
200000
250000
150
MB
0
100,000
400000
500000
300
MB
1
Verifying
the
LDAP
cache
resources
usage
Typically,
there
are
two
things
to
verify
regarding
the
LDAP
cache
settings:
one
is
whether
cache
misses
were
eliminated
and
another
is
if
the
LDAP
process
memory
usage
is
as
expected.
To
verify
that
cache
misses
were
eliminated,
periodically
enter
on
one
line
the
following
command
while
LDAP
searches
are
in
progress:
ldapsearch
–h
ldap_host
-s
base
–b
’cn=monitor’
’objectclass=*’
|
grep
entry_cache_miss
If
all
results
come
from
the
LDAP
cache,
the
entry_cache_miss
count
will
remain
constant
throughout
the
usage
of
LDAP.
To
verify
that
the
LDAP
cache
memory
usage
is
as
expected,
monitor
the
process
memory
growth
as
users
are
cached.
The
UNIX
ps
utility
is
recommended.
For
example,
the
following
ps
utility
shows
the
current
memory
size
of
the
LDAP
process:
ps
–e
–o
vsz
–o
–comm
|
grep
slapd
Or:
ps
–e
–o
vsz
–o
–comm
|
grep
ibmslapd
Repeat
this
command
periodically
to
determine
the
memory
size
of
the
slapd
or
the
ibmslapd
process
when
it
levels
off.
To
verify
that
the
LDAP
cache
memory
usage
does
not
exceed
process
memory
size
limits,
watch
the
slapd
or
the
ibmslapd
process
and
verify
that
it
does
not
end
unexpectedly.
If
the
slapd
or
ibmslapd
process
ends
after
increasing
the
LDAP
cache,
it
is
probably
because
it
has
exceeded
the
memory
limits.
Analyzing
performance
problems
with
DB2
statement
monitoring
and
explain
The
do_statement_monitoring.sh
script
can
be
used
to
assist
in
monitoring
a
DB2
statement.
Switch
to
IBM
the
Directory
server’s
DB2
instance
owner,
typically
the
ldapdb2
user.
Ensure
that
the
script
file
ownership
is
that
of
the
DB2
instance
owner
48
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
with
the
same
group
information
as
that
user.
Run
the
script
without
arguments.
It
prompts
when
it
is
ready
for
a
test
to
be
performed.
Do
not
press
Ctrl+C
while
running
the
script,
or
the
statement
monitor
will
continue
to
run.
Instead,
press
enter
and
wait
for
the
script
to
return.
The
proc_stmt_mon_output.awk
script
summarizes
the
output
from
the
statement
monitor.
Run
it
as
follows:
cat
dstate.out
|
awk
-f
proc_stmt_mon_output.awk
where
dstate.out
is
the
output
file
from
the
do_statement_monitoring.sh
script
file.
The
do_explain_sql.sh
script
calls
the
DB2
explain
utility,
which
produces
a
report
showing
the
query
plan
that
the
DB2
optimizer
will
use
to
process
a
SQL
query.
Slow
SQL
queries
can
be
input
to
this
script
to
help
identify
why
they
are
slow.
Run
the
script
without
any
arguments
to
get
information
about
the
input
to
the
script.
Chapter
2.
IBM
Directory
information
and
utilities
49
50
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Chapter
3.
Tuning
Tivoli
Access
Manager
WebSEAL,
plug-ins
for
Web
servers,
and
authorization
server
The
following
sections
provide
tuning
information
for
Tivoli
Access
Manager
WebSEAL,
the
plug-ins
for
Web
servers,
and
the
authorization
server.
The
configuration
files
for
these
servers
can
be
found
at:
UNIX:
/opt/pdweb/etc/webseald.conf
/opt/pdwebpi/etc/pdwebpi.conf
/opt/PolicyDirector/etc/ivacld.conf
/opt/PolicyDirector/etc/ivmgrd.conf
Windows:
pd_install_dir\etc\webseald.conf
pd_install_dir\etc\pdwebpi.conf
pd_install_dir\etc\ivacld.conf
pd_install_dir\etc\ivmgrd.conf
General
purpose
The
following
sections
provide
performance
tuning
procedures
for
general
uses
of
Tivoli
Access
Manager
WebSEAL,
the
plug-ins
for
Web
servers,
and
the
authorization
server.
auth-using-compare
The
default
setting
for
the
auth-using-compare
stanza
entry
in
the
webseald.conf,
pdwebpi.conf,
and
ivacld.conf
configuration
files
is
yes.
This
setting
is
recommended.
The
auth-using-compare
stanza
entry
affects
only
the
performance
of
the
IBM
Directory
server
and
varies
with
the
size
of
the
directory.
This
parameter
has
little
or
no
affect
on
the
WebSEAL
server.
As
compared
to
setting
to
yes,
the
authentication
throughput
of
the
IBM
Directory
server
with
the
no
setting
is
from
5%
faster
with
10
thousand
users
in
the
directory
to
30%
slower
with
1
million
users
in
the
directory.
There
is
evidence
that
the
slower
performance
is
due
to
lock
contention,
so
the
affect
might
also
vary
with
the
number
of
CPUs.
These
results
are
based
on
a
4-CPU
system.
With
the
auth-using-compare
stanza
entry
set
to
no,
Tivoli
Access
Manager
authenticates
using
the
traditional
LDAP
bind
and
unbind
commands.
With
the
auth-using-compare
stanza
entry
set
to
yes,
Tivoli
Access
Manager
authenticates
with
the
IBM
LDAP
unique
search
and
compare
command.
The
auth-using-compare
stanza
entry
is
ignored
when
the
Sun
ONE
Directory
Server
is
used.
user-and-group-in-same-suffix
The
default
setting
for
the
user-and-group-in-same-suffix
stanza
entry
in
the
webseald.conf,
pdwebpi.conf,
and
ivalcd.conf
configuration
files
is
no.
If
possible,
set
this
value
to
yes.
When
this
value
is
set
to
yes,
Tivoli
Access
Manager
assumes
the
user,
and
the
group
or
groups
that
the
user
is
a
member
of,
are
in
the
same
suffix.
When
this
value
is
set
to
no,
Tivoli
Access
Manager
searches
every
suffix
for
a
given
user’s
group
membership.
Setting
the
user-and-group-in-same-suffix
stanza
entry
to
yes
reduces
LDAP
searches
for
authentication.
Authentication
performance
is
directly
related
to
the
number
of
LDAP
search
operations
that
are
performed.
©
Copyright
IBM
Corp.
2001,
2003
51
policy-cache-minimum-size
The
default
setting
of
the
policy-cache-minimum-size
stanza
entry
might
not
be
sufficient
to
provide
the
best
performance.
If
the
stanza
entry
is
not
already
present,
it
should
be
added
to
the
[aznapi-configuration]
stanza
of
the
applicable
configuration
file.
For
WebSEAL,
the
configuration
file
is
webseald.conf.
For
the
plug-ins
for
Web
Servers,
it
is
pdwebpi.conf.
For
the
policy
server,
it
is
ivmgrd.conf.
The
following
information
describes
this
cache
and
provides
some
guidelines
on
how
to
set
it.
v
The
minimum
size
of
the
in-memory
policy
cache
index
is
configurable.
The
cache
consists
of
the
policy
and
the
relationships
between
the
policy
and
the
resources.
The
knowledge
that
a
resource
has
no
directly
associated
policy
is
also
cached.
v
The
minimum
size
of
the
cache
index
should
be
relative
to
the
number
of
policy
objects
that
are
defined
and
the
number
of
resources
that
are
protected.
An
internal
calculation
is
performed
to
derive
the
cache
size
by
using
the
policy
database.
This
calculation
might
not
be
large
enough
because
it
does
not
take
into
account
the
resources
that
do
not
have
a
policy
directly
attached.
Resources
that
do
not
have
a
policy
attached
might
not
be
stored
in
the
policy
database.
A
reasonable
algorithm
to
begin
with
is:
((number
of
policy
objects
*
3)
+
(number
of
protected
resources
*
3))/2
This
value
does
not
control
how
much
information
is
cached.
All
policy
and
related
information
is
cached.
It
can,
however,
improve
or
retard
the
look-up
speed
within
the
cache.
The
cache
size
that
is
used
is
the
maximum
of
the
minimum
specified
here
and
the
derived
value.
The
size
is
specified
as
the
number
of
expected
entries.
policy-cache-minimum-size
=
4096
Special
case
purposes
The
following
sections
describe
tuning
procedures
for
specific
circumstances.
LDAP
root
administrator
account
(cn=root)
When
Tivoli
Access
Manager
is
configured,
it
creates
LDAP
user
accounts
that
are
used
to
access
the
LDAP
directory.
The
IBM
Directory
server
administrator
can
set
ACLs
in
the
directory
that
allow
or
deny
Tivoli
Access
Manager
server
users
access
to
parts
of
the
directory
tree.
For
the
IBM
Directory
server,
the
additional
ACL
checking
associated
with
each
LDAP
search
results
in
a
slight
performance
reduction
of
approximately
10
percent.
The
IBM
Directory
server
does
not
perform
ACL
checking
when
the
account
that
is
used
to
access
the
directory
is
that
of
the
LDAP
root
administrator.
By
changing
the
Tivoli
Access
Manager
configuration
to
use
the
LDAP
root
administrator’s
account
(usually
cn=root),
ACL
checking
is
eliminated.
The
stanza
entries
that
control
this
are
bind-dn
and
the
bind-pwd
stanza
entries
in
the
Tivoli
Access
Manager
server
configuration
files.
Note
that
in
IBM
Tivoli
Access
Manager
Version
5.1,
the
bind-pwd
stanza
entry
is
obfuscated.
Refer
the
server
configuration
file
information
in
the
IBM
Tivoli
Access
Manager
Base
Administration
Guide
for
information
on
changing
values
for
these
stanza
entries.
52
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Load
balancing
between
LDAP
replicas
(WebSEAL
only)
Tivoli
Access
Manager
can
balance
its
authentication
load
between
multiple
IBM
Directory
servers.
In
environments
where
the
IBM
Directory
server
is
the
bottleneck,
each
additional
IBM
Directory
server
results
in
a
linear
improvement
to
authentication
performance.
Note:
Authentication
performance
also
depends
on
the
authentication
load
throughput
of
the
Tivoli
Access
Manager
WebSEAL
servers
and
the
junctioned
backend
Web
servers
(if
they
are
used).
The
performance
improvement
for
adding
an
IBM
Directory
server
is
apparent
only
if
the
IBM
Directory
server
is
the
bottleneck.
The
ldap.conf
configuration
file
controls
the
definition
of
the
IBM
Directory
server
(or
servers)
for
use
during
authentication.
The
Tivoli
Access
Manager
ldap.conf
configuration
file
can
be
found
at:
UNIX:
/opt/PolicyDirector/etc/ldap.conf
Windows:
pd_install_dir\etc\ldap.conf
SSL
between
Tivoli
Access
Manager
and
LDAP
The
communication
protocol
between
Tivoli
Access
Manager
and
LDAP
can
be
either
Transmission
Control
Protocol
(TCP)
or
Secure
Sockets
Layer
(SSL).
Because
traffic
between
Tivoli
Access
Manager
and
LDAP
is
light
in
comparison
to
HTTP/HTTPS
traffic
and
because
communication
is
over
a
static
SSL
session,
the
performance
difference
between
using
TCP
and
SSL
is
approximately
10
percent.
SSL
session
cache,
user
credential
cache,
and
memory
use
The
configuration
files
for
the
Tivoli
Access
Manager
servers
can
be
found
at:
UNIX:
/opt/pdweb/etc/webseald.conf
/opt/pdwebpi/etc/pdwebpi.conf
Windows:
pd_install_dir\etc\webseald.conf
pd_install_dir\etc\pdwebpi.conf
The
following
stanza
entries
in
the
webseald.conf
and
pdwebpi.conf
files
are
relevant
to
these
caches:
[ssl]
ssl-v2-timeout
=
100
ssl-v3-timeout
=
7200
ssl-max-entries
=
4096
[session]
max-entries
=
4096
timeout
=
3600
inactive-timeout
=
600
The
ssl-max-entries
and
max-entries
stanza
entries
control
the
size
of
the
SSL
and
credential
caches,
respectively.
Increases
to
the
SSL
and
credential
cache
sizes
can
cause
WebSEAL
or
plug-ins
for
Web
servers
process
memory
usage
to
exceed
system
limits.
For
information
about
increasing
these
limits,
see
Chapter
5,
“Tuning
process
memory
size
limits,”
on
page
63.
Chapter
3.
Tuning
Tivoli
Access
Manager
WebSEAL,
plug-ins
for
Web
servers,
and
authorization
server
53
The
SSL
session
cache
uses
about
250
bytes
of
process
memory
per
entry
and
the
credential
cache
uses
about
7.5
KB
of
process
memory
per
entry.
The
previous
numbers
are
for
AIX
only.
On
Solaris
systems,
the
combined
SSL
session
cache
and
credential
caches
use
about
5.6
KB
per
entry.
It
is
probably
sufficient
to
consider
an
average
of
about
7
KB
per
entry.
Note:
The
[ssl]
configuration
file
stanza
is
not
available
in
the
plug-ins
for
Web
servers
configuration
file,
since
the
SSL
processing
is
handled
by
the
native
Web
server
and
not
the
plug-in.
Number
of
worker
threads
for
WebSEAL
The
worker-threads
stanza
entry,
located
in
the
webseald.conf
configuration
file,
specifies
the
number
of
worker
threads
that
WebSEAL
allocates
for
handling
incoming
requests.
In
most
cases,
it
is
not
necessary
to
adjust
the
worker-threads
stanza
entry.
The
primary
situation
in
which
increasing
the
number
of
worker
threads
improves
performance
is
thread
starvation
due
to
a
slow
backend
Web
server.
A
slow
backend
Web
server
can
block
a
worker
thread
until
that
server
responds.
If
all
50
of
the
default
worker
threads
become
blocked,
thread
starvation
will
occur
and
WebSEAL
will
not
be
able
to
process
any
further
requests.
Another
situation
in
which
WebSEAL
worker
thread
starvation
can
occur
is
a
long
running
CGI
script
or
executable
Web
page
served
by
WebSEAL.
When
this
situation
occurs,
it
is
recommended
that
the
executable
Web
page
be
moved
to
a
backend
Web
server.
The
following
explains
why
moving
the
executable
Web
pages
is
better
than
increasing
the
number
of
worker
threads.
WebSEAL
does
a
fork
function
to
process
an
executable
Web
page.
The
fork
function
makes
a
copy
of
the
process
memory
image.
Any
increase
in
number
of
worker
threads
also
increases
the
process
memory
size,
slows
down
the
fork
function,
and
negates
the
performance
improvement
from
increasing
the
number
of
worker
threads.
Detecting
worker
thread
starvation
One
way
to
detect
worker
threads
starvation
is
to
reduce
the
worker-thread-hard-limit
and
worker-thread-soft-limit
stanza
entries
in
the
/opt/pdweb/etc/webseald.conf
file.
When
these
values
are
exceeded,
warning
and
error
messages
are
written
to
the
WebSEAL
log
files.
The
default
value
of
100%
means
there
is
no
limit
and
no
messages
are
written.
When
the
number
of
active
worker
threads
reaches
the
soft
limit,
a
warning
message
is
generated.
When
the
number
of
active
worker
threads
reaches
the
hard
limit,
an
error
message
is
generated
and
a
503,
Service
Unavailable,
error
is
returned
to
the
requesting
Web
browser.
The
soft
and
hard
limits
can
also
be
specified
on
a
per-junction
basis
through
the
pdadmin
junction
create
command
with
the
–l
and
–L
options.
Refer
to
the
information
about
creating
a
new
junction
for
an
initial
server
in
the
IBM
Tivoli
Access
Manager
for
e-business
WebSEAL
Administration
Guide.
Another
way
to
detect
a
worker
thread
starvation
situation
is
to
use
the
WebSEAL
active
worker
thread
static.
To
get
this
information:
1.
Issue
the
following
command:
pdadmin
-a
sec_master
-p
password
server
list
where
sec_master
is
the
security
master
account
which
defaults
to
sec_master
and
password
is
the
security
master
account
password.
This
command
returns
a
list
of
the
names
of
all
the
WebSEAL
servers
configured
into
the
policy
server.
54
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
2.
Find
the
name
of
the
WebSEAL
server
of
interest,
which
was
returned
on
the
previous
command,
and
issue
the
following
command
on
one
line
against
that
Web
server
to
determine
the
number
of
active
worker
threads:
pdadmin
-a
sec_master
-p
password
server
task
webseal_server
stats
get
pdweb.threads
where
webseal_server
is
the
name
returned
on
the
first
command
for
the
WebSEAL
server
of
interest.
This
command
returns
the
number
of
active
threads
and
the
number
of
total
threads.
3.
If
the
number
of
active
and
total
threads
is
equal
or
near
equal,
increase
the
number
of
worker
threads,
and
restart
the
WebSEAL
server.
Other
indications
that
worker
thread
starvation
is
occurring
include
the
following:
v
Web
browsers
get
timeout
errors.
v
Response
times
are
high,
yet
WebSEAL
server
CPU
utilization
is
low.
v
Thread
stack
dumps
indicate
WebSEAL
worker
threads
are
blocked
on
receive
and
not
on
a
mutex,
meaning
they
are
waiting
for
work.
v
TCP/IP
packet
traces
indicate
the
number
of
active
requests
that
WebSEAL
is
processing
is
equal
to
the
number
of
worker
threads.
Worker
thread
resource
usage
and
limits
Each
additional
worker
thread
consumes
about
450
KB
of
virtual
memory
and
two
TCP/IP
sockets.
Physical
memory
is
limited
by
the
sum
of
physical
memory
and
the
paging
space
on
the
system.
To
prevent
thrashing,
process
memory
usage
should
be
limited
to
the
available
physical
memory.
TCP/IP
sockets
are
limited
by
the
number
of
file
descriptors
in
the
operating
system,
based
on
the
following
formula:
(maximum
file
descriptor
-
65
)
/
2
The
maximum
file
descriptor
is
2,048
on
both
AIX
and
Windows,
and
1,024
on
Solaris.
This
limits
the
maximum
number
of
worker
threads
to
991
on
both
AIX
and
Windows,
and
to
479
on
Solaris.
Increasing
the
number
of
worker
threads
can
cause
WebSEAL
or
plug-ins
for
Web
servers
process
memory
usage
to
exceed
system
limits.
See
Chapter
5,
“Tuning
process
memory
size
limits,”
on
page
63
for
information
about
increasing
these
limits.
Optimal
heap
allocation
on
Solaris
SMP
systems
The
following
information
is
specific
to
Tivoli
Access
Manager
WebSEAL
or
the
plug-ins
for
Web
servers
running
on
Sun
Ultra
Symmetric
Multi-Processor
(SMP)
systems
using
the
Solaris
operating
system.
SMP
systems
can
experience
performance
degradation
when
multiple
threads
make
concurrent
heap
requests.
Compiler
runtime
libraries
are
designed
for
single-processor
environments.
They
allow
only
one
thread
at
a
time
to
be
active
in
a
key
resource
that
is
constantly
used
by
all
threads:
the
heap.
On
single
CPU
systems
this
is
not
a
problem
since
only
one
thread
runs
at
any
given
time.
But
on
multi-CPU
systems
where
multiple
threads
make
concurrent
heap
requests,
all
but
one
is
blocked
by
the
heap
manager,
effectively
nullifying
the
benefit
of
the
extra
CPUs.
Chapter
3.
Tuning
Tivoli
Access
Manager
WebSEAL,
plug-ins
for
Web
servers,
and
authorization
server
55
Additionally,
each
time
a
thread
is
blocked,
it
loses
its
time
slice
and
causes
an
immediate
(and
very
expensive)
operating
system
context
switch
that
uses
up
otherwise
useful
cycles.
Adding
processors
increases
the
number
of
concurrent
threads,
thus
increasing
the
likelihood
of
heap
blocking
and
the
consequential
context
switches.
Extra
CPUs
can
actually
cause
a
vicious
cycle
of
operating
system
context
switching
overhead
that
can
slow
an
application’s
overall
performance
to
below
single
processor
levels.
Tivoli
Access
Manager
WebSEAL
and
the
plug-ins
for
Web
servers
ships
with
a
library
that
replaces
standard
heap
allocators
with
alternative
allocators
to
improve
performance.
These
alternative
allocators
more
successfully
eliminate
heap
contention
and
allow
multiple
threads
to
proceed
with
reduced
blocking
and
true
concurrency.
By
eliminating
heap
contention
and
associated
operating
system
overhead,
a
near
linear
performance
can
be
obtained
with
additional
CPUs.
To
enable
this
feature,
the
default
WebSEAL
startup
script
(/usr/bin/pdweb
start)
contains
the
necessary
lines
of
code
to
pre-load
and
enable
the
alternative
heap
allocator.
WebSEAL
on
Solaris
SMP
systems
experiences
poor
performance
if
this
alternative
allocator
is
not
loaded
and
enabled.
Such
a
situation
can
occur
if
WebSEAL
is
started
by
a
method
other
than
the
default
startup
script.
For
example,
manually
running
WebSEAL
in
the
foreground:
#
/opt/pdweb/webseald
–foreground
When
starting
WebSEAL
in
a
Sun
Ultra
SMP
/
Solaris
environment,
ensure
the
LD_PRELOADenvironment
variable,
with
a
value
set
for
the
libpdmemmgmt.so
library,
is
exported
before
starting
WebSEAL.
The
libpdmemmgmt.so
library
calls
the
alternative
allocator
program.
For
example:
#
export
LD_PRELOAD="libpdmemmgmt.so"
The
default
startup
script
(usr/bin/pdweb
start)
automatically
performs
this
export
instruction.
IRA
tuning
information
The
Tivoli
Access
Manager
IRA
cache
is
a
cache
of
LDAP
information;
therefore,
the
IRA
cache
only
applies
to
Tivoli
Access
Manager
configurations
that
use
LDAP
as
the
registry
interface.
The
following
are
some
of
the
directory
products
that
use
LDAP
as
the
registry
interface:
v
The
IBM
Directory
server
v
The
Sun
ONE
Directory
server
Authentication
(user
login)
performance
is
fastest
when
authentication
information
comes
from
the
Tivoli
Access
Manager
IRA
cache.
The
disadvantage
to
the
IRA
cache
is
that
the
information
can
become
stale
and
not
accurately
reflect
recent
updates
in
the
IBM
Directory
server.
For
example,
an
update
to
a
user’s
group
membership
is
not
reflected
in
the
IRA
cache
until
that
user’s
cache
entry
times
out.
Another
potential
disadvantage
is
the
information
in
the
cache
might
be
considered
sensitive.
In
many
environments
this
information
is
not
considered
sensitive.
Note
that
in
no
case
is
the
user
password
cached.
The
following
information
is
stored
in
this
IRA
cache:
v
UUID
v
principalName
56
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
v
DN
v
accountValid
v
passwordValid
v
group
membership
v
user-specific
policy
(such
as
when
password
was
last
changed)
The
IRA
environment
variables
offer
options
to
disable
the
use
of
certain
information
in
the
cache,
thereby
forcing
a
registry
lookup
for
that
information
any
time
it
is
needed.
The
following
cache
information
can
be
disabled
through
the
use
of
IRA
cache
environment
variables:
v
accountValid
v
passwordValid
v
group
membership
This
information
is
controlled
with
the
following
IRA
environment
variables:
v
IRA_CACHE_USER_VALID_FLAGS
v
IRA_CACHE_GROUP_MEMBERSHIP
Although
not
recommended,
the
cache
can
be
completely
disabled
through
the
cache-enabled
stanza
entry
in
the
[ldap]
stanza
of
the
following
configuration
files:
/opt/pdwebpi/etc/pdwebpi.conf
/opt/pdweb/etc/webseald.conf
/opt/PolicyDirector/etc/ivacld.conf
It
is
not
recommended
that
the
IRA
cache
be
completely
disabled.
The
IRA
cache
provides
a
big
performance
improvement
in
authenticating
even
non-cached
users
because
of
the
reduction
in
redundant
registry
lookups
that
the
cache
provides.
By
leaving
the
user
cache
timeout
at
its
default
of
30
seconds,
the
stale
cache
and
sensitive
information
concerns
are
addressed.
As
long
as
the
timeouts
are
left
short,
it
is
also
recommended
that
the
cache
be
enabled
to
use
the
accountValid,
passwordValid,
and
group
membership
information.
The
default
value
for
each
of
these
is
enable.
If
you
use
the
IRA
cache
to
improve
authentication
performance,
the
size
and
timeout
values
of
the
cache
must
be
increased.
Also,
consideration
should
be
made
as
to
whether
to
disable
the
use
of
the
accountValid,
passwordValid,
and
group
membership
information.
By
disabling
the
use
of
that
information,
the
number
of
registry
lookups
increases
and
removes
some
of
the
performance
benefit
of
the
IRA
cache.
As
a
guideline,
do
not
increase
the
IRA
cache
if
the
number
of
users
that
are
expected
to
authenticate
is
greater
than
10,000.
Increasing
the
IRA
cache
parameters
can
cause
WebSEAL
or
plug-ins
for
Web
servers
process
memory
usage
to
exceed
system
limits.
See
Chapter
5,
“Tuning
process
memory
size
limits,”
on
page
63
for
information
about
increasing
these
limits.
User
cache
IRA_USER_CACHE_SIZE:
Default:
256
entries
Chapter
3.
Tuning
Tivoli
Access
Manager
WebSEAL,
plug-ins
for
Web
servers,
and
authorization
server
57
Recommended:
If
the
IRA
cache
is
to
be
used
to
improve
authentication
performance,
set
this
to
the
number
of
users
that
are
expected
to
authenticate,
plus
some
overhead
(for
example,
15%)
for
peak
usage
but
not
greater
than
10,000.
Otherwise,
leave
it
the
default
value.
Controls
the
number
of
user
entries
cached
in
memory
for
the
WebSEAL
LDAP
client
cache.
The
user
entry
contains:
UUID
principalName
DN
accountValid
passwordValid
group
membership
user
specific
policy
...
IRA_USER_EXPIRE_TIME:
Default:
30
seconds
Recommended:
If
the
IRA
cache
is
to
be
used
to
improve
authentication
performance,
set
this
very
high
(for
example,
28800
seconds
for
8
hours,
86400
for
daily
or
604800
for
weekly).
Otherwise,
leave
it
the
default
value.
Controls
the
amount
of
time
in
seconds
that
the
user
entry
is
cached
in
memory
for
the
WebSEAL
LDAP
client
cache.
After
the
time
expires,
WebSEAL
must
reissue
the
LDAP
queries
to
refresh
the
WebSEAL
LDAP
client
cache.
Each
user
request
is
2
LDAP
queries
IRA_CACHE_USER_VALID_FLAGS:
Default:
1
(Yes)
Recommended:
If
the
IRA
cache
is
to
be
used
to
improve
authentication
performance,
consider
setting
this
to
0
(No).
Otherwise,
leave
it
the
default
value.
This
flag
is
checked
only
when
the
user
logs
in.
If
the
user
entry
exists
in
the
WebSEAL
LDAP
client
cache
and
the
current
setting
is:
v
Default:
1
(Yes)
The
accountValid
and
passwordValid
are
obtained
from
the
user
entry
in
cache,
even
though
the
accountValid
and
passwordValid
might
have
changed
on
the
IBM
Directory
server.
Updated
accountValid
and
passwordValid
changes
might
not
be
visible
to
WebSEAL
until
after
the
user
entry
in
the
WebSEAL
LDAP
client
cache
has
expired
(up
to
IRA_USER_EXPIRE_TIME
seconds)
and
then
the
user
logs
in.This
is
beneficial
for
stress
testing
when
the
same
user
logs
in
and
logs
off
repeatedly;
however,
the
administrator
accountValid
and
passwordValid
change(s)
may
appear
to
be
random
in
production.
v
0
(No)
Each
time
the
user
logs
in
the
accountValid
and
passwordValid
flags
from
the
user
entry
in
the
WebSEAL
LDAP
client
cache
are
bypassed
to
determine
the
current
settings
regardless
of
the
age
of
the
user
entry
in
the
cache.
Therefore,
each
time
the
user
logs
in,
an
LDAP
query
is
issued
to
the
IBM
Directory
server.
58
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
If
an
administrator
changes
the
passwordValid
or
accountValid
flags,
then
WebSEAL
can
retrieve
the
current
settings
after
the
user
logs
in
the
very
next
time.
This
is
beneficial
for
production
due
to
the
predictable
behavior;
however,
during
stress
tests
when
the
same
user
logs
in
and
logs
off
repeatedly,
this
action
could
create
additional
overhead
bypassing
the
WebSEAL
LDAP
client
cache
for
each
login.
IRA_CACHE_GROUP_MEMBERSHIP:
Default:
1
(Yes)
Recommended:
If
the
IRA
cache
is
to
be
used
to
improve
authentication
performance,
consider
setting
this
to
0
(No).
Otherwise,
leave
it
the
default
value.
This
flag
is
only
effective
when
the
user
logs
in.
If
the
user
entry
exists
in
the
WebSEAL
LDAP
client
cache
and
current
setting
is:
v
Default:
1
(Yes)
The
user’s
group
memberships
are
obtained
from
the
user
entry
in
cache,
even
though
the
group
memberships
might
have
changed
on
the
IBM
Directory
server.
Any
group
membership
additions
or
deletions
may
not
be
visible
to
WebSEAL
until
after
the
user
entry
in
the
WebSEAL
LDAP
client
cache
has
expired
(potentially
up
to
IRA_USER_EXPIRE_TIME)
and
then
the
user
logs
in.This
is
beneficial
for
stress
testing
when
the
same
user
logs
in
and
logs
off
repeatedly;
however,
the
administrator
might
not
be
able
to
perceive
addition
or
deletion
of
a
user’s
groups
immediately.
v
0
(No)
Each
time
the
user
logs
in
the
user’s
group
memberships
from
the
user
entry
in
the
WebSEAL
LDAP
client
cache
is
bypassed
to
determine
to
which
groups,
the
user
currently
belongs.
Therefore,
each
time
the
user
logs
in,
an
LDAP
query
is
issued
to
the
IBM
Directory
server.
If
an
administrator
adds
or
deletes
a
user’s
groups,
WebSEAL
can
see
the
current
group
membership
after
the
user
logs
in
the
very
next
time.
This
is
beneficial
for
production
due
to
the
predictable
behavior;
however,
during
stress
tests
when
the
same
user
logs
in
and
logs
off
repeatedly,
it
could
create
additional
overhead
bypassing
the
WebSEAL
LDAP
client
cache
for
each
login.
Group
cache
IRA_GROUP_CACHE_SIZE:
Default:
64
entries
Recommended:
Set
to
the
total
number
of
groups
in
which
users
have
membership
plus
some
overhead
(for
example,
15%)
for
peak
usage
but
not
greater
than
10,000.
Controls
the
number
of
group
entries
cached
in
memory
for
the
WebSEAL
LDAP
client
cache.
The
group
entry
contains:
UUID
groupName
DN
...
Chapter
3.
Tuning
Tivoli
Access
Manager
WebSEAL,
plug-ins
for
Web
servers,
and
authorization
server
59
IRA_GROUP_EXPIRE_TIME:
Default:
300
seconds
(5
minutes)
Recommended:
28800
seconds
(8
hours)
Controls
the
amount
of
time
in
seconds
that
the
group
entry
is
cached
in
memory.
After
the
time
expires,
WebSEAL
must
reissue
the
LDAP
queries
to
refresh
the
WebSEAL
LDAP
client
cache.
The
user
may
belong
to
multiple
groups.
Each
group
for
the
user
not
in
cache
is
2
LDAP
queries.
IRA_GLOBAL_POLICY_EXPIRE_TIME:
Default:
30
seconds
Recommended:
30
seconds
Controls
the
amount
of
time
in
seconds
that
the
any
global
policy
changes
is
effective.
Process
the
WebSEAL
logs
for
throughput
information
The
wwwlog_tput_calc.sh
monitoring
and
diagnostic
aid
script
can
be
used
to
process
the
WebSEAL
www
logs
to
extract
WebSEAL
throughput
history
information.
The
script
accepts
an
argument
that
is
either
noauth
or
auth.
With
noauth,
the
script
counts
all
pages,
except
pages
with
401
status.
With
the
auth
value,
the
script
counts
only
pages
with
a
401
status,
which
is
common
for
Basic
Authentication
(BA).
60
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Chapter
4.
Tuning
the
AIX
operating
system
for
Tivoli
Access
Manager
and
LDAP
The
following
environment
variables
improve
the
performance
of
Tivoli
Access
Manager
servers:
v
SPINLOOPTIME=650
(for
SMP
systems)
v
MALLOCMULTIHEAP=1
(for
SMP
systems)
Note
that
the
Tivoli
Access
Manager
pd_start
overrides
the
MALLOCMULTIHEAP
environment
variable
and
sets
it
to
heaps:n,
where
n
is
the
number
of
CPUs
+
1.
Tivoli
Access
Manager
runs
faster
on
AIX
version
5.2
with
MALLOCMULTIHEAP=1.
It
is
recommended
that
the
pd_start
script
be
modified
to
set
the
MALLOCMULTIHEAP=1
for
better
performance.
v
AIXTHREAD_MUTEX_DEBUG=OFF
v
AIXTHREAD_SCOPE=S
v
MALLOCTYPE=BUCKETS
The
following
environment
variables
improve
the
performance
of
the
IBM
Directory
server:
v
SPINLOOPTIME=650
(for
SMP
systems)
v
MALLOCMULTIHEAP=1
(for
SMP
systems)
Following
are
some
ways
you
can
set
environment
variables:
v
Temporarily
define
the
environment
variables
before
starting
the
server,
then
undefine
them.
Here
is
an
example:
export
SPINLOOPTIME=650
export
MALLOCMULTIHEAP=1
...
pd_start
start
unset
SPINLOOPTIME
unset
MALLOCMULTIHEAP
...
v
Pass
the
environment
variable
on
the
server
start
command.
Here
is
an
example:
SPINLOOPTIME=650
MALLOCMULTIHEAP=1
...
ibmslapd
v
For
IBM
Directory
server,
define
the
environment
variables
in
the
slapd32.conf
or
ibmslapd.conf
configuration
files.
For
more
information,
see
the
IBM
Directory
Server
documentation.
v
Define
the
variables
in
the
/etc/environment
file.
For
the
environment
variables
in
the
/etc/environment
file
to
take
effect,
the
user
must
log
off
and
back
on
again
before
starting
the
server.
The
advantage
of
this
approach
is
that
it
eliminates
the
human
error
that
is
involved
in
remembering
a
non-standard
way
of
starting
the
servers.
The
disadvantage
is
the
potential
to
affect
other
processes
in
the
system.
At
this
time,
there
are
no
known
processes
that
are
detrimentally
affected
by
the
setting
of
these
environment
variables.
©
Copyright
IBM
Corp.
2001,
2003
61
62
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Chapter
5.
Tuning
process
memory
size
limits
On
UNIX
platforms,
some
of
LDAP
and
Tivoli
Access
Manager
performance
tuning
tasks
in
this
document
result
in
process
sizes
that
exceed
the
operating
system
default
limits.
This
section
describes
how
to
increase
the
operating
system
limits
so
that
the
affected
processes
do
not
run
out
of
memory.
When
a
process
runs
out
of
memory,
the
process
often
ends.
In
some
cases,
it
leaves
a
core
dump
file,
an
error
message,
or
an
error
log
entry.
On
AIX
systems,
the
system
error
log
might
indicate
that
the
process
ended
due
to
memory
allocation
failure.
Use
the
errpt
–a
|
more
command
to
display
the
error
log.
Increasing
the
operating
system
process
memory
size
limits
On
UNIX
systems,
each
user
can
either
inherit
resource
limits
from
the
root
user
or
have
specific
limits
defined.
The
most
useful
setting
to
use
for
the
process
size
limits
is
unlimited.
That
way,
the
system
process
size
limits
are
defined
to
allow
the
maximum
process
growth.
On
AIX
systems,
the
process
size
limits
are
defined
in
the
/etc/security/limits
file.
A
value
of
–1
indicates
that
there
is
either
no
limit
or
that
it
is
unlimited.
The
names
of
the
limits
to
increase
are
data
and
rss.
For
changes
to
the
/etc/security/limits
file
to
take
effect,
the
user
must
log
out
of
the
current
login
session
and
log
back
in.
On
AIX,
some
limits
may
apply
to
the
root
user.
On
Solaris
systems,
the
process
size
limits
are
defined
by
the
ulimit
command.
You
can
specify
a
value
of
unlimited
on
the
command.
The
names
of
the
limits
to
increase
are
data
and
vmemory.
By
default
on
Solaris
systems,
the
root
user
has
unlimited
access
to
these
resources
(for
example,
unlimited).
When
setting
resource
limits
for
a
process,
it
is
important
to
know
that
the
limits
that
apply
are
those
that
are
in
effect
for
the
parent
process
and
not
the
limits
for
the
user
under
which
the
process
runs.
For
example,
Tivoli
Access
Manager
servers
run
under
the
ivmgr
user
account
created
at
install
time,
yet
Tivoli
Access
Manager
servers
are
typically
started
while
logged
in
as
the
root
user.
This
means
that
any
limits
in
effect
for
the
ivmgr
user
have
no
effect
on
Tivoli
Access
Manager
server
processes,
unless
the
Tivoli
Access
Manager
servers
are
started,
for
example
by
using
by
pd_start
command,
while
logged
in
as
the
ivmgr
user.
AIX-specific
process
size
limits
On
AIX
systems,
the
number
of
data
segments
that
a
process
is
allowed
to
use
also
limits
the
process
memory
size.
The
default
number
of
data
segments
is
1.
The
size
of
a
data
segment
is
256
MB.
Data
segments
are
shared
for
both
data
and
stack.
The
maximum
number
of
data
segments
a
process
can
use
is
8.
Setting
the
maximum
number
of
AIX
data
segments
On
AIX,
the
number
of
segments
that
a
process
can
use
for
data
is
controlled
by
the
LDR_CNTRL
environment
variable.
It
is
defined
in
the
parent
process
of
the
process
that
is
to
be
affected.
For
example,
the
following
example
defines
one
additional
data
segment:
export
LDR_CNTRL=MAXDATA=0x10000000
start_process
unset
LDR_CNTRL
©
Copyright
IBM
Corp.
2001,
2003
63
It
is
a
good
idea
to
unset
the
LDR_CNTRL
environment
variable,
so
that
it
does
not
unintentionally
affect
other
processes.
Unlike
other
environment
variables
for
the
IBM
Directory
server
process
(slapd
or
ibmslapd),
the
LDR_CNTRL
environment
variable
cannot
be
set
as
a
front-end
variable
in
the
slapd32.conf
or
ibmslapd.conf
configuration
file.
It
must
be
set
as
an
environment
variable.
Table
4
shows
the
LDR_CNTRL
setting
and
memory
increase
for
various
numbers
of
data
segments:
Table
4.
LDR_CNTRL
Settings
LDP_CNTRL
Setting
Total
Number
of
Segments
Process
Memory
Limit
Unset
0(default)
256
MB
LDR_CNTRL=MAXDATA=0x10000000
1
256
MB
LDR_CNTRL=MAXDATA=0x20000000
2
512
MB
LDR_CNTRL=MAXDATA=0x30000000
3
768
MB
LDR_CNTRL=MAXDATA=0x40000000
4
1
GB
LDR_CNTRL=MAXDATA=0x50000000
5
1.24
GB
LDR_CNTRL=MAXDATA=0x60000000
6
1.5
GB
LDR_CNTRL=MAXDATA=0x70000000
7
1.75
GB
LDR_CNTRL=MAXDATA=0x80000000
8
2
GB
If
an
invalid
setting
is
used
for
the
LDR_CNTRL
environment
variable,
it
will
be
ignored
and
the
default
one-segment
usage
will
be
defined.
AIX
data
segments
and
LDAP
process
DB2
connections
On
AIX,
process
segments
are
used
for
increasing
a
process
memory
size
and
for
shared
memory.
A
segment
can
be
used
for
one
or
the
other
of
these
purposes,
but
not
for
both.
When
possible,
the
IBM
Directory
server
uses
shared
memory
to
communicate
between
its
server
process
(slapd
or
ibmslapd)
and
DB2
processes.
Each
shared
segment
used
in
this
way
is
a
connection
to
the
DB2
database.
If
there
are
not
enough
process
segments
to
satisfy
the
number
of
DB2
connections
defined
in
the
IBM
Directory
server
configuration
file
(slapd32.conf
or
imbslapd.conf),
the
remaining
connections
are
satisfied
by
using
local
TCP/IP
sockets.
For
this
reason,
there
is
no
conflict
between
increasing
the
process
memory
size
of
the
IBM
Directory
server
process
and
increasing
the
number
of
DB2
connections
defined
for
the
IBM
Directory
server
to
use.
Verifying
process
data
segment
usage
If
the
perfagent.tools
are
installed,
/usr/bin/svmon
-P
pid
shows
the
memory
usage
of
a
process.
In
the
output,
identify
the
segments
labeled
shmat/mmap.
Segments
with
an
Inuse
column
of
zero
(0)
are
for
data
segments
that
are
available
for
process
growth.
Segments
with
an
Inuse
column
greater
than
1
are
for
data
segments
in
which
the
process
has
already
grown.
Segments
with
an
Inuse
column
of
1
are
usually
found
in
the
slapd
or
the
ibmslapd
process
and
represent
the
shared
memory
segments
being
used
for
DB2
connections.
64
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Chapter
6.
Troubleshooting
When
a
problem
occurs
that
appears
to
be
related
to
the
IBM
Directory
server,
you
should
first
check
the
following
files
for
error
messages.
For
IBM
Directory
Server
version
4.1:
v
slapd.errors
v
cli.error
For
IBM
Directory
Server
version
5.1
or
later:
v
ibmslapd.log
v
db2cli.log
On
systems
with
IBM
Directory
Server,
Version
4.1,
the
default
location
of
these
files
is
/var/ldap
for
Solaris
and
/tmp
for
AIX.
On
systems
with
IBM
Directory
Server,
Version
5.1
or
later,
the
default
location
is
/var/ldap
for
both
Solaris
and
AIX.
On
IBM
Directory
Server,
Version
4.1,
you
can
change
the
location
of
the
slapd.errors
file
(but
not
the
cli.error
file)
by
updating
the
ibm-slapdErrorLog
parameter
in
the
slapd32.conf
configuration
file.
On
IBM
Directory
Server,
Version
5.1
and
later,
you
can
change
the
location
of
both
of
these
files
by
modifying
the
ibm-slapdErrorLog
and
ibm-slapdCLIErrors
parameters
in
the
ibmslapd.conf
configuration
file.
Problem:
errors
when
starting
the
IBM
Directory
server
Get
message
SQL1478W
The
database
has
been
started
but
only
one
buffer
pool
has
been
activated.
SQLSTATE=01626
on
db2
connect
to
ldapdb2
or
a
similar
message
when
starting
the
IBM
Directory
server
Cause
1:
On
Solaris
systems,
this
is
typically
due
to
the
shmsys:shminfo_shmmax
parameter
in
/etc/system
not
being
set
high
enough
to
support
the
DB2
cache.
Solution:
Change
the
value
of
the
shmsys:shminfo_shmmax
in
the
/etc/system
file
and
restart
the
system.
See
“Increase
the
shared
memory
maximum
(shmmax)”
on
page
8
for
more
information.
Cause
2:
This
problem
can
also
occur
when
the
UTIL_HEAP_SZ
DB2
configuration
parameter
is
set
too
high.
Solution:
Switch
to
the
DB2
instance
owner,
typically
the
ldapdb2
user
(su
–
ldapdb2)
and
reduce
the
UTIL_HEAP_SZ
DB2
configuration
parameter.
For
example,
enter
the
following:
db2
update
db
config
for
ldapdb2
using
UTIL_HEAP_SZ
5000
Cause
3:
This
problem
can
occur
when
the
DB2
buffer
pool
sizes
are
set
too
high.
Solution:
Switch
to
the
DB2
instance
owner,
typically
theldapdb2
user,
(su
–
ldapdb2)
and
reduce
the
buffer
pool
configuration
parameter.
For
more
information,
see
“Perform
DB2
parameter
tuning”
on
page
12.
©
Copyright
IBM
Corp.
2001,
2003
65
Problem:
the
wrong
number
of
processors
The
/export/home/ldapdb2/sqllib/db2dump/db2diag.log
file
reports
a
message
similar
to
the
following:
SQL8017W
The
number
of
processors
on
this
machine
exceeds
the
defined
entitlement
of
"1"
for
the
product
"DB2
Enterprise
Edition".
The
number
of
processors
on
this
machine
is
"4".
Solution:
Purchase
an
updates
license
and
then
use
db2licm
to
update
the
system
license.
For
example,
enter
db2licm
–l
to
get
the
password,
then
enter
db2licm
–n
DB2UDBEE
4
to
do
the
update.
In
this
example,
the
password
is
DB2UDBEE
and
the
number
of
processors
is
4.
Problem:
LDAP
or
DB2
fails
to
start
LDAP
or
DB2
fails
to
start
and
there
is
no
message
in
the
LDAP
error
log.
It
returns
to
the
command
prompt
when
attempting
to
start
the
IBM
Directory
server.
Cause:
The
DB2
BUFFPAGE
parameter
is
set
too
high
for
the
available
physical
memory
and
paging
space.
Solution:
Decrease
the
buffer
pool
size.
See
“Perform
DB2
parameter
tuning”
on
page
12.
Problem:
LDAP
or
DB2
fails
to
start
after
a
DB2
restore
After
a
DB2
restore,
LDAP
and
DB2
fail
to
start
with
a
message
indicating
that
the
database
needs
to
be
migrated.
Cause:
See
“Perform
DB2
parameter
tuning”
on
page
12
for
reasons
why
this
occurs.
Solution:
The
workaround
is
to
create
a
script
that
continuously
loops
and
sets
the
DB2
BUFFPAGE
parameter
every
five
seconds.
Run
the
script
during
the
restore
process.
Ensure
that
the
buffer
pool
is
defined
with
a
size
of
–1
before
running
the
script.
For
example:
db2
connect
to
ldapdb2
while
[
1
=
1
];do
sleep
5
db2
update
database
configuration
for
ldapdb2
using
BUFFPAGE
16000
done
Problem:
insufficient
size
for
the
maximum
shared
memory
The
SQL1220N
The
database
manager
shared
memory
set
cannot
be
allocated.
message
is
displayed.
Cause:
An
insufficient
size
for
the
shared
memory
maximum
has
been
set.
Solution:
See
“Increase
the
shared
memory
maximum
(shmmax)”
on
page
8.
Problem:
the
user
registry
is
not
available
The
ldapsearch
commands
return
with
Tivoli
Access
Manager
operation
errors
indicating
that
the
registry
is
not
available.
The
ldapsearch
command
returns
with
no
results
when
results
are
expected.
66
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Cause:
DB2
has
been
forcefully
stopped,
using
db2
terminate,
and
possibly
db2stop
and
db2start.
Solution:
Restart
LDAP.
Problem:
no
results
returned
when
results
are
expected
The
ldapsearch
commands
do
not
fail,
but
return
no
results
when
results
are
expected.
Cause:
Authentication
parameters
on
ldapsearch
were
either
not
specified
or
incorrectly
specified.
For
example,
the
–D
and
–w
parameters
were
not
specified.
Solution:
Reissue
the
command
with
the
authentication
parameters
specified,
for
example,
–D
and
–w.
Problem:
the
DB2
runstat
command
fails
The
DB2
runstat
command
fails
and
issues
the
following
message:
SQL2310N
The
utility
could
not
generate
statistics.
Error
"-1024"
was
returned
Cause:
A
DB2
connection
does
not
exist.
Solution:
Enter
the
db2
connect
to
ldapdb2
command
and
try
again.
Problem:
the
server
stops
unexpectedly
An
Tivoli
Access
Manager
server
ends
unexpectedly,
but
leaves
no
message
or
error
log
entry.
Cause:
The
process
ran
out
of
memory,
due
to
lack
of
paging
space
or
system
process
limits.
Solution:
Either
increase
the
system’s
physical
memory,
the
operating
system’s
paging
space,
or
the
system
process
limits
and
try
again.
See
Chapter
5,
“Tuning
process
memory
size
limits,”
on
page
63
for
information
about
increasing
the
system
process
limits.
Problem:
the
DB2
backup
fails
The
DB2
backup
fails
and
issues
this
message:
SQL2009C
There
is
not
enough
memory
available
to
run
the
utility.
Cause:
The
DB2
UTIL_HEAP_SZ
parameter
is
not
set
high
enough
for
the
backup
utility.
Solution:
Increase
the
DB2
UTIL_HEAP_SZ
configuration
parameters
using
the
following
command:
db2
update
database
configuration
for
ldapdb2
using
UTIL_HEAP_SZ
Chapter
6.
Troubleshooting
67
Problem:
the
database
transaction
log
is
full
There
is
an
LDAP
or
DB2
error
message
indicating
that
the
transaction
log
for
the
database
is
full.
Cause:
The
LOGFILSIZ_DB2
parameter
is
set
too
low.
Solution:
Create
the
LOGFILSIZ_DB2
parameter
using
the
following
command:
db2
update
database
configuration
for
ldapdb2
using
LOGFILSIZ
10000
Ensure
that
there
is
enough
file
space
in
the
DB2
instance
owner’s
home
directory.
the
DB2
instance
owner
is
typically
the
ldapdb2
user
68
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Appendix.
Notices
This
information
was
developed
for
products
and
services
offered
in
the
U.S.A.
IBM
may
not
offer
the
products,
services,
or
features
discussed
in
this
document
in
other
countries.
Consult
your
local
IBM®
representative
for
information
on
the
products
and
services
currently
available
in
your
area.
Any
reference
to
an
IBM
product,
program,
or
service
is
not
intended
to
state
or
imply
that
only
that
IBM
product,
program,
or
service
may
be
used.
Any
functionally
equivalent
product,
program,
or
service
that
does
not
infringe
any
IBM
intellectual
property
right
may
be
used
instead.
However,
it
is
the
user’s
responsibility
to
evaluate
and
verify
the
operation
of
any
non-IBM
product,
program,
or
service.
IBM
may
have
patents
or
pending
patent
applications
covering
subject
matter
described
in
this
document.
The
furnishing
of
this
document
does
not
give
you
any
license
to
these
patents.
You
can
send
license
inquiries,
in
writing,
to:
IBM
Director
of
Licensing
IBM
Corporation
North
Castle
Drive
Armonk,
NY
10504-1785
U.S.A.
For
license
inquiries
regarding
double-byte
(DBCS)
information,
contact
the
IBM
Intellectual
Property
Department
in
your
country
or
send
inquiries,
in
writing,
to:
IBM
World
Trade
Asia
Corporation
Licensing
2-31
Roppongi
3-chome,
Minato-ku
Tokyo
106-0032,
Japan
The
following
paragraph
does
not
apply
to
the
United
Kingdom
or
any
other
country
where
such
provisions
are
inconsistent
with
local
law:
INTERNATIONAL
BUSINESS
MACHINES
CORPORATION
PROVIDES
THIS
PUBLICATION
“AS
IS”
WITHOUT
WARRANTY
OF
ANY
KIND,
EITHER
EXPRESS
OR
IMPLIED,
INCLUDING,
BUT
NOT
LIMITED
TO,
THE
IMPLIED
WARRANTIES
OF
NON-INFRINGEMENT,
MERCHANTABILITY
OR
FITNESS
FOR
A
PARTICULAR
PURPOSE.
Some
states
do
not
allow
disclaimer
of
express
or
implied
warranties
in
certain
transactions,
therefore,
this
statement
may
not
apply
to
you.
This
information
could
include
technical
inaccuracies
or
typographical
errors.
Changes
are
periodically
made
to
the
information
herein;
these
changes
will
be
incorporated
in
new
editions
of
the
publication.
IBM
may
make
improvements
and/or
changes
in
the
product(s)
and/or
the
program(s)
described
in
this
publication
at
any
time
without
notice.
Any
references
in
this
information
to
non-IBM
Web
sites
are
provided
for
convenience
only
and
do
not
in
any
manner
serve
as
an
endorsement
of
those
Web
sites.
The
materials
at
those
Web
sites
are
not
part
of
the
materials
for
this
IBM
product
and
use
of
those
Web
sites
is
at
your
own
risk.
IBM
may
use
or
distribute
any
of
the
information
you
supply
in
any
way
it
believes
appropriate
without
incurring
any
obligation
to
you.
©
Copyright
IBM
Corp.
2001,
2003
69
Licensees
of
this
program
who
wish
to
have
information
about
it
for
the
purpose
of
enabling:
(i)
the
exchange
of
information
between
independently
created
programs
and
other
programs
(including
this
one)
and
(ii)
the
mutual
use
of
the
information
which
has
been
exchanged,
should
contact:
IBM
Corporation
2Z4A/101
11400
Burnet
Road
Austin,
TX
78758
U.S.A.
Such
information
may
be
available,
subject
to
appropriate
terms
and
conditions,
including
in
some
cases,
payment
of
a
fee.
The
licensed
program
described
in
this
information
and
all
licensed
material
available
for
it
are
provided
by
IBM
under
terms
of
the
IBM
Customer
Agreement,
IBM
International
Program
License
Agreement,
or
any
equivalent
agreement
between
us.
Any
performance
data
contained
herein
was
determined
in
a
controlled
environment.
Therefore,
the
results
obtained
in
other
operating
environments
may
vary
significantly.
Some
measurements
may
have
been
made
on
development-level
systems
and
there
is
no
guarantee
that
these
measurements
will
be
the
same
on
generally
available
systems.
Furthermore,
some
measurements
may
have
been
estimated
through
extrapolation.
Actual
results
may
vary.
Users
of
this
document
should
verify
the
applicable
data
for
their
specific
environment.
Information
concerning
non-IBM
products
was
obtained
from
the
suppliers
of
those
products,
their
published
announcements
or
other
publicly
available
sources.
IBM
has
not
tested
those
products
and
cannot
confirm
the
accuracy
of
performance,
compatibility
or
any
other
claims
related
to
non-IBM
products.
Questions
on
the
capabilities
of
non-IBM
products
should
be
addressed
to
the
suppliers
of
those
products.
All
statements
regarding
IBM’s
future
direction
or
intent
are
subject
to
change
or
withdrawal
without
notice,
and
represent
goals
and
objectives
only.
This
information
contains
examples
of
data
and
reports
used
in
daily
business
operations.
To
illustrate
them
as
completely
as
possible,
the
examples
include
the
names
of
individuals,
companies,
brands,
and
products.
All
of
these
names
are
fictitious
and
any
similarity
to
the
names
and
addresses
used
by
an
actual
business
enterprise
is
entirely
coincidental.
COPYRIGHT
LICENSE:
This
information
contains
sample
application
programs
in
source
language,
which
illustrate
programming
techniques
on
various
operating
platforms.
You
may
copy,
modify,
and
distribute
these
sample
programs
in
any
form
without
payment
to
IBM,
for
the
purposes
of
developing,
using,
marketing
or
distributing
application
programs
conforming
to
the
application
programming
interface
for
the
operating
platform
for
which
the
sample
programs
are
written.
These
examples
have
not
been
thoroughly
tested
under
all
conditions.
IBM,
therefore,
cannot
guarantee
or
imply
reliability,
serviceability,
or
function
of
these
programs.
You
may
copy,
modify,
and
distribute
these
sample
programs
in
any
form
without
payment
to
IBM
for
the
purposes
of
developing,
using,
marketing,
or
distributing
application
programs
conforming
to
IBM’s
application
programming
interfaces.
70
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
If
you
are
viewing
this
information
softcopy,
the
photographs
and
color
illustrations
may
not
appear.
Trademarks
The
following
terms
are
trademarks
or
registered
trademarks
of
International
Business
Machines
Corporation
in
the
United
States,
other
countries,
or
both:
AIX
DB2
IBM
IBM
logo
Tivoli
Tivoli
logo
Universal
Database
WebSphere
z/OS
zSeries
Lotus
is
a
registered
trademark
of
Lotus
Development
Corporation
and/or
IBM
Corporation.
Domino
is
a
trademark
of
International
Business
Machines
Corporation
and
Lotus
Development
Corporation
in
the
United
States,
other
countries,
or
both.
Microsoft
and
Windows
are
trademarks
of
Microsoft
Corporation
in
the
United
States,
other
countries,
or
both.
Java
and
all
Java-based
trademarks
and
logos
are
trademarks
or
registered
trademarks
of
Sun
Microsystems,
Inc.
in
the
United
States
and
other
countries.
UNIX
is
a
registered
trademark
of
The
Open
Group
in
the
United
States
and
other
countries.
Other
company,
product,
and
service
names
may
be
trademarks
or
service
marks
of
others.
Appendix.
Notices
71
72
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
Index
AACLs
bulk
loading
41
ACLs
not
created
by
the
bulkload
utility,
adding
25
ACLs
to
suffix
objects
20
add_am_to_groups_ldif.sh
script
file
45
add_am_to_testusers_ldif.sh
script
file
42
adding
ACLs
to
suffix
objects
20
adding
the
Tivoli
Access
Manager
schema
to
the
IBM
Directory
server
18
adding
Tivoli
Access
Manager
ACLs
not
created
by
the
bulkload
utility
25
adding
users
and
groups
25
AIXdata
segments
usage
64
LDAP
process
DB2
connections
64
process
data
segment
usage
64
tuning
for
IBM
Tivoli
Access
Manager
and
LDAP
61
AIXTHREAD_MUTEX_DEBUG
61
AIXTHREAD_SCOPE
61
am_tune_ldap.sh
script
file
2
audit
logging
configuration
11
auth-using-compare
stanza
entry
51
Bbacking
updatabase
35
DB2
26,
37
backing
up
the
database
22
bind-dn
stanza
entry
52,
53
buffer
pool
memory
usage
14
bulk
loading
and
ACLs
41
bulkload
temporary
files
4
bulkload
utility
39
disk
space
requirements
40
Ccache
choosing
values
47
group
59
LDAP
46
setting
parameters
47
user
57
cache
resources
usage
48
cache-enabled
stanza
entry
57
change
log
configuration
11
check_indexes.sh
script
file
14,
27
check_ldap_acls.sh
script
file
20
cn=root
52
commandspdadmin
user
list
15
configuration
filesslapd32
and
ibmslapd
15
create
suffix
objects
17
creating
large
number
of
users
39
Ddata
segments,
AIX
64
databasebacking
up
35
database,
backing
up
22
DB2adding
groups
45
adding
transaction
log
parameters
45
backing
up
26
backup
37
instance
owner
12
LDAP
process
connections
64
ldapdb2
user
12
perform
a
reorgchk
15
permanent
attribute
tables
40
permanent
LDAP_ENTRY
table
40
redoing
tuning
parameters
26
restore
37
statistics
tuning
27
temporary
indexes
40
temporary
transaction
logs
40
use
with
LDAP
32
DB2
commandsreorgchk
27
DB2
performance
tuning
tasksbuffer
pool
memory
usage
14
MINCOMMIT
Db2
tuning
14
recycle
the
IBM
Directory
server
17
tune
DB2
parameters
12,
13
db2–tunings.sh
script
file
12,
14
default
policy
data
31
Directory
tablespaces,
LDAP
33
disk
space
requirements
40
display
and
verify
DB2
parameters
13
distributing
the
database
across
multiple
disk
drives
23,
33
do_explain_sql.sh
script
file
49
do_statement_monitoring.sh
script
file
48
Eenvironment
variablesAIXTHREAD_MUTEX_DEBUG
61
AIXTHREAD_SCOPE
61
IRA
environment
variables
57
LD_PRELOAD
56
LDR_CNTRL
10,
63
MALLOCMULTIHEAP
61
MALLOCTYPE
61
SPINLOOPTIME
61
Ffile
systems
and
directories
on
target
disks
34
fixacls_propagate_parents_once.sh
script
file
25,
41
forcing
all
DB2
Connections
to
be
closed
22
©
Copyright
IBM
Corp.
2001,
2003
73
Ggroup
cache
59
groupsadding
a
large
number
of
users
to
43
groups
and
usersadding
25
loading
25
using
group
scripts
together
45
Hheap
allocation,
Solaris
SMP
55
IIBM
Directorypreparing
to
load
users
18
IBM
Directory
performance
tuning
tasksbuffer
pool
memory
usage
14
change
size
limit
for
LDAP
searches
15
display
and
verify
the
current
settings
13
MINCOMMIT
Db2
tuning
14
missing
and
extra
indexes
14
perform
DB2
parameter
tuning
12
recycle
the
IBM
Directory
server
17
start
the
IBM
Directory
server
11
stop
the
IBM
Directory
server
12
tune
the
IDS
configuration
file
15
verify
the
change
log
is
not
configured
11
verify
the
server
audit
logging
is
turned
off
11
IBM
Directory
serverstopping
12,
21
IBM
LDAP
Directory
servertuning
31
ibm-slapdSizeLimit
parameter
15
ignore-suffix
stanza
entry
16,
17
incremental_bulkload.sh
script
file
4,
42
incremental_groups.sh
script
file
45
indexes,
missing
and
extra
14
instance
owner,
DB2
12
IRA
environment
variablesIRA_CACHE_GROUP_MEMBERSHIP
57,
59
IRA_CACHE_USER_VALID_FLAGS
57,
58
IRA_GROUP_CACHE_SIZE
59
IRA_GROUP_EXPIRE_TIME
60
IRA_USER_CACHE_SIZE
57
IRA_USER_EXPIRE_TIME
58,
59
RA_GLOBAL_POLICY_EXPIRE_TIME
60
IRA_CACHE_GROUP_MEMBERSHIP
57,
59
IRA_CACHE_USER_VALID_FLAGS
57,
58
IRA_GLOBAL_POLICY_EXPIRE_TIME
60
IRA_GROUP_CACHE_SIZE
59
IRA_GROUP_EXPIRE_TIME
60
IRA_USER_CACHE_SIZE
57
IRA_USER_EXPIRE_TIME
58,
59
Llarge
number
of
users
39
LD_PRELOAD
56
LDAPbulkload
utility
39
cache
46
Directory
tablespaces
33
monitoring
performance
38
SSL
between
IBM
Tivoli
Access
Manager
and
LDAP
53
Tivoli
Access
Manager’s
use
of
ACLs
31
using
directory
with
Tivoli
Access
Manager
31
verifying
cache
resources
usage
48
with
DB2
32
ldapdb2
user
12
LDR_CNTRL
10,
63
load
balancing
between
LDAP
replicas
53
loading
users
18
location
of
server
configuration
files
52
logging
configuration
11
logs
for
throughput
information
60
MMALLOCMULTIHEAP
61
MALLOCTYPE
61
max-search-size
stanza
entry
15,
46
memory
size
64
memory
size
limits
of
the
tuning
processAIX-specific
size
limits
63
increasing
process
memory
size
limits
63
memory
usage
64
MINCOMMIT
DB2
tuning
14
missing
and
extra
indexes
14,
27
mk_am_min_unconfig_dom_ldif.sh
script
file
19
mk_ldap_group_ldif_stdin.sh
script
file
44
mk_test_users_ldif.sh
script
file
41
multiple
disk
drives,
distributing
the
database
23,
33
Ooverview
of
scriptsadding
large
numbers
of
users
to
a
group
43
Pparameters
ibm-slapdSizeLimit
15
pdadmin
user
list
command
15
perfagent.tools
64
performanceand
SMP
systems,
update
38
monitoring
LDAP
38
performance
of
the
registry,
testing
28
permanent
attribute
tables
40
permanent
LDAP_ENTRY
table
40
planning
to
expand
to
a
large
registry
21
plug-ins
for
Web
serversauth-using-compare
51
LDAP
admin
account
(cn=root)
52
load
balancing
between
LDAP
replicas
53
policy-cache-minimum-size
52
Plug-ins
for
Web
Serversuser-and-group-in-same-suffix
51
74
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
policy-cache-minimum-size
stanza
entry
52
proc_stmt_mon_output.awk
script
file
49
process
segments
64
Rrecheck
for
missing
and
extra
indexes
27
recycle
the
IBM
Directory
server
17
redirected
restore
of
the
database
35
registry
performance,
testing
28
related
publications
x
reorgchk
DB2
command
27
restart
the
IBM
Directory
server
11
restoring
DB2
37
Sschema,
Tivoli
Access
Manager
18
script
filesadd_am_to_groups_ldif.sh
45
add_am_to_testusers_ldif.sh
42
am_tune_ldap.sh
2
check_indexes.sh
14,
27
check_ldap_acls.sh
20
db2–tunings.sh
12,
14
do_explain_sql.sh
49
do_statement_monitoring.sh
48
fixacls_propagate_parents_once.sh
25,
41
incremental_bulkload.sh
4,
42
incremental_groups.sh
45
mk_am_min_unconfig_dom_ldif.sh
19
mk_ldap_group_ldif_stdin.sh
44
mk_test_users_ldif.sh
41
proc_stmt_mon_output.awk
49
set_containers.sh
36
sysstat_tune.sh
27
test_registry_perf.sh
28
wwwlog_tput_calc.sh
60
scriptsoverview
of
bulk-loading
scripts
41
using
the
group
scripts
together
45
segment
usage,
process
data
64
server
audit
logging
configuration
11
server
configuration
fileslocation
52
set_containers.sh
script
file
36
shared
memory
64
size
limit
for
LDAP
searches
15
slapd32
and
ibmslapd
configuration
files
15
Solarisoptimal
heap
allocation
on
SMP
systems
55
SPINLOOPTIME
61
SSLmemory
use
53
session
cache
53
SSL
between
IBM
Tivoli
Access
Manager
and
LDAP
53
user
credential
cache
53
stanza
entriesauth-using-compare
51
bind-dn
52,
53
stanza
entries
(continued)cache-enabled
57
ignore-suffix
16,
17
max-search-size
15,
46
policy-cache-minimum-size
52
user-and-group-in-same-suffix
51
worker-threads
54
starting
the
IBM
Directory
server
28
statistics
tuning,
DB2
27
stop
the
IBM
Directory
server
12,
21
suffix
objects
17,
20
sysstat_tune.sh
script
file
27
Ttemporary
files,
bulkload
4
temporary
indexes
40
temporary
transaction
logs
40
test_registry_perf.sh
script
file
28
testing
the
performance
of
the
registry
28
Tivoli
Access
Manager
stanza
entriesSee
stanza
entries
transaction
log
parameters
45
troubleshooting
65
tune
DB2
parameters
12
tuningAIX
61
AIX-specific
size
limits
63
memory
size
limits
63
Tivoli
Access
Manager
WebSEAL
51
tuning
script
filesSee
script
files
tuning
when
IBM
Directory
server
is
running
14
tuning,
IBM
LDAP
Directory
server
31
UURLs
IBM
LDAP
use
of
DB2
32
usage,
data
segment
64
user
cache
57
user
data
31
user-and-group-in-same-suffix
stanza
entry
51
usersadding
a
large
number
to
a
group
43
creating
a
large
number
of
39
users
and
groupsadding
25
loading
25
using
group
scripts
together
45
Wwarnings
buffer
pool
memory
usage
14
MINCOMMIT
Db2
tuning
14
tuning
when
IDS
is
running
14
WebSEALlogs
for
throughput
information
60
user-and-group-in-same-suffix
51
Index
75
WebSEAL
serverauth-using-compare
51
LDAP
admin
account
(cn=root)
52
load
balancing
between
LDAP
replicas
53
policy-cache-minimum-size
52
worker-threads
stanza
entry
54
wwwlog_tput_calc.sh
script
file
60
76
IBM
Tivoli
Access
Manager
for
e-business:
Performance
Tuning
Guide
����
Printed
in
USA
SC32-1351-00
![BEA WebLogic Server XΓU - IBMpublib.boulder.ibm.com/tividd/td/ITAME/SC32-1366-01/zh_TW/PDF/am51_wls_guide.pdfw∩ ® IBM ®Tivoli Access Manager for BEA WebLogic Server®]HU Tivoli](https://img.pdfslide.net/doc/110x75/5e87e582a374bd0c512bcb77/bea-weblogic-server-xu-wa-ibm-tivoli-access-manager-for-bea-weblogic.jpg)
