ADAM Time Limit Exceeded

We have two ADAM instances (Windows 2003 sp2) that contain three
object classes; each has a large number of records (3,000,000+,
3,000,000+ and 2,000,000+). One instance is a replica of the other.
Each night we sync each object class to a different database table.
We extract all of the records from the directory (1000 at a time)
until all of the records are extracted and compare them to the
appropriate database record. There is a separate process that handles
each extract. Each one starts at the same time. A round robin
approach splits the processes so that all three are not hitting the
same ADAM instance. Each ADAM instance was running on a two processor
server with 3 GB of RAM.

This process used to work fine, even though it took a while, until the
ADAM directories were moved to virtual machines created by VMWare.
After the move the extraction processes started receiving COMException
(0x80072022). Each virtual machine has 1 processor. Each machine
started with 3 gb of RAM but we noticed that dsmain.exe was using over
2.5 gb. We increased the RAM to 4 gb and dsmain.exe is now using over
3.5 gb. The current directory uses almost 24 gb of storage. This
does not appear to be a processor issue based on the CPU usage.

How much RAM should we have? Is there a way to limit the amount of
RAM dsmain.exe uses? Is there something about having ADAM instances
on a virtual machine that we need to know about? Would adding an
extra process help?

Hi,

what (LDAP) query do you use to do the sync? A poorly indexed could result
in the
entire DIT being pulled into RAM for each query albeit that you will be
returning
all objects eventually as a result of this sync. Is it really object classes
or organizational
units that you are sync'ing?

Ideally these days you would want enough RAM
on the server to cache the entire DIT but that needs 64bit OS. Depending
on the form of query you are running you can hit DS timeout errors which
have
limits set in policy. dsamain will take as much memory as it can get but
will
yield memory as required by other OS functions.

Lee Flight

"drm" <don.mai@westernsouthernlife.com> wrote in message
news:c924fdd1-8b37-424a-9fe4-28529e2eecab@x12g2000yqx.googlegroups.com...
> We have two ADAM instances (Windows 2003 sp2) that contain three
> object classes; each has a large number of records (3,000,000+,
> 3,000,000+ and 2,000,000+). One instance is a replica of the other.
> Each night we sync each object class to a different database table.
> We extract all of the records from the directory (1000 at a time)
> until all of the records are extracted and compare them to the
> appropriate database record. There is a separate process that handles
> each extract. Each one starts at the same time. A round robin
> approach splits the processes so that all three are not hitting the
> same ADAM instance. Each ADAM instance was running on a two processor
> server with 3 GB of RAM.
>
> This process used to work fine, even though it took a while, until the
> ADAM directories were moved to virtual machines created by VMWare.
> After the move the extraction processes started receiving COMException
> (0x80072022). Each virtual machine has 1 processor. Each machine
> started with 3 gb of RAM but we noticed that dsmain.exe was using over
> 2.5 gb. We increased the RAM to 4 gb and dsmain.exe is now using over
> 3.5 gb. The current directory uses almost 24 gb of storage. This
> does not appear to be a processor issue based on the CPU usage.
>
> How much RAM should we have? Is there a way to limit the amount of
> RAM dsmain.exe uses? Is there something about having ADAM instances
> on a virtual machine that we need to know about? Would adding an
> extra process help?

On Mar 17, 7:36*am, "Lee Flight" <l...@le.ac.uk-nospam> wrote:
> Hi,
>
> what (LDAP) query do you use to do the sync? A poorly indexed could result
> in the
> entire DIT being pulled into RAM for each query albeit that you will be
> returning
> all objects eventually as a result of this sync. Is it really object classes
> or organizational
> units that you are sync'ing?
>
> Ideally these days you would want enough RAM
> on the server to cache the entire DIT but that needs 64bit OS. Depending
> on the form of query you are running you can hit DS timeout errors which
> have
> limits set in policy. dsamain will take as much memory as it can get but
> will
> yield memory as required by other OS functions.
>
> Lee Flight
>
> "drm" <don....@westernsouthernlife.com> wrote in message
>
> news:c924fdd1-8b37-424a-9fe4-28529e2eecab@x12g2000yqx.googlegroups.com...
>
> > We have two ADAM instances (Windows 2003 sp2) that contain three
> > object classes; each has a large number of records (3,000,000+,
> > 3,000,000+ and 2,000,000+). *One instance is a replica of the other.
> > Each night we sync each object class to a different database table.
> > We extract all of the records from the directory (1000 at a time)
> > until all of the records are extracted and compare them to the
> > appropriate database record. *There is a separate process that handles
> > each extract. *Each one starts at the same time. *A round robin
> > approach splits the processes so that all three are not hitting the
> > same ADAM instance. *Each ADAM instance was running on a two processor
> > server with 3 GB of RAM.
>
> > This process used to work fine, even though it took a while, until the
> > ADAM directories were moved to virtual machines created by VMWare.
> > After the move the extraction processes started receiving COMException
> > (0x80072022). *Each virtual machine has 1 processor. *Each machine
> > started with 3 gb of RAM but we noticed that dsmain.exe was using over
> > 2.5 gb. *We increased the RAM to 4 gb and dsmain.exe is now using over
> > 3.5 gb. *The current directory uses almost 24 gb of storage. *This
> > does not appear to be a processor issue based on the CPU usage.
>
> > How much RAM should we have? *Is there a way to limit the amount of
> > RAM dsmain.exe uses? *Is there something about having ADAM instances
> > on a virtual machine that we need to know about? *Would adding an
> > extra process help?


