Hi Dmitriy,

On Wed, Jul 20, 2011 at 06:33:27AM +0400, Dmitriy Samsonov wrote:
> Very strange, but your experience is enourmous so I'd be better to listen to
> you. As I wrote, before disabling HT I've tested all possible combinatrions
> of bindings:
> (haproxy, irq) = (cpu#n, cpu#m) in (0,1), (0,2), (0,3), ..(0,11), (1,0),
> (1,2), (1,3)...,(1,11) - total of 138 combinations, testing each one for
> three minutes with two httperf running, and recording information on
> haproxy's stat socket. If problem was not in HT what then?

Given that you tested that many combinations, I would say that there is
no option left ! I'm just surprized that you have an hyperthreading which
is as bad as the one we had on P4s. At this time, one of the factor for
its low efficiency was that the caches were cut in half when it was
enabled (half of the cache for each sibling). Maybe this is implemented
that way on your CPU, I don't know.

(...)
> Yes, according to /proc/cpuinfo CPU#0 has physical_id = 0, CPU#1 has
> physical_id = 1, and so on 0, 1, 0, 1... My first idea was to bind haproxy
> is CPU#0 and process irqs and CPU #2, it should be one CPU in one socket.
> And looks like these cores shoud share same L2.

Yes that's the idea.

> > At least now you know that in case of a DDoS, you can just put your
> > desktop machine in front of your expensive servers to protect them :-)
> 
> In case of DDoS I should read haproxy's mailing list:) I really appreciate
> your help.

Well, in a few years we managed to stop about a tens of them, maybe even
a bit more, including at least three really big ones. Sometimes it can take
up to a week to find how to block them. And each time we had to quickly add
dirty emergency hacks in the code. Once you've figured how to scale and
resist, they often give up because it's an endless game. At high rates, you
generally need your internet provider to cooperate (eg: inflate pipes to
drain the excess traffic). But that's something pleasant to work on :-)

Cheers,
Willy


Reply via email to