How to prevent /proc/<pid>/status from running slow on AIX ?

[Volker Simonis]

Hi,

just for reference I want to post the answer I got from the IBM support here.

Unfortunately, it seems that the described behaviour
(i.e./proc/<pid>/status running slow on AIX) seems to be the known,
default behaviour which can not be changed easily:

".. /proc/<pid>/status gets its data from a different source (pvproc),
than does getrusage and times (the ublock). The ublock data is updated
each time a thread leaves the CPU, while the pvproc data is aggregated
from the threads by sched every second. Therefore, the pvproc based
times are usually almost always behind the ublock based ones.."

Regards,
Volker


On Fri, Jul 17, 2015 at 8:34 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Yes, reading /proc/<pid>/status twice in a row will report exactly the
> same (inaccurate) value.
>
> It really seems that the update interval of /proc/<pid>/status on AIX
> is much to coarse compared to other Unix implementations.
>
> Regards,
> Volker
>
> On Thu, Jul 16, 2015 at 10:27 PM, Dean Long <dean.long at oracle.com> wrote:
>> If you read /proc/<pid>/status twice in a row, does the value increase or
>> stay the same?  I found the following that implies it's not being updated
>> between reads:
>>
>>   http://fixunix.com/aix/85091-reading-proc-status-file.html
>>
>> If that's the case then the accuracy would be limited by how often an
>> internal snapshot is done for procfs.
>> Being off by a clock tick sounds reasonable, but being off by 1 second? not
>> so reasonable.
>>
>> dl
>>
>>
>> On 7/15/2015 7:23 AM, Volker Simonis wrote:
>>>
>>> Hi AIX experts,
>>>
>>> do you have any idea how to prevent /proc/<pid>/status from running
>>> slow on AIX (compared to times() and getrusage())?
>>>
>>> Please have a look at the attached program which describes and
>>> demonstrates the problem in full detail.
>>>
>>> I'd need a workaround for this problem for the AIX port of the new
>>> ProcessHandle implementation which came as part of JEP 102.
>>>
>>> Thank you and best regards,
>>> Volker
>>
>>