Forum: NGINX What are the limitations of ip_hash ?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
2e3ab10b8ef891b5dd872ef8f8bea3cb?d=identicon&s=25 Mark Swanson (Guest)
on 2008-12-31 04:25
(Received via mailing list)
upstream tomcatcluster {
        ip_hash;
        server test1:8080 max_fails=0;
        server test2:8080 max_fails=0;
    }

It seems that the size of ip_hash is too small and it can't hold enough
keys - or perhaps nginx clears out keys after a period of time?

I'm curious what the limitations of ip_hash are because it's not working
100% of the time.

Thank you.
Fda08117336cfde6562315df04b976e8?d=identicon&s=25 Dave Cheney (Guest)
on 2008-12-31 05:04
(Received via mailing list)
Hi Mark,

Can you explain 'not working'. From my experience with ip_hash given a
large enough set of incoming IP addresses, requests would be distributed
equally across both machines. Its not so much a hash as a modulo of the
incoming ip address.

Cheers

Dave

On Tue, 30 Dec 2008 22:15:21 -0500, Mark Swanson
<mark@ScheduleWorld.com>
2e3ab10b8ef891b5dd872ef8f8bea3cb?d=identicon&s=25 Mark Swanson (Guest)
on 2008-12-31 09:10
(Received via mailing list)
Dave Cheney wrote:
> Hi Mark,
>
> Can you explain 'not working'. From my experience with ip_hash given a
> large enough set of incoming IP addresses, requests would be distributed
> equally across both machines. Its not so much a hash as a modulo of the
> incoming ip address.

1. IP 1.1.1.1 -> ip_hash -> server A
2. IP 2.2.2.2 -> ip_hash -> server B
3. IP 1.1.1.1 -> ip_hash -> server A

so far so good. 1.1.1.1 always goes to server A just like the docs
state. Until ...

4. IP 1.1.1.1 -> ip_hash -> server B

This should never happen if I understand ip_hash correctly, yet this it
seems to happen about 10% of the time (not useful to anyone needing
sticky sessions).

Btw, modulo? If you have the source handy would you mind posting the
code for this? I was really hoping the class C address would be used as
a key into a hash table and the value was the previously used server ID.

I was also really hoping this hash table would be preserved after
sending a HUP signal to nginx.

Cheers.
E88f834c0785a399b498b6cf70d10223?d=identicon&s=25 Grzegorz Nosek (gnosek)
on 2008-12-31 11:03
(Received via mailing list)
On śro, gru 31, 2008 at 02:58:30 -0500, Mark Swanson wrote:
> seems to happen about 10% of the time (not useful to anyone needing
> sticky sessions).

If I understand the source correctly, this happens when one of your
backends is down (as determined by Nginx). The IP address is then
rehashed and the connection retried until it succeeds or you run out of
backends.

> Btw, modulo? If you have the source handy would you mind posting the
> code for this? I was really hoping the class C address would be used as
> a key into a hash table and the value was the previously used server ID.

The two functions starting from here:

http://emiller.info/lxr/http/source/http/modules/n...

> I was also really hoping this hash table would be preserved after
> sending a HUP signal to nginx.

There's no hash table in ip_hash, there's a hash _function_ which maps
incoming IP to a server id. It isn't remembered anywhere. But the
backend up/down status and failure count is indeed reset upon SIGHUP
(AFAIK).

Best regards,
 Grzegorz Nosek
Fda08117336cfde6562315df04b976e8?d=identicon&s=25 Dave Cheney (Guest)
on 2008-12-31 12:07
(Received via mailing list)
Indeed - what does your error log say ? I notice you have max fails=0
which means (AFAIK) that a temporarily failed backend will be re added
to the queue immediately.

Cheers

Dave
2e3ab10b8ef891b5dd872ef8f8bea3cb?d=identicon&s=25 Mark Swanson (Guest)
on 2008-12-31 17:22
(Received via mailing list)
Grzegorz Nosek wrote:
>> This should never happen if I understand ip_hash correctly, yet this it
>> a key into a hash table and the value was the previously used server ID.
> backend up/down status and failure count is indeed reset upon SIGHUP
> (AFAIK).
>
> Best regards,
>  Grzegorz Nosek
>
>
Ok, thank you for the info.
2e3ab10b8ef891b5dd872ef8f8bea3cb?d=identicon&s=25 Mark Swanson (Guest)
on 2008-12-31 18:43
(Received via mailing list)
Dave Cheney wrote:
> Indeed - what does your error log say ? I notice you have max fails=0

Error log: er... hold the phone...
I've just finished some analysis of the session conversations and found:
1. Funambol client connects to SWorld to start a sync.
2. Funambol client takes 80 minutes to figure out what to send.
3. Funambol client sends, and fails because the session timed out and
has been deleted.

When a session is terminated it looks like nginx is routing a request to
the wrong machine because the session isn't there, but it's not nginx's
fault.

Summary:
I have no evidence that nginx ip_hash is at fault.
I'm sorry for the noise. I'm thankful for the responses.

> which means (AFAIK) that a temporarily failed backend will be re added
> to the queue immediately.

I did this because the docs don't state what to look for in the
error.log file if a server is marked as inoperative. I was worried that
a server was being marked as inoperative and the requests are being sent
to the wrong machine. I should be able to force this condition and
derive the text from the logs. If I get around to doing this I'll post
to the list.

Cheers.
This topic is locked and can not be replied to.