All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: Moritz Gartenmeister <moritz@uplink-verein.ch>
Cc: netfilter@lists.netfilter.org
Subject: Re: iptables crashes server?
Date: Mon, 04 Apr 2005 09:59:15 -0500	[thread overview]
Message-ID: <42515643.3040202@riverviewtech.net> (raw)
In-Reply-To: <4250F7E0.3070203@uplink-verein.ch>

I've had a similar situation on a system that was extremely complex (ECMP across 8 UML routers & CableModems, etc) running a lot of things both kernel space and user land.  We put 2 GB in the box for all the contracks that were going on for support of roughly 64000 possible contracks (8000 per UML with 8 UMLs) (there is a formula that I can find if needed).  The box would end up in a very similar situation after about 36 hours of operations.  We decided to set up a cron job to reboot the box daily.  Yes I know that this is a unix box that we are talking about, but given the nature of what the system was doing and the amount of time that we had to work on things this was the simple solution at the time.  Needless to say it's (sort of) working so my boss will not let me go back and work on it any more.  :(  Yes it pains me every time that I think about it.



Grant. . . .

Moritz Gartenmeister wrote:

> hi all
> 
> i'm running linux 2.6.11.3 and iptables 1.3.1 with pom 20050321. i 
> patched the kernel with ipp2p, and layer-7 patch.
> 
> the server is running as a bridge and is working absolutly fine. after a 
> while (there is no specific time limit) the server crashes. the server 
> is no more able to allocate new memory and even swapping doesn't help. 
> in this state i am unable to log in, i have to push the power button.
> 
> i don't see heavy traffic before a crash and i don't see any flooding. 
> is there a known memory leak problem?
> 
> i checked /proc/sys/net/ipv4/netfilter/ip_conntrack_count this number is 
> in the range of 2'000 - 5'000.
> i checked /proc/slabinfo <active_objs> is more or less similiar to 
> ip_conntrack_count, <num_objs> is the maximum of ip_contrack_count.
> i also was checking /proc/meminfo and there was no steady increase.
> 
> /var/log/messages shows no warning.
> /var/log/syslog shows nothing
> icmp is working.
> imap is probably working (someone told me).
> http is not working.
> pop over ssl is working (sometimes).
> 
> does anyone had/have the same experience? or does anyone have some hints 
> for further steps?
> 
> hardware: dell poweredge 2560 with 2gybte ram, 2 xenon dual cpus.
> 
> i was running the same setup wiht an older kernel 2.6.7/10 without much 
> troubles.
> 
> regards
> moritz
> 
> 
> 



      parent reply	other threads:[~2005-04-04 14:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-04  8:16 iptables crashes server? Moritz Gartenmeister
2005-04-04 11:47 ` Mohamed Eldesoky
2005-04-05  6:47   ` Moritz Gartenmeister
2005-04-05 16:34     ` R. DuFresne
2005-04-05 18:22       ` Moritz Gartenmeister
2005-04-05 16:45     ` Mariusz Kruk
2005-04-10 10:50       ` iptables crashes server? [OT] Moritz Gartenmeister
2005-04-11  9:15         ` Mariusz Kruk
2005-04-04 14:59 ` Grant Taylor [this message]

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=42515643.3040202@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --cc=moritz@uplink-verein.ch \
    --cc=netfilter@lists.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.