I’m not finding much detail on the stick table size settings. Can someone point me in the right direction?
We’re running 1.5.18. The latest change log for 1.5.19 mentions some bugs related to segfaults with stick tables. Since upgrading isn’t an option for us, and I’ve narrowed down the problem to our stick table (see below), I think we can possibly configure our way out of daily crashes by fiddling withe the ‘size’ value, probably making it 500k or larger?
stick-table type ip size 200k expire 5m store gpc0,conn_cur,conn_cnt
acl block_on_path path_beg -i /path/to/login
tcp-request content track-sc1 src if block_on_path
http-request tarpit if { src_conn_cnt ge 15 } block_on_path
In the documentation, some examples of stick tables show the size:204800, so about the same as ours (200k). Other examples I’ve ran across are all about the same, think the largest was 500. But, what is that number exactly?
Thanks in advance!
HAP (can’t believe i scored the username ‘haproxy’ in this community!)
Found this is some old, deprecated documentation, perhaps it’s still fairly accurate. Still not a trove of details, but I guess I can go up to my RAM limits.
<size> is the maximum number of entries that can fit in the table. This value directly impacts memory usage. Count approximately 50 bytes per entry, plus the size of a string if any. The size supports suffixes "k", "m", "g" for 2^10, 2^20 and 2^30 factors.
So that would explain why whoever created this stick table used 200k, since we have 4G RAM. Ram usage has never gone way up though, at anytime, before a crash, or before any of it’s daily segfaults. Makes me want to try reducing the crashes, possibly preventing them, by increasing this to…500? 1m? 5m? We can always add more virtual RAM if necessary…
size: is the maximum number of entries that can fit in the table. This
value directly impacts memory usage. Count approximately
50 bytes per entry, plus the size of a string if any.
We will upgrade when it makes it downstream to our centos 7 repo’s, but in the meantime, hope to prevent a segfault which can occur 2-3 times every 24 hours, by giving the table a larger size. Thanks!
Well, if you are sure you are hitting a specific bug that has already been fixed, you simply report it to the RPM maintainer, so that he can backport the fix.
But I’m not sure how you come to the conclusion that increasing the stick table size is preventing the crash? Can you elaborate why you believe that?
No premises to my conclusion. Merely looking for anyone that can shed any more details on the size parameter.
I am not sure if we are hitting a specific bug, and cannot reproduce the problem. But, I do know it crashes. And I know if I remove the stick table, it doesn’t. And if it’s crashing, seems like one thing to try would be, give the table more room, see if there’s a reduction, no effect, or what.
I would rather install the debug build (including debug symbols), let it produce a coredump (“ulimit -c unlimited” before starting the executable) and post the stacktrace of the crash (gdb haproxy core; bt full).
Thanks, that is good advice! I was actually headed down that path, when I learned that the fix would still likely only be applying the latest 1.5.19 build, which isn’t an option for us. The company would rather have this crash than let us build a custom rpm and maintain it, etc. So, yea, I’m sure I’d spot one of those bugs in my dump, but then what?
Which again brings us back to fiddling with our current table. The only setting to fiddle with appears to be the size. Does anyone feel there’s any hope at all that increasing our 200k to, say, 1m, may help?
Alternately, a different, non-stick table method of accomplishing the same protection?
Well - not totally blind. Most of the examples I’ve ran across while researching this show that at 200k, it’s definitely on the lowest end. Raising it would appear to make sense, and likely cannot hurt anything, and MAY help. But yea, wish I could collect the core dump w/o having to recompile in the debug symbols first. Wish I could just compile the new build and put it on there. May end up doing that, eventually, but for now, I’m thinking we may just try a larger table. Thanks, Lukastribus.
