Hi people:
We've had several incidents where one Linux server has high CPU utilization and
impacts other servers from other applications. We were asked to prevent this
from happening again so we are looking for the best practices to avoid CPU
stealing or CPU waits on one Linux server caused by
Are you running under z/VM or in native LPARs ?
If you are running under z/VM what performance tools do you have available
?
On Wed, Oct 28, 2015 at 9:26 AM, Victor Echavarry Diaz <
vechava...@evertecinc.com> wrote:
> Hi people:
>
> We've had several incidents where one Linux server has high CPU
Yes, doing this yourself is a huge job. Using crosstool-ng helps a lot
because it finds the software pieces for your configuration and knows
how to build them.
On Wed, 2015-10-28 at 08:41 +, Agblad Tore wrote:
> I tried that once, starting to read the docs I found, probably the same
>
Hi, Rich.
You are correct; I misread the note and thought of gcc390 when I got to
the words "cross compiler". :-)
Have a good one, too.
DJ
On 10/27/2015 08:57 PM, Rich Smrcina wrote:
> Dave,
>
> That's for CMS. Florian appears to be looking for Linux.
>
>
> On 10/27/2015 08:48 PM, Dave Jones
Greetings Victor,
Is it always the same Linux guest?
That is somewhat important as thoughts maybe different its different
random Linux guest or just some from the same workload grouping.
Depending on how important the work a single guest maybe (will throttling
it hurt SLA's associated with
It is a somewhat crude method, but we used SHARE values on the directory entry
for the guests.
prod hosts would have SHARE weights in the thousands, and dev hosts would have
SHARE weights in the tens or hundreds.
Non-prod could pull hard as long as we weren't at capacity, but with any CPU
I tried that once, starting to read the docs I found, probably the same people
here had advised you to, pretty old but probably works.
However, I found out it was a huge job getting all the source files in place
with exactly the right versions.
And after next upgrade you have to fix all the
No, please don't do this. Having weights in the 1000's is what causes
this problem, creates excess share, the looping user takes over.
If you don't understand excess share, keep shares in the 100's, and use
absolute shares where you know exactly what is intended.
On 10/28/2015 7:13 AM,
The best way is to first understand your share settings and avoid excess
share.See Rob's paper on the topic
here "http://www.velocitysoftware.com/relshare.HTML;
Use zalert to detect problems, and have zoperator to give your
operations and applications people early indication.
i believe you
Well I dunno, we ran with ZVM 95-100% CPU far more than I was comfortable with,
and zlinux prod kept ticking, while non-prod got choked out above 95%. That
sure seemed like mission accomplished at the time. But we had a rather
standard Java workload across the board, and perhaps more a more
Dear Tore,
I do know that it is a huge job to get a correct environment, but I hope to
automate a lot of things of the configuration and it should be possible to
update it with new versions of the tools.
Let's see how far I will make it.
Florian
Am 28.10.2015 09:43 schrieb "Agblad Tore"
Thanks everybody for your comments they're very useful for us.
Regards,
Victor Echavarry
System Programmer, EVERTEC LLC
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Barton
Robinson
Sent: Wednesday, October 28, 2015 12:37 PM
To:
Thanks Jon. The only time this really matters is when you have looping
or otherwise out of control users. A well behaved system is, just, well
behaved If i could only get ibm to change their default shares from
large relative shares for things like tcpip to absolute shares, a lot of
this
13 matches
Mail list logo