On Thu, 5 Nov 2020 at 16:23, Dave Jones wrote:
> So handling this approximately 1K times could drive the %steal up, I
> think.
>
That appears to be nmon failing, probably picking up a stale pointer or
following some bunny trail. It's something to pick up with Nigel. It does
not directly
No offense taking, Rob! :-)
We now have another clue, this time from the console log. This error
keeps recurring:
[82053.035436] User process fault: interruption code 0x60010 in
nmon_mainframe_6
[82053.035448] failing address: 3FFFD379000
[82053.035453] CPU: 24 PID: 17149 Comm: nmon_mainframe_
On Wed, 4 Nov 2020 at 20:06, Rob van der Heij wrote:
>
> On Wed, 4 Nov 2020 at 19:30, Dave Jones wrote
>
> What is the CP overhead of managing this? The one Linux guest that is
>> running here reports a %steal of 15-17%, which I think is a bit high.
>>
>
At the risk of teaching granny... the
On Wed, 4 Nov 2020 at 19:30, Dave Jones wrote
What is the CP overhead of managing this? The one Linux guest that is
> running here reports a %steal of 15-17%, which I think is a bit high.
> Could this be configured better?
> Thanks, appreciate it.
You’re right that EDEV overhead would show in
I don't see how steal time and the scsi would be related. There's an old
article about what steal time is at "http://velocitysoftware.com/STEAL.html;
On 11/4/2020 10:30 AM, Dave Jones wrote:
Hello, all.
I have a site that is using SCSI SAN (a V7000) to hold all z/VM
storagethe system
Hello, all.
I have a site that is using SCSI SAN (a V7000) to hold all z/VM
storagethe system z/VM and Linux software is installed on emulated
FBA dasd, and the Oracle database is stored on 360 or so SCSI disks,
attached via FCP.
What is the CP overhead of managing this? The one Linux
