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

atdp03

Активный участник
  • Публикации

    113
  • Зарегистрирован

  • Посещение

О atdp03

  • Звание
    Студент
    Студент

Контакты

  • ICQ
    Array

Посетители профиля

Блок посетителей профиля отключен и не будет отображаться другим пользователям

  1. Добрый всем. Две одинаковых по железу и софту машинки, с различающимся вдвое уровнем трафика, начали подсыпать пропуски. В логах из аномалий такое: 2022-05-22 11:28:47.717 [28895] Error ESender - Can't send packet. Buffer is full. 2022-05-22 11:28:47.717 [28895] Error ESender - Can't send packet. Buffer is full. 2022-05-22 11:29:07.826 [28895] Error ESender - Can't send packet. Buffer is full. 2022-05-22 11:29:07.827 [28895] Error ESender - Can't send packet. Buffer is full. Режим зеркала, разные локации, разные свичи. Я один такой везучий?
  2. Так и продолжается дикими всплесками. Но у меня 32 гига на машине, мне не особо критично пока.
  3. У меня мониторинг начал ругаться на использование памяти процессом. Триггер стоял на 200 мегабайт, срабатываний не было. После перехода на фильтрацию blocktype=ip с зеркала, срабатывания триггера вызывались потреблением в районе 6.9-7.1 гигабайт в момент обновления списков.
  4. Перепроверился. Это был старый бинарник. На новом греп ничего не возвращает вообще. Единственное из этой области в логе: 2019-10-12 00:47:36.802 [16288] Information ACL - Building ACL from file /root/reestr/extfilter/configs/hosts UPD: послал -HUP процессу, конфиг влился, заработал.
  5. Ругается, да: 2019-10-11 23:52:02.779 [7328] Information ACL - Preparing 1061560 rules for IPv4 ACL 2019-10-11 23:52:02.816 [7328] Information ACL - Preparing 50 rules for IPv6 ACL 2019-10-11 23:52:02.822 [7328] Error ACL - Setup acl for ipv4 with socketid 0 failed, keeping previous rules for that socket 2019-10-12 00:32:04.250 [7328] Information ACL - Preparing 1061560 rules for IPv4 ACL 2019-10-12 00:32:04.287 [7328] Information ACL - Preparing 50 rules for IPv6 ACL 2019-10-12 00:32:04.294 [7328] Error ACL - Setup acl for ipv4 with socketid 0 failed, keeping previous rules for that socket Чего-то не хватает?
  6. А как бы это подебажить? Обновил фильтр, ресетов не вижу. в hosts 22 мегабайта такого: 217.69.14.132/32, 6/0xfe 217.69.14.176/32, 6/0xfe 217.69.15.108/32, 6/0xfe 217.69.15.223/32, 6/0xfe ресетов не вижу. Редиректы на http и ресеты на https прилетают исправно. В логе: All worker threads matched by ip/port: 0 Плюс, перестаёт блочиться такое как https://18.200.8.105:16869/. Откатываюсь на предыдущую работавшую версию, от августа 18го, этот адрес начинает ресетиться.
  7. А кто-нить заводил rest api на ASR1000? Поддержка 100*-x согласно сайту появилась с версии 3.14. У нас в бою версия 3.13, которую сильно не хочется обновлять. Ключевой вопрос - насколько можно запускать контейнер из свежих версий на старом иосе?
  8. Есть ли жизнь на Марсе? Есть пара 7600, с указанным Rsp. Есть 3-4 full-view, 3-4 обменника, от 30 до 170к префиксов. Есть пяток приватных пиров от нескольких десятков до нескольких десятков тысяч префиксов. Есть стопка даунлинков с full-view, плюс несколько с дефолтом. Пока всё нормально - оно работает. Но стоит чихнуть кому-то крупному - начинается цепная реакция. Начинают сыпаться по таймаутам остальные сессии, мрёт по таймаутам ospf, короче полный набор удовольствий. Единственный шанс стабилизировать ситуацию - перегасить почти всё, дождаться стабилизации, и потом поштучно включать всё обратно, дожидаясь прожёвывания маршрутов. Понятно, что железке пора на пенсию. Однако процесс это небыстрый, и хотелось бы понять: есть ли шанс хоть как-то снизить нагрузку? Порезать принимаемые анонсы до минимум /24? В прилетающих маршрутах мелочь так и останется, и экономия проца будет только на этапе невнесения в tcam (сам вопрос tcam не рассматриваем, там всё нормально). Выкручивать таймауты? А оно действительно надо? При реальной смерти пира держать лишнее время маршруты в никуда? Требуется помощь коллективного разума.
  9. И можно сразу костыли, реагирующие на попадание адресов ipv6 в другие теги. =)
  10. Стерильно: 2018-09-04 19:03:56.150 [1440] Information Application - Port 1 input packets 8115511114, input errors: 0, mbuf errors: 0, missed packets: 0 Собственно, там и было стерильно, но фантомные пропуски были - тупо прокликиваю раз 20 одну и ту же ссыль - раз 8 открывается, остальное блочится. В отчётах ревизора - рандомные пропуски, каждый день разные, штук по 200. После подъёма числа очередей с 2х до 3х - пропуски исчезли. При этом scale - закомментировано.
  11. Логично, не подумал. Единственное существенное отличие между старой и новой системами - 16.04 и 18.04.
  12. Можно подвести промежуточные итоги. Старая система: Xeon 1270v3+16G, extfilter от 2 февраля 2018. Новая: Xeon 1270v5+32G, extfilter от 30го августа 2018. Сетевухи идентичны, зеркало то же. Старая машина жевала объём в один поток (num_of_workers=1). Новой понадобилось 3, чтобы избавиться от фантомных пропусков. По факту сделал 4, с запасом. core_mask = 31 [port 1] queues = 0,1; 1,2; 2,3; 3,4
  13. Авоткстати. Есть примерные рекомендации? Типа: 100-500-1000к пакетов в секунду на входе, M (физических?) ядер по N Ghz, P гигабайт памяти, Q из них под hugepages, X очередей в extfilter, scale = Y, memory_channels = Z.
  14. Да, подтверждаю. Браузер закешировал, как и упоминавшееся ранее: