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