every minute: "I/O loop cycle took .... ms for 2 events"
Hello, (please keep me in CC the mailing list issues are still not solved) we get the following WARN log entry exactly once a minute: I/O loop cycle took 6343 ms for 2 events Is this something to worry about? Is this related to hard drive I/O or some other kind of I/O? thanks, Christoph
On Sat, Sep 28, 2019 at 02:12:00PM +0000, Christoph wrote:
Hello,
(please keep me in CC the mailing list issues are still not solved)
we get the following WARN log entry exactly once a minute:
I/O loop cycle took 6343 ms for 2 events
Is this something to worry about? Is this related to hard drive I/O or some other kind of I/O?
Hello This means there are events that take 6 s, possibly postponing other events. May cause problems if you would run some protocols configured with tight timers (e.g. OSPF set to 5 s dead interval). This is probably kernel table sync. Do you export full BGP to kernel? Is this on BSD? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
This means there are events that take 6 s, possibly postponing other events. May cause problems if you would run some protocols configured with tight timers (e.g. OSPF set to 5 s dead interval).
This is probably kernel table sync. Do you export full BGP to kernel? Is this on BSD?
Yes this is on a system doing fulltable BGP exports to kernel on FreeBSD 12 (BIRD 2.0.6). Is there anything that we can change in the configuration to mitigate this issue or should we just ignore it? Or is this a bug in BIRD 2? thanks, Christoph
On September 29, 2019 2:13:00 PM GMT+02:00, Christoph <cm@appliedprivacy.net> wrote:
This means there are events that take 6 s, possibly postponing other events. May cause problems if you would run some protocols configured with tight timers (e.g. OSPF set to 5 s dead interval).
This is probably kernel table sync. Do you export full BGP to kernel? Is this on BSD?
Yes this is on a system doing fulltable BGP exports to kernel on FreeBSD 12 (BIRD 2.0.6).
Is there anything that we can change in the configuration to mitigate this issue or should we just ignore it? Or is this a bug in BIRD 2?
BIRD reads the kernel table on FreeBSD in one syscall which fills a huge array with all routes at once. (Is there any better choice?) This syscall eats several seconds uninterruptibly. The reading is needed as BIRD checks that the kernel table matches the BIRD table. The solution for this will be multithreaded execution which is currently being developed (for more reasons than BSD route sync). Then one thread could wait for the kernel export without blocking whole the now-singlethreaded daemon. Maria
participants (3)
-
Christoph -
Maria Matějka -
Ondrej Zajicek