История изменений
Исправление fet4, (текущая версия) :
conntrack -C в момент проблемы показывает те же самые показатели, которые начинают падать из-за потери производительности. Т.е. скачков количества сессий нет.
В логах ВСЕ чисто. Максимум что видно в момент проблемы, вчера например.
Oct 26 18:29:13 fibernet-router kernel: [163086.225243] perf: interrupt took too long (2502 > 2500), lowering kernel.perf_event_max_sample_rate to 79750
pps в районе 100Kpps. Так же скачков нет и начинает падать в момент.
A dnat_post -m set --match-set snat06 dst,dst -j SNAT --to-source 172.19.0.6Так и сделаю, люблю связку ipset+iptables, почему-то сам не увидел такую оптимизацию)))
Я бы начал с поиска «виновника» - т.е. того кто создает очень много соединений ( через -m connlimit --connlimit-above ... )
А можно ли как-то посмотреть количество сессий не общее а по ip?
Через -m connlimit --connlimit-above интересно какое выбрать значение, что есть нормальное для обычного хомяка? Может вообще просто зарезать количество сессий с одного ip?
Возможно кто-то внутри «досит».
Перед маршрутизатором стоит еще BRAS для pppoe/ipoe, ядро постарей конечно. На нем проблемы нет, а если бы досили изнутри должно было бы так же вылезти ?! conntrack на нем так же не отключен, отличие разве что в нате и мангл балансировке.
Кстати
bras# conntrack -C
81268
nat# conntrack -C
267003
Ну бородатые рекомендации говорят, что хеш к макс надо ставить 1/1, если память позволит. 1/4 многовато.
Может 1/4 маловато по сравнению 1/1. Ну не знаю, я просто пропорционально увеличил дефолтные размеры до нужных значений и там как раз 1/4.
http://i.piccy.info/i9/be5586091d4a1b02ff07add150881ba1/1509090818/52555/1191...
Исходная версия fet4, :
conntrack -C в момент проблемы показывает те же самые показатели, которые начинают падать из-за потери производительности. Т.е. скачков количества сессий нет.
В логах ВСЕ чисто. Максимум что видно в момент проблемы, вчера например.
Oct 26 18:29:13 fibernet-router kernel: [163086.225243] perf: interrupt took too long (2502 > 2500), lowering kernel.perf_event_max_sample_rate to 79750
pps в районе 100Kpps. Так же скачков нет и начинает падать в момент.
A dnat_post -m set --match-set snat06 dst,dst -j SNAT --to-source 172.19.0.6Так и сделаю, люблю связку ipset+iptables, почему-то сам не увидел такую оптимизацию)))
Я бы начал с поиска «виновника» - т.е. того кто создает очень много соединений ( через -m connlimit --connlimit-above ... )
А можно ли как-то посмотреть количество сессий не общее а по ip?
Через -m connlimit --connlimit-above интересно какое выбрать значение, что есть нормальное для обычного хомяка? Может вообще просто зарезать количество сессий с одного ip?
Возможно кто-то внутри «досит».
Перед маршрутизатором стоит еще BRAS для pppoe/ipoe, ядро постарей конечно. На нем проблемы нет, а если бы досили изнутри должно было бы так же вылезти ?! conntrack на нем так же не отключен, отличие разве что в нате и мангл балансировке.
Кстати
bras# conntrack -C
81268
nat# conntrack -C
267003
Ну бородатые рекомендации говорят, что хеш к макс надо ставить 1/1, если память позволит. 1/4 многовато.
Ну не знаю, я просто пропорционально увеличил дефолтные размеры до нужных значений и там как раз 1/4.
http://i.piccy.info/i9/be5586091d4a1b02ff07add150881ba1/1509090818/52555/1191...