Thanks, Kirk.

We've got the CPACF hardware going on this - we had thought the software 
encryption was causing the problem. We've also checked via the SMF 113s that it 
is being used. 

Next step was to get the SMF 119s written to see what transfers were using the 
CPU. But there's absolutely no correlation between the transfers and the CPU 
burn.

Everything runs fine until the related server, which is driving OpenSSH gets 
the error, then immediately the SSH process goes nuts. If we get another error, 
the second SSH process goes nuts too.

It's how we can verify what is using the resources within the SSH daemon that 
we're trying to understand. Our client is outsourced to IBM and they're not 
being terribly helpful.

Any guidance on seeing inside SSH would be greatly appreciated.

Martyn



On 9 Aug 2012, at 17:54, "Kirk Wolf" <[email protected]> wrote:

> The CPU consumption of Ported Tools OpenSSH can be significantly diminished
> by enabling the new ICSF hardware accelerated Cipher/MAC support.   See the
> User's Guide for details.
> 
> Time to startup, including CPU consumption, can also be reduced
> significantly if you enable /dev/random (via ICSF), but this doesn't sound
> like your problem.
> 
> Also, it is important to follow IBM's recommendations for tuning OMVS -
> especially those that relate to placing the LE C libraries in LPA.
> 
> Your problem description seems to imply that things are OK until some event
> which causes high CPU consumption.   If you can verify that the CPU
> consumption is by OpenSSH and not a user process, then I would recommend
> that you open a problem with IBM.
> 
> Regards,
> 
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
> 
> On Thu, Aug 9, 2012 at 7:58 AM, Martyn Jones <[email protected]> wrote:
> 
>> One of our clients has a problem with one or more OpenSSH processes
>> consuming as much of a whole processor as they can get.
>> 
>> The client is running IBM Ported Tools for z/OS - OpenSSH V1.2, primarily
>> to transfer files using SFTP.
>> 
>> Another server task in their architecture, which is attempting to manage
>> the transfer of files to their customer gets an error condition
>> (essentially an empty file).
>> 
>> This server task takes an unknown action when this error occurs, and then
>> the OpenSSH process starts consuming CPU as if it were going out of
>> fashion. The correlation between the error being detected on the server
>> task and the OpenSSH process going hot is too close on numerous days for
>> there not to be a cause annd effect link here.
>> 
>> The OpenSSH process will consume between 2300 and 4000 seconds of CPU
>> (z196) for each error that is detected on the server task, so it's a major
>> cost issue for the client.
>> 
>> Taking APA traces of the OpenSSH does not really help. Any application
>> code being run under the OpenSSH process is not usefully identified by APA.
>> 
>> Does anyone have any technique for seeing under the covers for an OpenSSH
>> process?
>> 
>> Thanks
>> 
>> Martyn
>> --
>> Disclaimer:This email is for the use of the addressee only and may contain
>> information that is confidential, privileged and/or subject to copyright.
>> Any views expressed in this email communication are those of the individual
>> sender, except where the sender specifically states them to be the views of
>> CPT Global. CPT Global does not represent, warrant or guarantee that the
>> integrity of this communication has been maintained or that the
>> communication is free of errors, virus or interference. If you are not the
>> intended recipient, you must not read, print, store, copy, forward or use
>> this email for any reason, in accordance with privacy and copyright laws.
>> If you have received this email in error, please notify the sender
>> immediately and delete the email. Thank you.
>> 
>> Message  protected by MailGuard: e-mail anti-virus, anti-spam and content
>> filtering.http://www.mailguard.com.au/mg
>> 
>> 
>> ----------------------------------------------------------------------
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to [email protected] with the message: INFO IBM-MAIN
>> 
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to