Thanks to everyone for the performance suggestions...I will report to
the board as soon as we resolve it.

Kevin



Kevin D. Vezertzis
Project Manager
Cypress Business Solutions, LLC.
678.494.9353  ext. 6576      Fax  678.494.9354
 
[EMAIL PROTECTED]
Visit us at www.cypressesolutions.com
 
 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Stevenson, Charles
Sent: Friday, April 09, 2004 4:24 PM
To: U2 Users Discussion List
Subject: RE: Performance

Kevin,
When you finally get this solved,  let us know what the answer was.  I
am sure all responders would be interested.

re. /tmp: I've seen marginal but not incredible inprovement moving
UVTEMP onto our EMC storage rather than on the system's local disk
(/tmp)

re. file sizing: since you are porting from D3, I assume yoou made
everything type 18, which is the standard Pick hashing algorithm?  That
ought to behave about the same as it did on D3.   How about Separation?
Does D3 have that concept?  I don't think Jeff mentioned it.  For most
files you want to set separation such that you get integer number of
groups for each OS disk read.  If a sigle disk read grabs 8K, then
separation 4 (512*4= 2K/group) means filescans will ask for a group, the
OS will read in 4 groups, and the next 3 times the process asks for the
next group, it's probably still sitting in memory.  So if the OS does
read 8K at a time, separations of 1,2,4,8,16,12 make sense, depending on
the nature of the records.  4 is typical.

re. locks:  I notice the lock table is pretty small, and there are a
lots of 'CLR.OM.LOCK" proceses.  Is this one of those PICK aps where
people developed their own record locking scheme because they didn't
trust PICK's record lock handling?  If so,  maybe that is a source of
ineffeciency.  It's not clear how that would manifest itself with
paging, though.

What about loading programs into shared memory?  Do you have an
absolutely huge program that many users use?  By default they each load
their own copy of the object file into their private memory.  But you
can change that so only one copy is loaded.  The same with small utility
routines that get called by everyone throughout the day.  Load them once
in shared memory,  then all users will run off that copy.   Again, we're
talking incremental, not incredible, performance improvements.

I'm grasping here.  I'm sure IBM's Hdwr, AIX, & U2 support has gone
through all this already.  You will post the answer once you know it,
won't you?
 
cds
-- 
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users
-- 
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users

Reply via email to