MFILES is related to the OS per process open file limit (documented in the uvconfig file). The specific name of this value varies for different OSes. It looks like the default limit for AIX is 2000 (listed as "nofiles"). This was the absolute maximum until around 4.3.1. An individual user can see their setting via the "ulimit -a" command.
Some time ago we had a program that started getting slower over time. Turns out the original programmer had made liberal use of dynamic arrays rather than dimensioned arrays, and these become horribly inefficient when they become large. HTH Drew -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dan Fitzgerald Sent: Thursday, March 05, 2009 2:47 AM To: [email protected] Subject: RE: [U2] Performance monitoring Get a count of the number of read locks at a busy time. If it's more than RLTABSZ times GSEMNUM, you'll want to increase gsemnum. I would avoid increasing GLTABSZ and RLTABSZ by much; the lock table is a hashed table, and just like uv files, "broad and shallow" yields better performance/less contention. Also look at MFILES; in the uv account, do a PORT.STATUS with the MFILE.HIST option to see how things are going. Closing & reopening files is very expensive. I've asked a few people if there's an upper limit, and while nobody will commit to an answer (feel free, anyone), there appears to be no penalty to making it too big. I don't recall what the scratch buffer pool does, and the documentation is sparse. SELBUF is interesting, if you're doing a lot of selects. The default is 4, in units of 1K. So, if you do a select, it starts accumulating a list of id's in RAM until the size of that list reaches 4K. At that point, it creates a file in UVTEMP, and you're going to disk. I can't see much reason not to increase this to 1024, so select lists up to 1Mb are created in RAM. These may help some, but unless MFILES is massively underconfigured and you're using some absurd amount of cpu to just close & re-open files, I'm inclined to think that the symptoms you mention indicate that AIX VMM tuning will give you more bang for the buck. I'd be especially looking at how VMM is treating computational vs file cache; with the amount of data you churn through in a night, you'll want to be sure to heavily favor computational memory pages. How much RAM do you have? -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ericro Sent: Wednesday, March 04, 2009 7:31 PM To: [email protected] Subject: RE: [U2] Performance monitoring Sounds like a good start. I'm also wondering how the Universe config is playing into things. There are some parameters we've never changed, i.e. the scratch buffer stuff, and others we have such as the lock parameters. We haven't changed any of these in some time, but I'm wondering if we're hitting some thresholds. How would I know? Dan Fitzgerald wrote: > > Of course, there are a lot of things to look at. > > I think what you're looking for is svmon -U username. This will show you > the > user's memory map. Svmon with no arguments shows you overall stats; one > thing to look for there is that there should be no pinned memory for UV; > Oracle needs pinned memory, it's wasted with (and unusable to) UV. > > Further, there are three AIX commands that will display environment > variables (as of 5.2) are vmo, ioo, and schedo. Vmo -l, for example, will > give you virtual memory settings. These are stored in > /etc/tunables/lastboot, but - similar to looking at uvconfig rather than > analyze.shm - what's in lastboot may not be the current values. > > Now, one of the first things to look at is in vmstat -v. This is output in > nmon, if you're running that daily (recommended); if not, you can run it > at > the command line. Look for these lines: > > vmstat -v 0 pending disk I/Os blocked with no pbuf > vmstat -v 0 paging space I/Os blocked with no psbuf > vmstat -v 9877 filesystem I/Os blocked with no fsbuf > vmstat -v 0 client filesystem I/Os blocked with no fsbuf > vmstat -v 0 external pager filesystem I/Os blocked with no > fsbuf > > If, over time, these are growing, you'll need to increase the number of > the > various file buffers. If you see growth over, say, an hour, you'll want to > increase significantly. > > > > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of ericro > Sent: Wednesday, March 04, 2009 1:59 PM > To: [email protected] > Subject: [U2] Performance monitoring > > We run an IBM P570 with 12 processors running Universe 10.2.4, average of > 400 > users against at EMC DMX4500 disk array. 20 file systems with each about > 45gb, 60-80% utilized striped across 94 disks. > > We do tons of batch processing at night and our rate of data change is > about > 175GB an hour at night. We're running into some performance issues, jobs > taking much longer, keyboard response slow, editing single records taking > a > long time, etc. and want to really dive in to see what's going on. We've > looked at file sizing and have done a fair amount of resizing, but to > little > avail. > > Does anyone have any tools, or know of any tools, similar to Oracle, that > can really give me insight into what's happening with a given user session > at any time? I know I can do port.status and find the address in the code > and see what's being executed at that time, but I want something more that > will show memory utilization and other stats like that. > > Any help would be appreciated. > -- > View this message in context: > http://www.nabble.com/Performance-monitoring-tp22336819p22336819.html > Sent from the U2 - Users mailing list archive at Nabble.com. > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ > > -- View this message in context: http://www.nabble.com/Performance-monitoring-tp22336819p22342848.html Sent from the U2 - Users mailing list archive at Nabble.com. ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
