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

polmax

Пользователи
  • Публикации

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

  • Посещение

Сообщения, опубликованные пользователем polmax


  1. В 22.04.2019 в 22:13, jffulcrum сказал:

    MSI-X попробуйте выключить (hw.pci.enable_msix=0)

    И как это должно было помочь? Проверил, по моему вообще стало грузить только 1 ядро :)

    В общем решил проблему просто:

    Установил: /usr/ports/net/intel-ix-kmod

     

    в loader.conf:

     

    Цитата

    if_ix_updated_load="YES"

    И теперь 12 по распределению ведёт себя так же как 11 версия.

     

    И да всё же 12 пока не советую ставить, падения в кору случаются, причём на пустом месте, баг репорт пестрит этими сообщениями.

  2.  

    В 07.05.2019 в 20:56, doubtpoint сказал:

    Спасибо ответившим.

    Число ядер с гипертредингом 12.

    Решилось 

    
    dev.ix.0.iflib.override_nrxqs=12
    dev.ix.0.iflib.override_ntxqs=12

     

    А что показывает: top -aSIHP
    нагрузка по ядрам распределилась?

  3. Что намудрили в FreeBSD 12? 

    Я так понял что теперь крутится всё через iflib, но при дефолтных настройках из 2 процессоров теперь  используется только один, в топе вижу примерно следующее:
     

    Скрытый текст

    last pid: 22997;  load averages:  2.37,  2.55,  2.49                                                                                                                                                                 up 0+07:05:28  19:44:09
    620 threads:   19 running, 544 sleeping, 57 waiting
    CPU 0:   0.0% user,  0.0% nice, 33.3% system,  0.0% interrupt, 66.7% idle
    CPU 1:   1.6% user,  0.0% nice, 19.4% system,  0.0% interrupt, 79.1% idle
    CPU 2:   1.6% user,  0.0% nice, 17.1% system,  0.0% interrupt, 81.4% idle
    CPU 3:   1.6% user,  0.0% nice, 23.3% system,  0.0% interrupt, 75.2% idle
    CPU 4:   0.0% user,  0.0% nice, 24.0% system,  0.0% interrupt, 76.0% idle
    CPU 5:   0.0% user,  0.0% nice, 28.7% system,  0.0% interrupt, 71.3% idle
    CPU 6:   0.0% user,  0.0% nice, 25.6% system,  0.0% interrupt, 74.4% idle
    CPU 7:   0.0% user,  0.0% nice, 24.0% system,  0.0% interrupt, 76.0% idle
    CPU 8:   0.8% user,  0.0% nice,  4.7% system,  0.0% interrupt, 94.6% idle
    CPU 9:   0.8% user,  0.0% nice,  0.8% system,  0.0% interrupt, 98.5% idle
    CPU 10:  1.3% user,  0.0% nice,  1.3% system,  0.6% interrupt, 96.8% idle
    CPU 11:  0.0% user,  0.0% nice,  3.1% system,  0.0% interrupt, 96.9% idle
    CPU 12:  0.8% user,  0.0% nice,  4.6% system,  0.0% interrupt, 94.7% idle
    CPU 13:  0.0% user,  0.0% nice,  4.5% system,  0.0% interrupt, 95.5% idle
    CPU 14:  0.0% user,  0.0% nice,  0.8% system,  0.0% interrupt, 99.2% idle
    CPU 15:  1.5% user,  0.0% nice,  5.3% system,  0.0% interrupt, 93.2% idle
    Mem: 111M Active, 394M Inact, 3254M Wired, 665M Buf, 27G Free
    ARC: 696M Total, 128M MFU, 124M MRU, 288K Anon, 4809K Header, 439M Other
         41M Compressed, 211M Uncompressed, 5.18:1 Ratio
    Swap: 4096M Total, 4096M Free

      PID USERNAME    PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
       11 root        155 ki31      0   256K CPU10   10 407:22 100.00% [idle{idle: cpu10}]
       11 root        155 ki31      0   256K CPU13   13 406:13  99.40% [idle{idle: cpu13}]
       11 root        155 ki31      0   256K CPU14   14 405:39  99.08% [idle{idle: cpu14}]
       11 root        155 ki31      0   256K CPU9     9 407:45  98.99% [idle{idle: cpu9}]
       11 root        155 ki31      0   256K CPU8     8 414:26  97.31% [idle{idle: cpu8}]
       11 root        155 ki31      0   256K RUN     15 405:16  96.85% [idle{idle: cpu15}]
       11 root        155 ki31      0   256K CPU12   12 406:41  96.26% [idle{idle: cpu12}]
       11 root        155 ki31      0   256K RUN     11 407:08  95.45% [idle{idle: cpu11}]
       11 root        155 ki31      0   256K CPU2     2 352:19  80.28% [idle{idle: cpu2}]
       11 root        155 ki31      0   256K CPU1     1 350:32  77.45% [idle{idle: cpu1}]
       11 root        155 ki31      0   256K RUN      3 352:01  76.41% [idle{idle: cpu3}]
       11 root        155 ki31      0   256K CPU4     4 349:27  74.74% [idle{idle: cpu4}]
       11 root        155 ki31      0   256K CPU5     5 351:07  73.20% [idle{idle: cpu5}]
       11 root        155 ki31      0   256K CPU7     7 343:33  72.37% [idle{idle: cpu7}]
       11 root        155 ki31      0   256K CPU6     6 350:32  71.73% [idle{idle: cpu6}]
       11 root        155 ki31      0   256K CPU0     0 329:45  65.72% [idle{idle: cpu0}]
        0 root        -76    -      0  6160K -        6  69:09  26.13% [kernel{if_io_tqg_6}]
        0 root        -76    -      0  6160K -        7  76:12  25.86% [kernel{if_io_tqg_7}]
        0 root        -76    -      0  6160K -        5  68:41  24.98% [kernel{if_io_tqg_5}]
        0 root        -76    -      0  6160K -        0  70:12  23.79% [kernel{if_io_tqg_0}]
        0 root        -76    -      0  6160K -        4  70:26  23.38% [kernel{if_io_tqg_4}]
        0 root        -76    -      0  6160K -        3  67:54  21.41% [kernel{if_io_tqg_3}]
        0 root        -76    -      0  6160K -        1  69:21  20.91% [kernel{if_io_tqg_1}]
        0 root        -76    -      0  6160K -        2  67:36  17.84% [kernel{if_io_tqg_2}]
        0 root        -92    -      0  6160K -        0  25:59  12.64% [kernel{dummynet}]
     

     

    Сетевые ix (Intel(R) PRO/10GbE PCI-Express Network Driver) 

  4. @IPaddress.ru @ipaddr.ru Как долго занимает процесс переноса с одного Лира на другой, просто тоже зареганы у netup и получается срок до отбора ип уже меньше 2 месяцев. Хотелось бы узнать какова процедура, сколько по времени и что по оплате, ссылок на сайт не надо, хочется информации из первых уст. Спасибо.

  5. В 18.02.2019 в 14:07, gosti96admin сказал:

    используется для того чтобы Натить и Полосить абонентов

    В момент проблемы посмотрите, сколько у вас соединений ната, недавно тоже наткнулись на такую проблему, один юзер (вируса) по 445 порту открывал до 70к соединений, и системе становилось очень плохо. А и да, если используется ipfw nat, попробуйте убрать опцию same_ports (это в том случает если проблема именно с натом)

     

    И ещё заметил в 11.2 версии прибитие dummynet к нулевому ядру не дает визуального результата как раньше, он теперь всегда показывает нагрузку на dummynet, примерно так:

    0 root       -92    -     0K  6128K -       0 706:54  12.49% kernel{dummynet}

     

  6. В 02.02.2019 в 20:27, default_vlan сказал:

    Подскажите, как обновить фриху с 10.3 до 12 версии. 

    Не советую обновляться до 12 версии, есть шанс словить: can't find '/boot/entropy'. Лучше всего устанавливать с нуля и на новый диск, если в случае чего вернуть старый диск на место, так как есть шанс что и с нуля 12 версия не взлетит, что-то они там с загрузчиком перемудрили, хотя патчи вроде уже есть, но не в релизе. Поставьте 11.2, у него вроде поддержка до 2021 года, а к тому времени уже и 12 допилят :)

     

    freebsd-update -r 11.2-RELEASE upgrade

     

  7. В нашем биллинге так же сделано, если есть деньги то списываем 1 числа, если денег нет то блокируем, как только внесли оплату - списываем абонентскую плату до конца месяца (без учёта дней, часов, минут  прошедших от 1 числа до момента разблокировки). И никаких проблем нет. 1 число остаётся расчётным всегда. А абонентская плата меняется в зависимости от времени выхода из блокировки.

  8. 54 минуты назад, Kolunchik сказал:

    polmax

    max-udp-size не пробовали на бинде крутить?

    Конечно пробовал, при превышении этого параметра, пакет начинает бегать по tcp, вместо udp. При первом запросе если пакет превышает параметр указаный в max-udp-size, возвращает клиенту: Message is truncated, клиент пытается уже получить данные по tcp, а TP-Link походу этого уже не умеет.

     

    9 часов назад, st_re сказал:

    клиент (в вашем случае ТПлинк) должен свичнуться на tcp

    Судя по tcpdump, клиент на андроиде делает тоже самое, он делает запрос у TP-Link по udp, ничего от него не получает, потом пытается послать запрос по tcp, а TP-Link уже походу этого не умеет и всё приехали.

     

    9 часов назад, st_re сказал:

    но это оттянет проблему, отрезав доп. поля в ответе, а не решит. Написать 1000 А записей на 1 имя можно легко.

    Об том я и писал, что это временное решение, и возможно что уже есть какие то домены которые не пролазят, просто они не так популярны как гугл.

  9. Ivan_83 как всегда в своём репертуаре, лишь бы всех говном полить. Раз такой спец подсказал бы как порезать на unbound и bind ответ так чтобы пролезал на мыльницах.

  10. 3 часа назад, kirush сказал:

    У меня например провайдер Онлайм, IpoE , динамика , MTU 1500 на 841 v7 , v13 - никаких проблем с 2013 года по сей день

    Дак и не было никаких проблем, пока пакет пролазил, а сейчас очень много обращений пользователей у разных провайдеров именно с роутерами TP-Link + приложения на андроиде гугл Маркет, Youtube и проблема у всех одна: выдаёт ошибку что нет связи. Всех проблемных клиентов объединяет роутер TP-Link причём разных марок, MTU у всех клиентов разные и разные способы подключения (IPoE, PPTP), причём у тех у кого MTU 1500, проблема тоже есть.

  11. minimal-responses yes; 

    Это временно решение, добавит гугл ещё пару записей и МТУ (размер пакета) станет выше 1500 и всё, проблему уже не решить этим параметром, если только каким то образом выдавать своим днс не все записи, а например всего 5.

  12. Только что, kirush сказал:

    TPLINK предложил с MTU поиграться.

    Только я так понимаю мту это затрагивает пакеты которые проходят через роутер, а не предназначенные роутеру, ибо проблема когда роутер выступает DNS сервером, если указать сервер DNS например свой (провайдера) на прямую на клиенте (или выдавать его через DHCP), то пакеты без "minimal-responses yes;" норм начинают бегать.

  13. kirush держите в курсе решения вопроса через поддержку TP-Link, ибо тоже недавно столкнулись с такой проблемой, видать гугл добавил новых пару записей, проблема началась где то после 13 ноября.

  14. Может глянуть в сторону: Преобразование значений, создать своё в котором 999 -> 0. Сам не пробовал.

  15. P.S. И вообще, начиная с 10-ки, mpd стал плохо уживаться с ОС..

    Посему везде, где юзаю mpd, выше 9.3 не поднимался.

    Говорят, на днях пофиксили всё (перешли на новые библиотеки), вроде пашет.

  16. А так же владельцев, впн и анонимайзеров, блокировать сайты из реестра, а не операторов. Вы бы хоть законопроекты читали сначала, чем шум поднимать :)

    Попросят, владельца внп блокировать сайты, он по списку запрещает доступ, всё ок, если не захочет, то его в блок, вот тут уже попадает в списки к операторам.

    Но всё равно, они уже надоели со своими блокировками, запретили бы уже всё и оставили в доступе несколько угодных сайтов.

  17. https://rkn.gov.ru/news/rsoc/news46262.htm

    А вот и новости от РКН подъехали, это не они виноваты, а уроды провайдеры, которые не правильно блокируют.

    Теперь есть рекомендации:

    "В частности, при самостоятельном определении оператором связи IP-адреса запрещенного интернет-ресурса, провайдерам рекомендовано проверять, не попадут ли под блокировку популярные и общественно значимые сайты и их IP-адреса ."

    Маразм крепчал.

     

    Всё просто: резолвим, получаем IP адреса, проверяем эти IP, а не принадлежат ли они хорошим сайтам? (тут наверное и должны быть белые списки, али же содержать базу всех ресурсов интернет, в связке: IP - домен :))) ).

  18. А то так можно из-за небольшого сбоя или перегруза в минуту на фильтрующем железе попасть на штраф с этими 0.5%

    Я понять не могу о каких, вы 0.5 и 1%, говорите, на нас за 1 пропуск сразу дело в суд подали (уже 2 раза, один раз как раз ревизор зафиксировал урл в момент перегрузки правил, 2 раз из-за сбоя на пограничном маршрутизаторе, трафик не переправлялся минут 10), пока правда всё предупреждением отделывались, но это пока, а так от 50 до 100к, причём по закону вас могут штрафовать хоть каждый день. Нам так и сказали по закону доступ должен быть запрещён, никаких допусков вообще нет, то есть 100%.