Re: Performance Problems

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

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
> > 
>