All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.