Date: Thu, 19 Feb 2004 18:50:24 +1100
From: Ken Wallis [EMAIL PROTECTED]
Subject: RE: Unidata, Monitoring system parameters
James Hogan wrote:
From time to time we have customers who break a Unidata
parameter and the
program they are running will crash with errors such as No
more entries in
MI table in 'LCT -n'.
[snip]
I have had a look at the commands sms, gstt and lstt.
With some clever
scripting these could be used to take snap shots of the
system periodically
to check for an over step of the parameters. The script could
then warn the user if any parameter is over 80% utilised.
:I doubt it could warn them in time James. When programs go wild and eat smm
resources they tend to do it in a big hurry.
With decent tuning you should be able to find a reasonable compromise
between making lots of memory available for big jobs without lumbering
little jobs with a huge footprint. Even on AIX now there are some extended
shared memory facilities which allow you to have more segments instead of
just making them all huge! I can't remember the exact details but EXTSHM
rings a bell.
Cheers,
Ken
Hello James Hogan,of Sungard and Ken Wallis,
I have been getting the U2 Users Daily Digest for a for weeks now, after getting
individual emails for the longest time. I just caught this thread, and had to get in
on this.
What James Hogan wants to accomplish can be done.
There are products out there such as the DPMonitor that do exactly that.
There are several key factors though:
1) Situations like that require constant monitoring, and mapping out of platform
operational dynamics, and knowing the behaviors that occur when things start to go
wrong.
2) The Monitor needs to be external to the application server being monitored. You
need a real low overhaed process (Agent) on the Application Server doing low level
kernel calls, consistently, over time, and establish what the operational baseline
characteristics of the application are in normal mode. A real key is having that
Agent talking to an Operations Console Performance Explorer and Alert Center, and
having Probes, or Alarms set up, to notify Operations in things get out of whack, and
therefore allow corrective action to take place before the application server or
process gets hung. Imagine that - a proactive response as compared to a reactive
response.
3) You can't run such standard system commands/programs/utilities, especially ones on
the application server being monitored, as they consume significant volumes of
resources, and contribute to the problem, if they ever report back to you, (such as
Ken mentions).
So, what do you do? Reinvent the wheel with some configuration of scripts?
The smart choice is to download and evaluate the DPMonitor Performance Monitoring
Solution. The licensed version will monitor individual, user-selected processes, in
addition to the system wide parameters and metrics. You can set up Probes to test and
watch for certian conditions or thresholds to be crossed, and then take pro-active,
pre-programmed by the user responses to those situations, or simply generate an email,
a page, or what have you.
DPMonitor has Performance Agents for AIX, Solaris, and Windows. Even an Oracle Agent.
U2 Products and applications can be monitored via individual per process monitoring.
One Performance Explorer can display Agent data from all Agents, for centralized
Enterprise, or ASP providers. Very easily installed and set up, and provides dynamic
scaling, colorful, detail graphs of the health and resource level consumption of the
application server platform, history of resource consumption, aggregation, and
user-selectable timeframe periods for display. Dial right into problems situations
quickly and easily and understand exactly what is going on, when it happens, and what
ripple affects it causes in paltform operational dymanics. Real easy to solve the
problems if you have a clear roadmap. DPMonitor provides that roadmap, at reasonable
pricing.
Check out the significantly updated www.deltek.us websoyte for product information and
examples of how the DPMonitor could be easily quickly setup to provide exactly the
type of application server monitoring James at Sungard was asking about.
Regards,
Scott Richardson
Senior Systems Engineer / Consultant
Marlborough, MA 01752
Email: [EMAIL PROTECTED]
Web: http://home.comcast.net/~CheetahFTL/CC
eFax: 208-445-1259
--
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users
