Am 27.12.19 um 02:29 schrieb Tom Yan: > Hi Reindl, > > Hmm. Not sure I get what you mean. Are you saying that this could be a > "generic" kernel flaw (in handling logging / messages), instead of a > Netfilter-specific issue? dunno, but since no longer using "-j LOG" the f**g randomly crashes of our production firewall system over months hwich nearly made me insane are gone and that it spits to "dmesg" is ugly anyways when i try to debug crashes, enable kexec/kdump and the only thing it has to do is write my whole filesystem full with 100 lines iptables related messages from dmesg repeatet until the is no space available i am done > On Fri, 27 Dec 2019 at 08:23, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote: >> >> >> >> Am 26.12.19 um 23:29 schrieb Duncan Roe: >>> On Thu, Dec 26, 2019 at 11:05:33AM +0800, Tom Yan wrote: >>>> Hi all, >>>> >>>> So I was trying to log all traffics in the FORWARD chain with the LOG >>>> target in iptables (while I say all, it's just some VPN server/client >>>> that is used by only me, and the tests were just opening some >>>> website). >>>> >>>> I notice that the logging causes high CPU usage (so it goes up only >>>> when there are traffics). In (h)top, the usage shows up as openvpn's >>>> if the forwarding involves their tuns. Say I am forwarding from one >>>> tun to another, each of the openvpn instance will max out one core on >>>> my raspberry pi 3 b+. (And that actually slows the whole system down, >>>> like ssh/bash responsiveness, and stalls the traffic flow.) If I do >>>> not log, or log with the NFLOG target instead, their CPU usage will be >>>> less than 1%. >>>> >>>> Interestingly, the problem seems to be way less obvious if I am using >>>> it on higher end devices (like my Haswell PC, or even a raspberry pi >>>> 4). There are still "spikes" as well, but it won't make me "notice" >>>> the problem, at least not when I am just doing some trivial web >>>> browsing. >>>> >>>> Let me know how I can further help debugging, if any of you are >>>> interested in fixing this. >>>> >>> Just in case you missed it, be sure that your logger is configured not to sync >>> the file system after every logging. That is the default action btw. >>> >>> I have used large-volume logging in the past and never encountered a CPU problem >>> (but had to run logrotate every minute to avoid filling the disk) >> >> the problem is "-j LOG" at it's own and not suprisingly after having >> enough of random crashes and kexec only spits the disk full of >> demsg-output from iptables "-j LOG" switching awy to NFLOG and ulogd and >> never ever faced antother crash >> >> "-j LOG" spits into kernel ring buffer and by it's own produces double >> load no matter what happns after the action
