Перейти к содержимому
Калькуляторы
Блокировка веб ресурса  

566 пользователей проголосовало

  1. 1. Для блокировка используем



Блокировка сайтов провайдерами маневры с DNS

extfilter> show acl
show acl
ACL for ip:port blocking: /usr/local/rkn/extFilter/data/hosts
ACL for SSL ip blocking:
ACL for notification:

 

 

ACL SSL ip blocking так и должно быть пустым ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Чет начал в oom падать при старте на машине, с 16 гигами памяти. Увеличил hugepage  с 8 до 12 гигов - не помогло. На машинах где больше 16 гигов пока не наблюдается.

Как считать необходимое количество памяти? При текущем количестве  ip от 16 гигов, то соответственно если будет больше 2 млн то нужно больше 32 гигов?

Изменено пользователем swsn

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

49 минут назад, swsn сказал:

Чет начал в oom падать при старте на машине, с 16 гигами памяти. Увеличил hugepage  с 8 до 12 гигов - не помогло. На машинах где больше 16 гигов пока не наблюдается.

Как считать необходимое количество памяти? При текущем количестве  ip от 16 гигов, то соответственно если будет больше 2 млн то нужно больше 32 гигов? 

 

я так понимаю, что чем больше рабочих, тем больше памяти необходимо. Каждый worker подгружает (вроде бы) независимо все acl на себя.

Плюс scale отжирает в среднем по 1.2гига памяти. Scale = 1 - 1.2, 2 - 2.4 и т.д. Из описания видел, что на 1гбит/с трафика - scale = 1 и т.д.

Определённо ещё виляет:

fragmentation_ipv4_state = true
fragmentation_ipv4_table_size = 512
fragmentation_ipv6_state = false
fragmentation_ipv6_table_size = 512

 

Самому интересно было какие параметры на что влияют...

Может быть Максим ответит на эти вопросы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@aalexanderr дело в том что я уже попытался все отключить/уменьшить ,все равно не лезет в 16 гигов 1185500 айпишников

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@swsn у меня позавчера, когда я убрал кваггу и перешёл на hosts тоже с 16 гигами падало при наличии 6 воркеров, scale = 5, выделено было 16 гигов оперативы на hugepages. Запускался нормально, но через 50 минут падал. Пришлось выделить 20. Сейчас живёт и не падает.

 

Было бы неплохо если бы кто-нибудь объяснил как используется память и что влияет на её потребление - какие параметры.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

7 часов назад, aalexanderr сказал:

@swsn у меня позавчера, когда я убрал кваггу и перешёл на hosts тоже с 16 гигами падало при наличии 6 воркеров, scale = 5, выделено было 16 гигов оперативы на hugepages. Запускался нормально, но через 50 минут падал. Пришлось выделить 20. Сейчас живёт и не падает.

 

Было бы неплохо если бы кто-нибудь объяснил как используется память и что влияет на её потребление - какие параметры.

Нет у меня на подгрузке acl вылетает независимо от количества hp, не хватает общего объема  памяти в размере 16 гигов

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 hours ago, swsn said:

Нет у меня на подгрузке acl вылетает независимо от количества hp, не хватает общего объема  памяти в размере 16 гигов

У меня мониторинг начал ругаться на использование памяти процессом.

Триггер стоял на 200 мегабайт, срабатываний не было.

После перехода на фильтрацию blocktype=ip с зеркала, срабатывания триггера вызывались потреблением в районе 6.9-7.1 гигабайт в момент обновления списков.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

16 минут назад, atdp03 сказал:

У меня мониторинг начал ругаться на использование памяти процессом.

Триггер стоял на 200 мегабайт, срабатываний не было.

После перехода на фильтрацию blocktype=ip с зеркала, срабатывания триггера вызывались потреблением в районе 6.9-7.1 гигабайт в момент обновления списков.

А сейчас как с потреблением в момент обновления? У меня oom начались вчера вечером

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

22 minutes ago, swsn said:

А сейчас как с потреблением в момент обновления? У меня oom начались вчера вечером

Так и продолжается дикими всплесками. Но у меня 32 гига на машине, мне не особо критично пока.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

14 минут назад, atdp03 сказал:

