From: Bernhard Schmidt <berni@birkenwald.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: null-pointer deref in ulogd2
Date: Wed, 24 Jun 2009 00:39:58 +0200 [thread overview]
Message-ID: <4A4159BE.7040807@birkenwald.de> (raw)
In-Reply-To: <4A4108D6.901@birkenwald.de>
Hi,
> ARGH! I found my problem. Apparently Postgres was too slow on INSERT.
> Although the CPU load looked fine (and even IOWait wasn't out of the
> ordinary, 20% on one CPU) it seems to have blocked. Sacrificing
> consistency for speed by setting fsync=no in postgres the IOwait went
> down to 0.5% and I now have 100 flows, all of them with start and end!
Looks like I spoke too early :-(
We have now passed peak-time, which means about 450 Mbps traffic, 60k
concurrent sessions and about 300 flows/s in a 1hour average.
First of all, ulogd has segfaulted again. Unfortunately I didn't get a
coredump, I've restarted it in gdb now.
Second, the number of flow records without any time stamp is getting
higher and higher again, with now 20% lacking either start or endtime
ulogd=# SELECT count(*) FROM ulog2_ct;
count
---------
3278208
(1 row)
ulogd=# SELECT count(*) FROM ulog2_ct WHERE flow_start_sec IS NULL;
count
--------
270690
(1 row)
ulogd=# SELECT count(*) FROM ulog2_ct WHERE flow_end_sec IS NULL;
count
--------
306740
(1 row)
This seems to get worse the longer ulogd runs, shortly before the
segfault there were 8000 flows without end_time in a row. The recent
ones are fine again.
I'm still getting (very ocasionally)
Wed Jun 24 00:31:21 2009 <5> ulogd_inpflow_NFCT.c:656 Maximum buffer
size (17367040) in NFCT has been reached. Please, consider rising
`netlink_socket_buffer_size
` and `netlink_socket_buffer_maxsize` clauses.
does it make sense to increase the buffer even more? If 17MB of buffer
aren't enough I don't think it can keep up with any setting. And now
that fsync is disabled in Postgres the box is really not that heavily
loaded. CPUs 3&4 (serving the interrupts of the two NICs) are near 100%
interrupt load at peak time, but 1&2 are >80% idle.
Does anyone else run this setup with similar numbers and can shed some
light on tuning?
Oh, and we're dumping conntrack -L every minute. Works fine during the
day with 30k connections, but starts to frequently segfault with 60k
connections in the evening. Also trying to get a coredump now.
Bernhard
next prev parent reply other threads:[~2009-06-23 22:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-23 7:27 null-pointer deref in ulogd2 Bernhard Schmidt
2009-06-23 8:31 ` Bernhard Schmidt
2009-06-23 15:40 ` Pablo Neira Ayuso
2009-06-23 16:54 ` Bernhard Schmidt
2009-06-23 22:39 ` Bernhard Schmidt [this message]
2009-06-24 10:59 ` conntrack segfault (was: Re: null-pointer deref in ulogd2) Bernhard Schmidt
2009-06-24 11:17 ` Krzysztof Oledzki
2009-06-24 11:57 ` Jan Engelhardt
2009-06-24 12:56 ` conntrack segfault Bernhard Schmidt
2009-06-24 17:58 ` Pablo Neira Ayuso
2009-06-24 20:05 ` Bernhard Schmidt
2009-06-24 22:18 ` Bernhard Schmidt
2009-07-02 16:30 ` Pablo Neira Ayuso
2009-07-06 10:29 ` Krzysztof Oledzki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A4159BE.7040807@birkenwald.de \
--to=berni@birkenwald.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.