Wednesday, September 27, 2017

Re: relayd: high CPU usage by one or two proc. of many

Hey,
had to bring this up again as I'm facing the same problem.
Exactly with the same 'error 35' in trace.
This time it is a 6.0-stable.

Anything else can be done to track this down?

Br
Maxim

> 24 feb. 2016 kl. 10:53 skrev Stuart Henderson <stu@spacehopper.org>:
>
> On 2016-02-24, mxb <mxb@alumni.chalmers.se <mailto:mxb@alumni.chalmers.se>> wrote:
>> Hey,
>> I have a strange behavior of relayd running on 5.8.
>> This machine almost exclusively terminates TLS traffic.
>> Exceptions are forwards which are in backup state (listen on CARP).
>>
>> Some times one or two relayd processes out of many consumes a lot of CPU
>> and stays like this until I restart relayd.
>
>> ktrace gives me following:
>> 4013 relayd CALL getdtablecount()
>> 4013 relayd RET getdtablecount 101/0x65
>> 4013 relayd CALL getrlimit(RLIMIT_NOFILE,0x7f7ffffbb630)
>> 4013 relayd STRU struct rlimit { cur=65536, max=65536 }
>> 4013 relayd RET getrlimit 0
>> 4013 relayd CALL recvmsg(550,0x7f7ffffbb6a0,0)
>> 4013 relayd RET recvmsg -1 errno 35 Resource temporarily unavailable
>> 4013 relayd CALL getdtablecount()
>> 4013 relayd RET getdtablecount 101/0x65
>> 4013 relayd CALL getrlimit(RLIMIT_NOFILE,0x7f7ffffbb630)
>> 4013 relayd STRU struct rlimit { cur=65536, max=65536 }
>> 4013 relayd RET getrlimit 0
>> 4013 relayd CALL recvmsg(550,0x7f7ffffbb6a0,0)
>> 4013 relayd RET recvmsg -1 errno 35 Resource temporarily unavailable
>> 4013 relayd CALL getdtablecount()
>> 4013 relayd RET getdtablecount 101/0x65
>> 4013 relayd CALL getrlimit(RLIMIT_NOFILE,0x7f7ffffbb630)
>> 4013 relayd STRU struct rlimit { cur=65536, max=65536 }
>> 4013 relayd RET getrlimit 0
>> 4013 relayd CALL recvmsg(550,0x7f7ffffbb6a0,0)
>> 4013 relayd RET recvmsg -1 errno 35 Resource temporarily unavailable
>>
>> Human readable file after kdump is filled with those lines.
>> This as far of my understanding is about limit of openfiles.
>
> It's not files; errno 35 is EAGAIN - it is likely that this was
> fixed in -current (2015/12/05).

No comments:

Post a Comment