|
Comments in-line. > -----Original Message----- > From: Pete Hall [mailto:pbhall@execpc.com] > > Ken, > > The single most important number is one that I didn't see in > your message. > Run WRKSYSSTS and check out the page faults. I expect that > they will not be > very high though. High is a relative term. On your system, 60 > is probably > ok, but the lower the better. Agreed. If you have PM/400 running, its historical WRKSYSSTS can be very helpful for this. > You have several problems with your configuration, not the > least of which > is that you are apparently running controlling subsystem > QBASE. If you want > to get any performance out of your system, that's not the way > to do it. Run > QCTL, segregate your jobs according the type of work they do > (will require > modifying subsystem descriptions to assign additional storage pools, > creation of routing entries and maybe additional classes of > service and job > descriptions). Pete, why do you think Ken is running QBASE? The last time I set up a new system from scratch ('98), the memory pools were the same before and after switching from QBASE to QCTL. Ken's running a very simple memory pool setup, but I really don't see any clues in it as to how his subsystems are set up. > The thing I'd try first though, is decreasing the timeslice > in your classes > of service by a factor of 10. That's right, 10! Change 2000 > to 200. Keep > track of what you do. You can always put it back, but my > guess is that you > have some CPU intensive jobs that are eating machine cycles for their > entire timeslice and then coming back for more. The net > effect is that the > lights get dim in Boston. Agreed - the default timeslice settings are for old, small machines, not the powerful system that Ken's running. > Whether that works or not though, segregate your jobs. Move > everything but > system jobs out of *BASE and the machine pool (use shared pools - the > autotuner will manage them). Give similar jobs their own > storage pool and > try to run all of the jobs in a pool at the same priority. If you're > running QBASE, change your controlling subsystem. Agreed. Ken, for several years I've been using a memory pool setup that has worked on several different machines for two different companies. It arose from some discussions I had with Richard Jackson some years ago, on the old Newslink BBS and at a COMMON conference we both went to. Recently the performance expert at our local IBM branch checked over our machine here and was satisfied that there wasn't any obvious way to improve upon it. Here's the WRKSHRPOOL of the descriptions of the pools I use: Pool Text *MACHINE Machine pool *BASE Base pool *INTERACT Interactive pool *SPOOL Spool pool *SHRPOOL1 Batch pool *SHRPOOL2 Never-Ending Jobs pool *SHRPOOL3 Server Jobs pool *SHRPOOL4 Communications Jobs pool *SHRPOOL5 Subsystem Monitors pool All pools except *MACHINE have *CALC (Expert Cache) turned on, including *SPOOL. The subsystem setup to work with this is a bit of a pain, and has to be revisited after each release upgrade, but once done it requires no other maintenance. All subsystems have at least two pools defined. Pool 01 is always *SHRPOOL5. No routing entries use pool 01 in any subsystem, so the only things that run in *SHRPOOL5 are the subsystem monitors. This improves job creation and job startup response, since *SHRPOOL5 is set large enough that the monitors stay in memory and don't get paged out. I think *SHRPOOL2 is self-explanatory - we have several jobs that sit in this pool waiting on messages or cycling at regular intervals. Keeping them separate from the "normal" batch jobs helps the performance of both. We also put these in a separate subsystem, for ease of control. *SHRPOOL3 and *SHRPOOL4 are where jobs that run in QCMN, QSNADS, QSERVER, QSYSWRK, QUSRWRK, etc. end up. There are a LOT of routing entries and prestart job entries that need to be changed to make this work, but it has a noticeable effect once it's done - we could see the difference in system response. I also run the built-in autotuner, and have set some limits on it and changed some priorities in WRKSHRPOOL. Here they are: -----Size %----- -----Faults/Second------ Pool Priority Minimum Maximum Minimum Thread Maximum *MACHINE 1 8.93 100 5.00 .00 10.00 *BASE 2 3.00 100 10.00 2.00 100 *INTERACT 3 10.00 100 5.00 .50 200 *SPOOL 7 1.00 100 5.00 1.00 100 *SHRPOOL1 5 3.00 100 10.00 2.00 100 *SHRPOOL2 6 1.00 100 10.00 2.00 100 *SHRPOOL3 4 3.00 100 5.00 .50 100 *SHRPOOL4 2 1.00 100 10.00 2.00 100 *SHRPOOL5 1 1.00 100 10.00 2.00 100 This is a 620-2180 with 1 GB of memory - the machine is about maxed out during heavy load times (week after period close). With this tuning setup it maintains fairly good response and manages a lot of throughput, despite saturating the processor much too often. I hope it gives you some ideas, Ken. If anyone has any questions, please ask. If you think this is nuts, let me know that, too - there's a lot of alternatives that should at least be considered. Dave Shaw Spartan International, Inc. Spartanburg, SC +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