Так и продолжается дикими всплесками. Но у меня 32 гига на машине, мне не особо критично пока.

Снизил hp до 6 гигов , начало влезать. Надо конечно тоже для боевых серверов снмп трап написать , чтоб контролировать ситуацию) 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Исправлен алгоритм по созданию ACL, что привело к снижению потребления памяти при обработке данных из hosts файла. Изменения на github'е.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

22 минуты назад, max1976 сказал:

Исправлен алгоритм по созданию ACL, что привело к снижению потребления памяти при обработке данных из hosts файла. Изменения на github'е.

А какие нибудь дополнительные требования есть к конфигурации?

у меня просто на тестовой машине все также 7 гигов в момент подгрузки потребляет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 час назад, swsn сказал:

А какие нибудь дополнительные требования есть к конфигурации?

у меня просто на тестовой машине все также 7 гигов в момент подгрузки потребляет.

О какой памяти идет речь? Hugepages?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

8 минут назад, max1976 сказал:

О какой памяти идет речь? Hugepages?

Про resident, в момент подгрузки правил. Или фикс касался чего-то другого?

 ext.thumb.png.ba7233a7b10ce1668cdb67569980043c.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 минуты назад, swsn сказал:

Про resident, в момент подгрузки правил. Или фикс касался чего-то другого?

Исправление относится к ACL.

На последней сборке с github у меня так:

Цитата

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
29880 root      15  -5 16,495g  95020   3388 S 300,0  0,3 350:50.61 extFilter

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

10 минут назад, max1976 сказал:

Исправление относится к ACL.

На последней сборке с github у меня так:

 

Во момент обычной работы у меня тоже так.

Как организованна работа в момент перечитывания конфига hosts? Грузит в res а потом переносит hugepages?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 час назад, swsn сказал:

Как организованна работа в момент перечитывания конфига hosts? Грузит в res а потом переносит hugepages?

Да, все загружается в память, затем передается в dpdk для создания ACL. Память потребляется именно в момент обработки внутри dpdk.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

14 часов назад, max1976 сказал:

Да, все загружается в память, затем передается в dpdk для создания ACL. Память потребляется именно в момент обработки внутри dpdk.

Ясно.Мне просто непонятен тот момент что в момент создания ACL RES прыгает до 7 гигабайт хотя в логе:

Used 201326592 bytes of memory for acl4 rules (1203904 entries)

В итоге при hugepages 8gb на машине с 16gb памяти срабатывает OOM killer

Хочется как-то уметь прогнозировать рост этих скачков в увеличением размера файла hosts чтобы вовремя памяти докупить)

Изменено пользователем swsn

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

DPDK ACL задействует большой объем памяти для быстрой работы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я упростил ACL, убрав проверку по ip и порту источника. Это позволило уменьшить объем потребляемой памяти. Измненение опубликовано на githubе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый днеь, напомните пожалуйта, блокировка по IP работает только при работе в inline режиме?

Или в режиме заркала rst тоже будут отсылаться?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 час назад, epollia сказал:

Или в режиме заркала rst тоже будут отсылаться?

Тоже отправляется. Блокируется только tcp. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В dpdk 17.05.1 наблюдается проблема с ACL при задании разного диапазона портов в ACL. Поэтому на github выложено обновление extfilter, которое для всех блокируемых ip адресов, вне зависимости от заданного порта в hosts, задает диапазон с 0 по 655355 порт.

P.S. Именно из-за этого бага в dpdk до этой правки был большой расход памяти под ACL.

Изменено пользователем max1976

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 часа назад, max1976 сказал:

В dpdk 17.05.1 наблюдается проблема с ACL при задании разного диапазона портов в ACL. Поэтому на github выложено обновление extfilter, которое для всех блокируемых ip адресов, вне зависимости от заданного порта в hosts, задает диапазон с 0 по 655355 порт.

P.S. Именно из-за этого бага в dpdk до этой правки был большой расход памяти под ACL.

 

Спасибо, обновился. Расход 600мб при формировании acl

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день.

Есть подозрение что extfilter не обновляет списки по HUP.

После полного restart списки подгружаются полностью.

С чем может быть связанно?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.