directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Bash script [was Re: Various questions]
Date Tue, 06 Jun 2006 13:48:55 GMT
Emmanuel Lecharny wrote:

> Thanks a lot Quanah !

Yes thanks.  Just as a heads up though you might want to file a JIRA
issue and attach a patch next time. 

This way we can definately remember to add it to the next release if you
schedule the fix for it when creating the JIRA.   Sometimes emails go by
and we may miss something.

Alex

>
> We will modify the scripts accordingly to your proposal in the next RC.
>
> Have a good day.
>
> Emmanuel
>
> On 6/6/06, Quanah Gibson-Mount <quanah@stanford.edu> wrote:
>
>>
>>
>> --On Tuesday, June 06, 2006 1:15 AM +0200 Emmanuel Lecharny
>> <elecharny@gmail.com> wrote:
>> >> Good call on the time, it was 54 minutes via ldapadd. :)
>> >>
>> >> I gave it 2GB of memory to play with, that may have been overkill,
>> but
>> >> it worked.
>> >
>> > Any idea about the real memory used ? (jconsole) But I don't want
>> to push
>> > you on this, don't loose 54' again :)
>> >
>> > What scared me a lot is that if we need to push ADS to the limit, I
>> know
>> > a company which had 70 millions entries in its ldap server. So if
>> it goes
>> > linear (very unlikely, and if it goes, I guess that their ise
>> something
>> > wrong in the B-tree impl :), that would mean 12 days of processing on
>> > ADS. Oh My !
>>
>> Yeah, in my work for Symas, I've worked with companies who use in
>> excess of
>> 100 million entry databases.  Scaling loads really becomes a factor,
>> which
>> is why I was curious about the offline loading capabilities.  It led
>> Symas
>> to work on ways to optimize the bulk imports so that they are a lot more
>> efficient that normal ldapadd (contributed back into OL of course).
>>
>> > btw, we are currently trying to close a RC4, as I stated recently
>> in one
>> > of my previous post, so don't spend too much time playing with RC3,
>> it's
>> > really not usable. Just enjoy the ease of installation it offers,
>> thanks
>> > to Alex work.
>>
>>
>> Sure thing, the install was quite easy.
>>
>> I made a change to the startup init script that may be useful in
>> adding to
>> the release:
>>
>> -bash-3.00$ diff -u /usr/local/apacheds-1.0-RC3/bin/server.init apacheds
>> --- /usr/local/apacheds-1.0-RC3/bin/server.init Sun Jun  4 20:38:28 2006
>> +++ apacheds    Mon Jun  5 16:14:20 2006
>> @@ -126,6 +126,8 @@
>>  TMP_DIR=$SERVER_HOME/var/tmp
>>  PID_FILE=$SERVER_HOME/var/run/server.pid
>>
>> +MEM_OPS="-Xms256m -Xmx2048m"
>> +
>>  cd $SERVER_HOME
>>
>>  case "$1" in
>> @@ -141,6 +143,7 @@
>>      -user $APACHEDS_USER \
>>      -home $JAVA_HOME \
>>      -Djava.io.tmpdir=$TMP_DIR \
>> +    $MEM_OPS \
>>      -Dlog4j.configuration=file://$SERVER_HOME/conf/log4j.properties\
>>      -pidfile $PID_FILE \
>>      -outfile $SERVER_HOME/var/log/apacheds-stdout.log \
>>
>>
>> It makes it a lot easier to easily control the memory options.
>>
>>
>> > 1Am, CEST, time to dream about the fastest Ldap server on earth...
>> (may
>> > be OpenLdap for this night :)
>>
>>
>> Have a goodnights sleep.  I look forward to benchmarking 1.0RC4.
>>
>>
>> --Quanah
>>
>> -- 
>> Quanah Gibson-Mount
>> Principal Software Developer
>> ITS/Shared Application Services
>> Stanford University
>> GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
>>
>
>


Mime
View raw message