Hi Pablo, Pablo Neira Ayuso wrote: > * I had to rise the default value of SocketBufferSize and > SocketBufferSizeMaxGrowth in conntrackd.conf to avoid netlink overflows > with such amount of traffic. There are log messages in conntrackd.log > that warn about this issue. Also, you can notice this if you observe > that conntrackd hits 100% CPU consumption at some point - this happens > when netlink overflows. We already raised these values in the past. There are no hints in the log about overflows. > * Also, I had to rise the default value of McastSndSocketBuffer and > McastRcvSocketBuffer since I was noticing packets lost via conntrackd -s > - see multicast sequence tracking. This happens when the link gets > pretty congested because of Since upgrade to >0.9.6, there's no problem with multicast packets in 'conntrackd -s'. On the other hand, we have a dedicated 1 gigabit link as cluster interconnect. I do not expect congestion there. > With these tweaks the results were good, conntrackd was consuming about > the same percetange of CPU than ksoftirqd (~25% each via top, which is > not very reliable but it's OK for an estimation). We have quad core machines, and CPU is idling a lot. 2 of the cores are idle 100%, two are idle around 50%. > 1) does /var/log/conntrackd.log - or syslog - tells anything relevant? > Are the entries being comitted to kernel-space successfully? according to both conntrackd.log and syslog, entries are being commited. I see no relevant negative entries in both logs (except of course the INVALID packets). > 2) Can you see the committed entries in the kernel via `conntrack -L' > after the fail-over? yes. > 3) Are you noticing any abnormal CPU consumption? no. Best regards Bernhard -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