We assign the cn of each entry based on a running count. The first
query is (&(cn>=A000000001)(cn<=A000001000)), the next query is
(&(cn>=A000001001)(cn<=A000002000)), etc.

Each object class is under its own ou ex. objectClass = wsfgAccount;
ou = OU=ACCOUNTS,OU=WSFG,DC=COM.

Hi,
sorry for the delay I was trying so testing on this, I found that query of
the form you have below
was fairly responsive albeit using a directory of just 500k users. Have you
tried profiling the query?
If not you could try this using ldp.exe [1] or adfind [2] e.g.

adfind -b OU=ACCOUNTS,OU=WSFG,DC=COM -f
"(&(cn>=A000000001)(cn<=A000001000))"
-h adamserver:adamport -stats+only

You will need to be an ADAM administrator to use the stats control.

As cn is indexed I would expect this to work in timely fashion.

Let's us know what you find.
Thanks
Lee Flight

[1] http://robbieallen.com/downloads/Recipe15-9.htm
[2] http://www.joeware.net/freetools/tools/adfind/index.htm

"drm" <don.mai@westernsouthernlife.com> wrote in message
news:4c67ed07-364e-484c-a404-593bf62de048@q16g2000yqq.googlegroups.com...
> We assign the cn of each entry based on a running count. The first
> query is (&(cn>=A000000001)(cn<=A000001000)), the next query is
> (&(cn>=A000001001)(cn<=A000002000)), etc.
>
> Each object class is under its own ou ex. objectClass = wsfgAccount;
> ou = OU=ACCOUNTS,OU=WSFG,DC=COM.

On Mar 19, 6:54*pm, "Lee Flight" <l...@le.ac.uk-nospam> wrote:
> Hi,
> sorry for the delay I was trying so testing on this, I found that query of
> the form you have below
> was fairly responsive albeit using a directory of just 500k users. Have you
> tried profiling the query?
> If not you could try this using ldp.exe [1] or adfind [2] e.g.
>
> adfind -b OU=ACCOUNTS,OU=WSFG,DC=COM -f
> "(&(cn>=A000000001)(cn<=A000001000))"
> -h adamserver:adamport -stats+only
>
> You will need to be an ADAM administrator to use the stats control.
>
> As cn is indexed I would expect this to work in timely fashion.
>
> Let's us know what you find.
> Thanks
> Lee Flight
>
> [1]http://robbieallen.com/downloads/Recipe15-9.htm
> [2]http://www.joeware.net/freetools/tools/adfind/index.htm
>
> "drm" <don....@westernsouthernlife.com> wrote in message
>
> news:4c67ed07-364e-484c-a404-593bf62de048@q16g2000yqq.googlegroups.com...
>
> > We assign the cn of each entry based on a running count. *The first
> > query is (&(cn>=A000000001)(cn<=A000001000)), the next query is
> > (&(cn>=A000001001)(cn<=A000002000)), etc.
>
> > Each object class is under its own ou ex. objectClass = wsfgAccount;
> > ou = OU=ACCOUNTS,OU=WSFG,DC=COM.

This problem was not ADAM related. It was an issue with the VM/SAN.
Someone on our server management team made some changes, what I do not
know, and the problem was resolved.

Thanks for following up.

Lee Flight

"drm" <don.mai@westernsouthernlife.com> wrote in message
news:7fa1b409-2b99-4949-ba05-2391f0c0a54e@u34g2000yqu.googlegroups.com...
On Mar 19, 6:54 pm, "Lee Flight" <l...@le.ac.uk-nospam> wrote:
> Hi,
> sorry for the delay I was trying so testing on this, I found that query of
> the form you have below
> was fairly responsive albeit using a directory of just 500k users. Have
> you
> tried profiling the query?
> If not you could try this using ldp.exe [1] or adfind [2] e.g.
>
> adfind -b OU=ACCOUNTS,OU=WSFG,DC=COM -f
> "(&(cn>=A000000001)(cn<=A000001000))"
> -h adamserver:adamport -stats+only
>
> You will need to be an ADAM administrator to use the stats control.
>
> As cn is indexed I would expect this to work in timely fashion.
>
> Let's us know what you find.
> Thanks
> Lee Flight
>
> [1]http://robbieallen.com/downloads/Recipe15-9.htm
> [2]http://www.joeware.net/freetools/tools/adfind/index.htm
>
> "drm" <don....@westernsouthernlife.com> wrote in message
>
> news:4c67ed07-364e-484c-a404-593bf62de048@q16g2000yqq.googlegroups.com...
>
> > We assign the cn of each entry based on a running count. The first
> > query is (&(cn>=A000000001)(cn<=A000001000)), the next query is
> > (&(cn>=A000001001)(cn<=A000002000)), etc.
>
> > Each object class is under its own ou ex. objectClass = wsfgAccount;
> > ou = OU=ACCOUNTS,OU=WSFG,DC=COM.

This problem was not ADAM related. It was an issue with the VM/SAN.
Someone on our server management team made some changes, what I do not
know, and the problem was resolved.