Nginx TCP Delays

[Khalid Shaikh]

Chris,
Actually Paytam resolved the problem, the fix was.

It was simply amazing.

Best,
Khalid

violet2:~# cat README_PLEASE
Hi There,

This is Payam, i fixed your system by modifying your nf_conntrack max
setting as well as its h
           ash bucket size. Since you are using connection tracking via
iptable, you need to
make sure to modify the settings else you will have issues such as the one
reported =)

i created a payam-tune.sh file that has the 2 main commands you need
i also tuned the system slightly by making sure the proper sysctl.conf
options were selected

i no longer can experience the issue you were having before
one quick way for figuring out if your system is erroring out anywhere is by
using "dmsg" comm
     and on the command line

I also installed chkrootkit for you, in case your system was compromised. id
recomend installi
     ng  rkhunter 'apt-get install rkhunter'
I have also created you a test script to test your site, called
wget-test.sh.

cheers
Payam
pchychi at gmail.com
violet2:~# cat payam_tune.sh
# payam - pchychi
*echo 1048576 >  /proc/sys/net/ipv4/netfilter/ip_conntrack_max*
*modprobe ip_conntrack hashsize=1048576*
violet2:~#


On Thu, Sep 24, 2009 at 12:44 AM, Christopher Smith <x at xman.org> wrote:

> Avleen Vig wrote:
> > On Sep 21, 2009, at 1:02, François Battail <fb at francois.battail.name>
> > wrote:
> >
> >> Le dimanche 20 septembre 2009 à 22:47 -0700, Khalid Shaikh a écrit :
> >>
> >>> worker_processes 32;
> >>
> >> That's way too much, try to keep the number of workers sticked to the
> >> number of cores (eg: 4).
> >
> > Surely you should have more?
> > Eg with 4 cores have 8 workers.
> >
> > If workers block serving a request, this means you don't have CPU
> > sitting idle.
> Generally no. If you are doing everything properly event driven (even
> more so if you shift from a polling model to an AIO model), then any
> time you are busy serving a request, that means your CPU isn't sitting
> idle. The only time it should be idle is when there literally aren't any
> requests/events to process (at which point extra processes isn't going
> to help).
>
> --Chris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090924/8334b3c7/attachment.html>