On 27 September 2013 12:42, Thomas Greer <[email protected]> wrote:
>
>
> On 27/09/2013 11:30, "Mike Belopuhov" <[email protected]> wrote:
>
>>On 27 September 2013 12:21, Stuart Henderson <[email protected]> wrote:
>>> On 2013/09/27 10:09, Thomas Greer wrote:
>>>> Hi All
>>>>
>>>> I'm seeing high CPU usage with bgpd session engine, and this was
>>>>knocking out
>>>> all my routing. The only way to get routing back is to pill the bgpd
>>>>and then
>>>> start it again. sthen suggested I ktraced it and the output is below.
>>>
>>> To clarify from an IRC discussion (tgreer please correct me if I'm
>>>wrong),
>>> AIUI this was running OK until announcements are made on a particular
>>>peer
>>> session, just bringing the session up without making announcements
>>>doesn't
>>> trigger it. Same happens when either announcing just a default route or
>>> when announcing full table.
>>>
>>>
>>>> This is on 5.3 however same issues experienced on 5.2. Different
>>>>hardware
>>>> also.
>>>>
>>>> Peer is running bird. Versions: 1.3.8 and 1.3.11
>>>>
>>>> Kdump:
>>>>
>>>>  6326 bgpd     EMUL  "native"
>>>>   6326 bgpd     RET   sendmsg -1 errno 35 Resource temporarily
>>>>unavailable
>>>>   6326 bgpd     CALL  sendmsg(0x9,0x7f7ffffe7080,0)
>>>
>>> EAGAIN - send(2) says "The socket is marked non-blocking and the
>>>requested
>>> operation would block."
>>>
>>> Anyone have clues?
>>>
>>>>   6326 bgpd     RET   sendmsg -1 errno 35 Resource temporarily
>>>>unavailable
>>>>   6326 bgpd     CALL  sendmsg(0x9,0x7f7ffffe7080,0)
>>>>   6326 bgpd     RET   sendmsg -1 errno 35 Resource temporarily
>>>>unavailable
>>>>   6326 bgpd     CALL  sendmsg(0x9,0x7f7ffffe7080,0)
>>>>   6326 bgpd     RET   sendmsg -1 errno 35 Resource temporarily
>>>>unavailable
>>>>   6326 bgpd     CALL  sendmsg(0x9,0x7f7ffffe7080,0)
>>>>   6326 bgpd     RET   sendmsg -1 errno 35 Resource temporarily
>>>>unavailable
>>>>   6326 bgpd     CALL  sendmsg(0x9,0x7f7ffffe7080,0)
>>>>   6326 bgpd     RET   sendmsg -1 errno 35 Resource temporarily
>>>>unavailable
>>>>   6326 bgpd     CALL  sendmsg(0x9,0x7f7ffffe7080,0)
>>>>   6326 bgpd     RET   sendmsg -1 errno 35 Resource temporarily
>>>>unavailable
>>>>   6326 bgpd     CALL  sendmsg(0x9,0x7f7ffffe7080,0)
>>>>   6326 bgpd     RET   sendmsg -1 errno 35 Resource temporarily
>>>>unavailable
>>>>
>>
>>how was fd 0x9 obtained?
> Not sure how to answer thisÅ  does the info below help? This is taken
> during it's 'broken' state
>

in your kdump there was a syscall that returned it.  like

   CALL socket
   RET  0x9

but your fstat output is sufficient as well for now.  0x9
is a unix stream socket.

> _bgpd    bgpd        5255    9* unix stream 0xffff800000ccf000 <->
> 0xffff800000ccfe00

Reply via email to