Re: Performance Problems

["Sean O'Malley" <omalleys@eclipse.cl.msu.edu>]

*cheers* i finally got this to work. I used slapadd and slapindex instead
of ldapadd and used better indexing. It still took about 9 hours on a
p3/850 with only 256M of ram, but it is pretty spunky and im not getting
slapd hanging errors. 

A finger of someone through the ldap-nsswitch crap is:
real	0m0.030s
user	0m0.010s
sys	0m0.000s

the second time
 
real	0m0.007s
user	0m0.000s
sys	0m0.000s

but im also running nscd so i assume that picks up some of the slack too. 


--------------------------------------
  Sean O'Malley, Information Technologist
  Michigan State University
-------------------------------------

On Tue, 12 Nov 2002, Sean O'Malley wrote:

> Am I doing something wrong? 
> I loaded all 370K users into this database. (tuning the cache size to
> actual memory size helps) (it only took 10 hours this time.) and i stopped
> it after it was done to turn off the dbnosync option.
> 
> I restarted it and a little over a half an hour after I restarted it. I'm
> getting 34 slapd processes.
> 
> [root@cc-pubafs-14 etc]# uptime
>  10:58am  up 7 days, 23:57,  4 users,  load average: 10.00, 10.03, 9.59
> [root@cc-pubafs-14 etc]# free
>              total       used       free     shared    buffers     cached
> Mem:        255656     252172       3484          0       1324      14632
> -/+ buffers/cache:     236216      19440
> Swap:      3051056     319460    2731596
> 
> The swap that is being used keeps growing very slowly. 
> 
> Was I supposed to run db-archive so the database wouldnt be 2x checking
> all 2.4G of logs??
> 
> I ran an strace on some of these processes. 
> 
> im getting a lot of:
> sched_yield()                           = 0
> sched_yield()                           = 0
> 
> sched_yield()                           = 0
> time(NULL)                              = 1037117416
> sched_yield()                           = 0
> time(NULL)                              = 1037117416
> (with an occasional pread on some of them.)
> like:
> pread(7, "\353\0\0\0\335\355\235\0\1\0\0\0\0\0\0\0\0\0\0\0\37\0\24"...,
> 16384, 16384) = 16384
> 
> I also caught a few of these interlaced there as well:
> 
> time(NULL)                              = 1037117685
> kill(16324, SIGRTMIN)                   = 0
> sched_yield()                           = 0
> 
> More processes revealed actually this is good:
> [root@cc-pubafs-14 root]# strace -p16320
> getppid()                               = 16317
> poll([{fd=10, events=POLLIN}], 1, 2000) = 0
> getppid()                               = 16317
> poll([{fd=10, events=POLLIN}], 1, 2000) = 0
> 
> [root@cc-pubafs-14 root]# strace -p16317
> --- SIGSTOP (Stopped (signal)) ---
> 
> 
> 
> On Mon, 11 Nov 2002, Sean O'Malley wrote:
> 
> > The tuning makes it a lot faster but it is a ram hungry database.  370k
> > users from a password file used a bit over 1 gig of ram.  It wasnt indexed
> > right and this box only has 256M of real ram, but it took 26 seconds to
> > finger a user after i loaded it. 
> > 
> > Im worried about what RL performance is going to be like.. and if I
> > shouldnt be changing backends.. 
> > 
> > 
> > 
> > 
> > 
> > On Mon, 11 Nov 2002, John Morrissey wrote:
> > 
> > > On Mon, Nov 11, 2002 at 05:01:18PM -0800, Howard Chu wrote:
> > > % YES. The back-bdb "dbnosync" option is exactly the same as the BDB
> > > % DB_TXN_NOSYNC option.
> > > 
> > > You're right, sorry. Must've confused it with something else.
> > > 
> > > john
> > > 
> > 
>