RE: HP-UX 10.20 , Informix 7.30 - advice needed

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEA390.33834894 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****** Message from InterScan E-Mail VirusWall NT ****** ** No virus found in attached file onconfig.tmp Mail Scanned For Virus At ITLInfosys ***************** End of message *************** ------_=_NextPart_000_01BEA390.33834894 Content-Type: text/plain Hi, See reply below. Also got a lot of replies which said to get more memory. Going to try that but may take some time. Thanks a lot to all who replied. Thanks. Regards Vasudev > -----Original Message----- > From: Eric_Melillo@agsea.com [SMTP:Eric_Melillo@agsea.com] > Sent: Wednesday, May 19, 1999 6:04 PM > To: RVASUDEV > Cc: 'informix-list@iiug.org' > Subject: Re: HP-UX 10.20 , Informix 7.30 - advice needed > > > If I didn't know that this was from the newsgroup -- I would swear you > were > one of my users. [RVASUDEV] Good one :) ... but see next comment. > Can we have some specifics... "It works fine for a while, then just sits there for while", "cpu is pegged all the time", etc. Your statement, "We have an ap, using all the above, which is slow." gives us nothing. > [RVASUDEV] The reason I didn't post specifics initially is that it would become very long - thought it might put people off from reading it. Also, the query was partly generic in nature, i.e. about tuning HP-UX / Informix as a whole, so that all apps benefit in performance. Is this another boner ? I'm not an expert on performance issues; do know that tuning needed will be different for OLTP / batch / DSS type of apps. This is more of a batch type of app, but with some online features (has to keep pace with another app which gives it input - see Details below.) Different efforts are under way to improve perf. at app design level, code level, etc. My query was more aimed at getting help on general kernel / onconfig tuning, based on our machine config of RAM, etc. > Is it a specific portion of the app? [ see Big Picture and Details below > ] > the whole thing? Was it written in house or off the shelf? do you have > indexes?, [ yes ] have you run update > statistics? [ yes ] this group could go on-and-on... [RVASUDEV] what does iostat / vmsta > show you [ not tried vm/iostat - tried sar -u, sar -d - sar -d shows lot of disk usage - %busy ranging from 85 to 95 - sar -u showed very high %wio - around 95% > please post onstat -p [RVASUDEV] [ can't post it right now as the old app has been put into RCS and we are working on a new design, which is still in the dev. stage ] , config fil [ config file attached below <<onconfig.tmp>> ] > , and specifics of the "slow performance" [ given below ] . More may be > required later. > Anyway, here goes - it's quite complicated : This app (A1) is a set of programs. The Big Picture first: It talks via MQ queues to another app (A2) (gets input from it) and also sends output to a third app (A3) (again via MQ queues). In a nutshell, this app A1 is not able to keep up with the speed at which the app A2 sends messages on the queue. So the input queue eventually gets full. A2 does not do much work, while A1 does a lot of business logic processing + database access. This may be one reason why it's slow. But we are trying to make it at least catch up somewhat with A2. May be a futile effort :( End of big picture. Details : Some of the programs in A1 are written in ESQL/C and some in 4GL. (The ESQL/C programs are background batch jobs which do the real work. The 4GL program is basically an admin module to maintain config params of the app). They use MQ Series, via a wrapper library which provides easier-to-use calls to MQ, as well as some more functionality. The library as well as the app was written initially by our client. We now maintain many apps for them, of which this is one. Apparently, this app was giving performance problems from the start, hence was never deployed. A lot of people worked on it off and on over the past several months, to improve the performance, but not much progress was made. (Most of the efforts were directed at the code). There is also a library which enables the batch programs to run as background processes. A supervisor program is passed the program name and its config file as command line args. It starts the program as a child via fork/exec. It also monitors their existence / activity via UNIX IPC and restarts them if they die. There is also an application framework which enables the programs to communicate with the MQ wrapper library. This is basically a template. I.e. the main() function is part of the framework. A developer wanting to use the framework has to plug in his/her app-specific code into a few functions such as open_fn(), trans_fn(), close_fn(), etc. E.g. in main(), the framework connects to the MQ queue manager and the program's queue. In open_fn(), the developer can write code to connect to the database, declare / open cursors, etc. In trans_fn(), they have to write code to do database access and app-specific business logic. These *_fn()'s are called via a callback mechanism at appropriate points. The trans_fn() is where the bulk of the work is done. This fn. is called by the framework each time it receives a message on the input MQ queue. Within this fn, code exists to decipher the message contents, match it against some database tables using SQL queries to see if it satisfies some business criteria, and if so, insert some data into other tables, and also write some data to another program via another queue. This other program again runs a trans_fn() where it does some more processing using the input messages and the data inserted in tables by the earlier program, and based on this processing, sends output to the final destination apps via more queues. > Eric P. Melillo > > > > > Hi, > > Platform: > > HP9000/D230 > 128 MB RAM > 60 GB disk > HP-UX 10.20 > Informix 7.30 > ESQL/C 9.15 > MQ Series 5.00 > > Does anyone have experience with performance tuning on this combo ? > Kernel params, onconfig params, other Informix tuning ? > > We have an app, using all the above, which is slow. Urgently need advice. > > Can provide more details if needed. > > TIA > > Vasudev > > > > ------_=_NextPart_000_01BEA390.33834894 Content-Type: application/octet-stream; name="onconfig.tmp" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="onconfig.tmp" #***********************************************************************= *** # # INFORMIX SOFTWARE, INC. # # Title: onconfig.std # Description: INFO

I just changed SHMVIRTSIZE and SHMADD on an HPUX10.20 to match the size of the memory dynamically allocated to informix as shown by the ipcs command. For example if you show eight 8MB segments then set SHMVIRTSIZE to 64MB. It seemed to speed things up a lot. Many shared memory segments allocated to Informix seem to dog HPUX. Also check the release notes for update statistics recommendations. Try some cc flags in the $INFORMIXDIR/bin/esql script for compiler optimization, (like -O). If you do that let me know if it has any affect. -- --------------------------------------------------------- Steven Hauser email: hause011@tc.umn.edu URL: http://www.tc.umn.edu/~hause011 ---------------------------------------------------------