Conference turris::digital_unix

Hi

 You might try running sys_check so we can see more
tuning parameters...

  http://www-unix.zk3.dec.com/tuning/tools/sys_check/sys_check.html

>InterMail from Software.com has been ported from Sun to DU 4.0b.  Load 
>testing is showing that the software runs four times slower on DU.
>This is a 4100 with 4 processors, 1 GB RAM, dual HSZ40's, 50 GB storage, 
.....

Cool machine.

>InterMail appears to be spawning around 50 processes some which are writing 
>~7K byte files to disk.

Just a guess... I suspect you are using Advfs. Advfs seems to be
slightly slower than ufs for small i/o. Is i/o a problem in
the setup ?

>Thanks.
>Pat Bryant
>Software Partners Engineering

I wonder if you can keep me update on the porting process ?
I have a potential customer here that is waiting to try 
InterMail.

Thanks.

Does the Sun machine also experience a tremendous amount of
page ins?  Could it be that some data that ought to be BSS
is actually in the DATA portion of the image, so that it
needs to be read off disk instead of created from zeroed
pages?  Or could it be that some data that ought to be shared
(RDATA) is actually non-shared (DATA)?  Does the application
carefully organize things for SPARC's page size (4KB?) and
need to redo it for Alpha's (8KB)?

Can we assume the CPU's are nearly idle?

Re:  .2
� Just a guess... I suspect you are using Advfs. Advfs seems to be
� slightly slower than ufs for small i/o. Is i/o a problem in
� the setup ?

Yes, they do use ADVfs.  Suspecting that ADVfs would have relatively high
overhead for file system functions, I suggested that they try ufs.  They
were reluctant to make this change unless they had a high level of confidence
that it would help (gobs of RZ29s on two HSC40s).  In their tests, the disk
activity can be characterized as write once, read never (WORN :-) ).  That
is, they are basically just storing gazillions of MAIL messages to disk.

One individual here suggested that they use open/mmap/close rather than
open/write/close in order to eliminate a buffer copy -- does that make sense?


Re:  .3
� Can we assume the CPU's are nearly idle?

They said that CPU utilization swings back and forth between ~15% and ~85%.

The low CPU usage levels coincide with high paging levels.

								-- Chuck Newman

When page in activity is high, CPU utilization is low and vice versa.
I'm looking for something blantingly wrong here.  If switching to UFS is only
going to give a slight performance benefit, then that's not enough.

I'll gather information via sys_check and get some information about the Sun
machine as well.

This identical performance issue is occuring on a machine that is running
Software.com's older product, Post.office, only after the system was upgraded to
4.0x.  That machine is also running Advfs.  I don't see any reported performance
problems running Advfs on 4.0.  Maybe it makes sense to remove it from the
picture?

Hi

 I would gather the data...advfs does not cause the paging described.

I think we are looking for another problem...some sys_check output would
let us check the system parameters...you need to findout what the
application is trying to do in parallel.

Don't mess with advfs yet.

Please ensure you have installed latest OS patches, and hardware firmware is
up to rev also.

regards

Eric

Hi

How about a URL?

http://fluid.mro.dec.com/www-spe/www-mroctr/pb/swcom.html

Your sys_c?.html files contain some strange (MIME?) characters (=3D and the 
sort). 

Make sure you place clean HTML files !!

Regards, 

Arnold

    Pat,
    any chance that Solrais is using threaded smtp version. It's just a
    guess, but I would think that they are all waiting on a select. 
    check for voluntary and involuntary context switches of this 
    processes (nivcsw nvcws) and at the faults (majflt, minflt,pagein)
    you can also look directly at the structure by using dbx -k /vmunix,
    assign to pid and look at uu_tru structure via 
    p *thread->stack->uthread->np_uthread (per thread) and 
    p *thread->stack->uthread->utask (per task, look for uu_[?]ru)
    
    an easy way to check for vnode backuped data (read, shared) as Web
    mentioned is to switch to eager swap mode. anonymous backed memory
    (malloc, stack, data) gets saved in the swap area, but as you've got 
    no real pageout, i would guess the machine gets busy due to different 
    wakeups of the smtp proc's.
    
    if it's not due to the previous, and it's due to disk I/O, I would
    increase the ubcmaxpercent.
    
    Pit 

    oops, sorry sent to soon,
    also look that the socket and network parameters are sized ok,
    there are some tuning papers around (a couple reagrding webserver,
    but the underlying protocols are the same, and explained in quite 
    detail)
    
    Pit