Перейти до

FreeBSD hi loading CPU


Рекомендованные сообщения

День добрый, имеется:
9.2-RELEASE #0: Sun May 18 03:42:49 EEST 2014 /usr/obj/usr/src/sys/ROUTER  i386
Суть проблемы: иногда, загрузка проца подымается до возможных 100% (проц кстати двухядерка пень 4).
Так вот если верить показанию топа - нагрузка растёт именно из-за прерываний на внешней сетевой карте (менять пробовал, эфект тот-же).
Но vmstat -i в норме.

Вот примерно следующее видно:

last pid: 22409;  load averages:  0.52,  0.50,  0.30                                                                                                                   
128 processes: 3 running, 109 sleeping, 16 waiting
CPU:  0.0% user,  0.0% nice,  5.5% system, 27.2% interrupt, 67.3% idle
Mem: 108M Active, 80M Inact, 129M Wired, 132K Cache, 73M Buf, 1543M Free
Swap: 4096M Total, 4096M Free
 
 
 PID USERNAME  PRI NICE   SIZE    RES STATE   C   TIME    CPU COMMAND
   11 root      155 ki31     0K    16K RUN     0   7:38 88.28% idle{idle: cpu0}
   12 root      -72    -     0K   128K CPU1    1   2:46 50.05% intr{swi1: netisr 1}
   11 root      155 ki31     0K    16K RUN     1   5:21 47.36% idle{idle: cpu1}
   12 root      -72    -     0K   128K WAIT    0   0:24  6.01% intr{swi1: netisr 0}
    0 root      -92    0     0K    96K -       0   0:11  2.54% kernel{em1 taskq}
    0 root      -92    0     0K    96K -       1   0:15  0.63% kernel{em0 taskq}
interrupt                          total       rate
irq16: xhci0 ehci0                   891          1
irq19: atapci0+                     4995          8
irq23: ehci1                         893          1
cpu0:timer                       1216146       2122
irq256: em0                      2221212       3876
irq257: em1                      1758013       3068
irq258: hdac0                         41          0
cpu1:timer                       1187698       2072
Total                            6389889      11151

Ну это моменты когда нагрузка растёт и машина с ней справляется.

А бывают моменты когда машина просто в кору падает и всё. Поэтому данных что происходит тогда привести не могу.

Но то что я на скорую руку смотрел в принципе vmstat -i ничего криминального не показывает.

Какие будут идеи?

Может чего сильно в sysctl перекрутил?

kern.ipc.nmbclusters=60000
kern.ipc.somaxconn=8192
kern.ipc.maxsockets=204800
net.inet.udp.maxdgram=57344
net.inet.ip.portrange.first=1024
net.inet.ip.portrange.randomized=0
net.inet.tcp.nolocaltimewait=1
net.inet.ip.forwarding=1
net.inet.ip.fastforwarding=1
net.inet.icmp.bmcastecho=0
net.inet.ip.ttl=64
net.inet.tcp.drop_synfin=1
net.inet.tcp.syncookies=1
net.inet.ip.dummynet.expire=1
net.inet.ip.fw.dyn_buckets=2048
net.inet.tcp.maxtcptw=40960
kern.ipc.maxsockbuf=16777216
net.inet.tcp.recvspace=262144
net.inet.ip.intr_queue_maxlen=8192
net.inet.ip.dummynet.io_fast=1
net.inet.ip.dummynet.hash_size=1024
net.inet.ip.dummynet.pipe_slot_limit=1000
kern.maxfilesperproc=200000
kern.ipc.shmmax=67108864
net.inet.tcp.rfc3390=0
net.inet.ip.fw.autoinc_step=1
net.inet.tcp.blackhole=2
net.inet.icmp.maskrepl=1
net.inet.udp.blackhole=1
net.link.ether.inet.max_age=30
net.inet.tcp.sendspace=262144
net.inet.tcp.recvbuf_inc=524288
net.inet.tcp.sendbuf_inc=524288
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
net.inet.ip.random_id=1
net.inet.ip.rtexpire=60
net.inet.ip.rtminexpire=2
net.inet.ip.rtmaxcache=1024
net.inet.icmp.drop_redirect=1
net.inet.ip.redirect=0
kern.maxfiles=204800
net.inet.tcp.delayed_ack=0
dev.em.0.rx_int_delay=200
dev.em.0.tx_int_delay=200
dev.em.1.rx_int_delay=200
dev.em.1.tx_int_delay=200
dev.em.2.rx_int_delay=200
dev.em.2.tx_int_delay=200
dev.em.3.rx_int_delay=200
dev.em.3.tx_int_delay=200
net.graph.recvspace=8388608
net.graph.maxdgram=8388608
net.inet.icmp.icmplim=200
net.inet.udp.recvspace=262144
kern.random.sys.harvest.ethernet=0
kern.random.sys.harvest.interrupt=0
kern.random.sys.harvest.point_to_point=0
net.inet.ip.fw.dyn_buckets=16384
net.inet.ip.fw.dyn_max=65535
kern.ipc.shmall=128000000         
net.inet.tcp.msl=15000   
dev.em.0.rx_abs_int_delay=4000
dev.em.0.tx_abs_int_delay=4000
dev.em.1.rx_abs_int_delay=4000
dev.em.1.tx_abs_int_delay=4000
dev.em.2.rx_abs_int_delay=4000
dev.em.2.tx_abs_int_delay=4000
dev.em.3.rx_abs_int_delay=4000
dev.em.3.tx_abs_int_delay=4000
dev.em.0.rx_processing_limit=4096
dev.em.1.rx_processing_limit=4096
dev.em.2.rx_processing_limit=4096
dev.em.3.rx_processing_limit=4096
net.route.netisr_maxqlen=4096
net.inet.ip.intr_queue_maxlen=10240
net.isr.dispatch=deferred
net.link.bridge.pfil_onlyip=0
net.link.bridge.pfil_member=1
net.link.bridge.pfil_bridge=0
net.link.bridge.pfil_local_phys=0
net.link.bridge.ipfw=0
net.link.bridge.ipfw_arp=0
net.inet.tcp.mssdflt=1460
net.inet.tcp.syncache.rexmtlimit=0
net.inet.tcp.icmp_may_rst=0
vfs.read_max=128
security.bsd.see_other_uids=0
security.bsd.see_other_gids=0
vfs.ufs.dirhash_maxmem=16777216
net.raw.recvspace=65534
net.raw.sendspace=65534
net.inet.raw.maxdgram=65534
net.inet.raw.recvspace=65534
kern.ipc.shm_use_phys=1

Да и в sockstat никакого криминала нет... Уже извёлся незнаю чего и думать :(

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 249
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

2 KaYot    

Загалом про "сервер падає від пінгу", дуже нагадало  

это тоже пофиг. deny_in для начала ткните и посмотрите на результат.

Posted Images

Сетевухи аж 3, одна двух портовая inter pro/1000 pt dual port server adapter а ещё 2 на чипе device = '82574L Gigabit Network Connection', если верить pciconv -lv.

Нагрузки не очень большие порядка 70-80кппс и 150 мегабит. В час пик загрузка проца - максимум 35%, при нормальных условиях.

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

Сетевухи аж 3, одна двух портовая inter pro/1000 pt dual port server adapter а ещё 2 на чипе device = '82574L Gigabit Network Connection', если верить pciconv -lv.

Нагрузки не очень большие порядка 70-80кппс и 150 мегабит. В час пик загрузка проца - максимум 35%, при нормальных условиях.

 

выкидывате эти, ставьте с чипом не менее 82576.

На моей практике все сетевухи подобные вашей начинали дохнуть при 12к ппс и окончательно дохли при 18к.

Никакими тьюнингами и "яндексовскими" драйверами проблема не устранялась. Яндексовские дрова максимум что могли - это облегчить жизни на исходящем трафике

 

PS: в моём случае ОС - FreeBSD. На линуксе с 82579 чипом 480к ппс шуршит с 17% нагрузки на проц.

 

ну и посмотрите что именно проц нагружает

 

pmcstat -S instructions -O /tmp/sample.out &

sleep 30 && killall pmcstat

pmcstat -R /tmp/sample.out -g && gprof -l -K INSTR_RETIRED_ANY/kernel |head -n 60 | tail -n 25

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

 

Сетевухи аж 3, одна двух портовая inter pro/1000 pt dual port server adapter а ещё 2 на чипе device = '82574L Gigabit Network Connection', если верить pciconv -lv.

Нагрузки не очень большие порядка 70-80кппс и 150 мегабит. В час пик загрузка проца - максимум 35%, при нормальных условиях.

 

выкидывате эти, ставьте с чипом не менее 82576.

На моей практике все сетевухи подобные вашей начинали дохнуть при 12к ппс и окончательно дохли при 18к.

Никакими тьюнингами и "яндексовскими" драйверами проблема не устранялась. Яндексовские дрова максимум что могли - это облегчить жизни на исходящем трафике

 

PS: в моём случае ОС - FreeBSD. На линуксе с 82579 чипом 480к ппс шуршит с 17% нагрузки на проц.

 

ну и посмотрите что именно проц нагружает

 

pmcstat -S instructions -O /tmp/sample.out &

sleep 30 && killall pmcstat

pmcstat -R /tmp/sample.out -g && gprof -l -K INSTR_RETIRED_ANY/kernel |head -n 60 | tail -n 25

 

Спасибо за подсказку, буду смотреть. Не знаю, как у вас при 18кппс загибалось, у меня всё шуршит аж бегом  :)

Только вот у моей проблемы нет никакой систематики, по крайней мере не было.

Может профайлинг чего покажет...

Совершенно от нагрузки не зависит, только чаще вечером вылетает, но бывает и днем при мизерной нагрузке  :(

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

У меня была фря с 1000 с копейками правил фаервола ( на тот момент ).

После оптимизации фаервола стало несколько полегче, но фиг заставишь клиентов "любимый" провайдерами мюторрент корректно настроить, точнее отключить его фирменный протокол.

 

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

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

 

Совершенно от нагрузки не зависит, только чаще вечером вылетает, но бывает и днем при мизерной нагрузке  :(

 

 

не так давно разработчики интела заметили уязвимость, при которой наступал п@зд#ц при конкретном SIP пакете. Не твой случай?

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

Вот как.... Чтож тогда всё стало понятно, значит будем думать про замену!

Очень благодарен.

Но если сменим карточки и будет та же фигня, с меня начальство шкуру-то снимет :))

Так что жду ещё идей  ;)


 

 

Совершенно от нагрузки не зависит, только чаще вечером вылетает, но бывает и днем при мизерной нагрузке  :(

 

 

не так давно разработчики интела заметили уязвимость, при которой наступал п@зд#ц при конкретном SIP пакете. Не твой случай?

 

Да у меня вообще sip трафик незамечен, и ничего у меня вроде его не использует.

Если не ошибаюсь SIP - для айпи телефонии?

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

А кхм, если вы про это http://habrahabr.ru/post/168607/ - сначала внешняя сетевая была 82574L, а потом, всё переехало на двух портовую серверную.

И была ровно та же жопа...

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

 

 

Но если сменим карточки и будет та же фигня, с меня начальство шкуру-то снимет  :))

 

ну перед апгрейдо сделать профилирование ядра при нагрузке не помешает ;-) Скорее всего перед профилированием прийдётся сделать kldload pmc

блин как-то  не очень звучит команда  :D

 

кстати, посмотри в момент нагрузки top -HSCP и если там много нагрузки на echi  - отключи в биосе юсб

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

Начинать надо с фразы

проц кстати двухядерка пень 4

И дальше можно не продолжать. Отдайте этот хлам в местную школу/общество инвалидов, не мучайте себя.

И все пройдет само собой.

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

Начинать надо с фразы

проц кстати двухядерка пень 4

И дальше можно не продолжать. Отдайте этот хлам в местную школу/общество инвалидов, не мучайте себя.

И все пройдет само собой.

присоединяюсь. I5+intel ET решит вашу проблему.

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

 

Начинать надо с фразы

проц кстати двухядерка пень 4

И дальше можно не продолжать. Отдайте этот хлам в местную школу/общество инвалидов, не мучайте себя.

И все пройдет само собой.

присоединяюсь. I5+intel ET решит вашу проблему.

Че

 

 

Начинать надо с фразы

проц кстати двухядерка пень 4

И дальше можно не продолжать. Отдайте этот хлам в местную школу/общество инвалидов, не мучайте себя.

И все пройдет само собой.

присоединяюсь. I5+intel ET решит вашу проблему.

 

 

 

Чем решит? В кору будет падать чуть попозже? Бред... По теме, дело в картах... поэтому собственно сразу и задал этот вопрос... Хотя, тоже... У нас стоят TP-LINK TG-3468 в количестве 5-ти штук. Та что смотрит в локалку 12-14к держит :)

 

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

Сталкивался пол года назад с такой проблемой, проц 4 ядра ксеон, карта ЕТ. Без явной зависимости загрузка проца росла до 100%, правда сервер не ложился, но тупил страшно.

Тюнинг особо не помог, загрузка просто стала чуть меньше - в районе 50-60%. И всплески реже. Помогла только фильтрация на свичах - кто-то из юзеров вируса словил.

 

Так что не торопитесь менять железо, быстрей всего это Вам ничем не поможет.

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

 

Бред уважаемый это если у вас от 50 кппс сервер в кору падает. По теме, уже давно обоссано и про бсд, и про сетевухи и про сендибридж процы. А количество ппс косвенно позволяет судить о количестве клиентов, что в свою очередь наталкивает на то что люди вполне в состоянии купить нормальную сетевую.

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

 

 

Начинать надо с фразы

проц кстати двухядерка пень 4

И дальше можно не продолжать. Отдайте этот хлам в местную школу/общество инвалидов, не мучайте себя.

И все пройдет само собой.

присоединяюсь. I5+intel ET решит вашу проблему.

Че

 

 

Начинать надо с фразы

проц кстати двухядерка пень 4

И дальше можно не продолжать. Отдайте этот хлам в местную школу/общество инвалидов, не мучайте себя.

И все пройдет само собой.

присоединяюсь. I5+intel ET решит вашу проблему.

 

 

 

Чем решит? В кору будет падать чуть попозже? Бред... По теме, дело в картах... поэтому собственно сразу и задал этот вопрос... Хотя, тоже... У нас стоят TP-LINK TG-3468 в количестве 5-ти штук. Та что смотрит в локалку 12-14к держит :)

 

12k pps это вообще ни о чем. На em легко выжимается до полугига. Гиг на шустрых ядрах/яндекс драйверах.

у ТС включен net.isr Его выключение чуть разгрузит систему. И позволит точнее понять где проблема.

 

rx_int_delay и tx_int_delay можно увеличить до 500. Не забывайте про глюк, когда эти параметры реально применяются только на второй раз их применения.

 

покажите netstat -w 1 -I em0/em1/em2 в пиковые моменты загрузки проца

 

Ну и проц сменить. P4 двухядерный - ни о чем.

 

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

День добрый, имеется:

9.2-RELEASE #0: Sun May 18 03:42:49 EEST 2014 /usr/obj/usr/src/sys/ROUTER  i386

Суть проблемы: иногда, загрузка проца подымается до возможных 100% (проц кстати двухядерка пень 4).

Так вот если верить показанию топа - нагрузка растёт именно из-за прерываний на внешней сетевой карте (менять пробовал, эфект тот-же).

Возможно спам на порт 6881. Сделайте tcpdump или сразу добавьте в файерволл правило 

count ip from any to me dst-port 6881 in limit dst-addr 500

и понаблюдайте.

 

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

Это эпидемия какая-то, теже яйца, только FreeBSD 8.4, процессор Dual Core G2020 2.9GHz/5GT/s/3MB (BX80637G2020) s1155 BOX, сетевая ET двухголовая, нет систематики никакой, но обычно вечером, все один в один как у ТС... хз что делать

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

post-17807-0-78619500-1400745097_thumb.jpg

post-17807-0-90556600-1400745191_thumb.jpg

 

Почему так неизвестно.

Відредаговано BARVIT
Ссылка на сообщение
Поделиться на других сайтах
00005 fwd 127.0.0.1,80 ip from 172.32.0.0/20 to not me dst-port 80

00006 fwd 127.0.0.1,80 ip from table(47) to not me dst-port 80

00007 allow ip from table(2) to 82.117.226.38 via igb1.300

00007 allow ip from 82.117.226.38 to table(2) via igb1.300

00008 allow ip from table(2) to 195.64.136.182 via igb1.300

00008 allow ip from 195.64.136.182 to table(2) via igb1.300

06000 nat 1 ip from table(2) to not table(9) via igb0.1607

06001 nat 1 ip from any to 46.164.129.226 via igb0.1607

11000 allow ip from table(3) to 212.72.143.0/24 via igb1.300 in

11001 allow ip from 212.72.143.0/24 to table(4) via igb1.300 out

12000 pipe tablearg ip from table(3) to any via igb1.300 in

12001 pipe tablearg ip from any to table(4) via igb1.300 out

13000 allow ip from any to 10.100.0.1 via igb1.300

13000 allow ip from 10.100.0.1 to any via igb1.300

13001 allow ip from 46.164.129.226 80 to any via igb1.300

13001 allow ip from any to 46.164.129.226 dst-port 80 via igb1.300

65531 deny ip from table(10) to any via igb1.300

65532 deny ip from any to table(10) via igb1.300

65533 deny ip from table(2) to any via igb1.300

65535 allow ip from any to any
Ссылка на сообщение
Поделиться на других сайтах

Это эпидемия какая-то, теже яйца, только FreeBSD 8.4, процессор Dual Core G2020 2.9GHz/5GT/s/3MB (BX80637G2020) s1155 BOX, сетевая ET двухголовая, нет систематики никакой, но обычно вечером, все один в один как у ТС... хз что делать

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

attachicon.gifпроблемы.JPG

attachicon.gif12.JPG

 

Почему так неизвестно.

присоединяюсь!!! тоже самое происходит при этом не зависит от трафика или кол-ве ппс, может при загрузке +- 30% жевать 100к ппс и 500-600 мегов трафика и при 20-30к ппс с трафиком 200-250 мег упираться в 100% .сетевая ЕТ проц AMD FX-8350

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

ух блин :) уже трое нас :))) от трафика вообще никак не зависит, хоть 50 мбит используется.

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

ух блин :) уже трое нас :))) от трафика вообще никак не зависит, хоть 50 мбит используется.

При этом полезной инфы для диагностики 0. Где тспдамп ? Завернуть весь внешний траф на соседний порт свича, в момент проблемы, снифить чем угодно и анализировать. 

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

 

ух блин :) уже трое нас :))) от трафика вообще никак не зависит, хоть 50 мбит используется.

При этом полезной инфы для диагностики 0. Где тспдамп ? Завернуть весь внешний траф на соседний порт свича, в момент проблемы, снифить чем угодно и анализировать. 

 

 

 

 

ну мне завернуть не получится сервер находится далековато от меня , максимум только tcpdump как проявится конечно соберу стату.

Відредаговано DemonidZe
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

А я думал я один такой дурак :))

Меня кстати net.isr спасал в такие моменты. Когда он был выключен - его включение спасло сервер от падения в кору, он конечно был нагружен очень, но нормально себя чувствовал.

Кстати кто ещё подскажет - не хотят грузится параметры из loader.conf после недавнего мажорного обновления с 9.0 до 9.2.

Лично у меня спам на определенный порт отменяется, т.к. 6881 порт у меня ничем не слушается и включен blackhole.

Да и вообще, сокстат никакого криминала не показывает

Я правило с каунтом добавил - но думаю счётчик вообще дергатся не будет.

И почему сразу выкинуть железо? Ну живёт оно себе нормально, не перенагружается :)

hw.model: Intel® Pentium® CPU G860 @ 3.00GHz

Завернуть траф на соседний порт свича просто не могу, т.к. аплинк зашёл прямо в машину.

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

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від mac
      Глюк в тому, що один (так - тільки один) mac адрес onu існує в білінгу у вигляді строки. Це трохи заважає.
      olt - bdcom gepon.
      Наскільки зрозумів, це виключно проблема реалізації snmpwalk у freebsd, де snmpwalk може на свій розсуд віддати mac адресу не як hex-string, а як звичайний string.
      Можливо snmpwalk тригериться на якомусь символі, мені невідомо.
       
      # tcpdump -vv -i em0 udp port 161 and host olt and host ub | grep "3320.101.10.4.1.1.241 ... olt.snmp > ub.47940: [udp sum ok] { SNMPv2c C="*****" { GetResponse(44) R=93278354 E:3320.101.10.4.1.1.241="8LO"W*" } } ub.47940 > olt.snmp: [udp sum ok] { SNMPv2c C="*****" { GetNextRequest(34) R=93278355 E:3320.101.10.4.1.1.241 } } snmpwalk -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = STRING: "8LO\"W*" snmpwalk -Ox -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = Hex-STRING: 38 4C 4F 22 57 2A  
      Це стосується таких параметрів у snmp конфізі bdcom
       
      [signal] MACINDEX=".1.3.6.1.4.1.3320.101.10.4.1.1" [misc] ONUINDEX=".1.3.6.1.4.1.3320.101.11.1.1.3"  
      За для усунення глюку спробував трошки змінити код і завдати тип snmp параметру явно у ./api/libs/api.ponbdcom.php у function collect()
      Це працює. Мабуть станеться у нагоді:
       
      # diff api.ponbdcom.php{.new,.bak} 37c37 < $onuIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); --- > $onuIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); 91c91 < $macIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE); --- > $macIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE);  
      P.S. Створив тему, а зараз міркую: а може це глюк у ПЗ olt. Оновлю фірмваре olt та перевірю...
       

    • Від a_n_h
      Всем доброго дня и мирного неба!
        После многочисленных экспериментов выяснил, что на последних версиях freebsd  максимум удавалось прокачать до 14 ГБт суммарно трафика со 100% загрузкой процессора. На том-же железе но с установленной freebsd 11.2 прокачивается до 20-ти ГБт суммарно тестового трафика с загрузкой процессора около 50%. 
        Подскажите, что можно убрать или наоборот добавить в систему с freebsd 13,3 для получения аналогичного результата...
    • Від mac
      Здається, після оновлення PHP 7.4 до PHP 8.2 feesharvester припинив працювати:
       
      /usr/local/bin/curl "http://127.0.0.1/billing/?module=remoteapi&key={SERIAL}&action=feesharvester" <br /> <b>Fatal error</b>: Uncaught TypeError: Unsupported operand types: string - string in {UBPATH}/billing/api/libs/api.fundsflow.php:570 Stack trace: #0 {UBPATH}/billing/modules/remoteapi/feesharvester.php(22): FundsFlow-&gt;harvestFees('2024-01') ...  
      Невеличке розслідування врешті з'ясувало, що це через наявність пробілу у деяких логінах абонентів. Як так сталося? Тому що інколи був неуважно додан трейлінг пробіл до номеру будинка і цей пробіл потрапив до логіну абоненту. Логін абоненту неможливо змінити ніяким чином штатними засобами. Я не розглядаю створення нового абонента для усунення помілки.

      Був обран такий шлях вирішення проблеми. Заміну функції php explode() знайшов у мережі. Мабуть це станеться в нагоді:

       
      diff api.fundsflow.php.bak api.fundsflow.php.new 559c559 < $eachfee = explode(' ', $eachline); --- > $eachfee = preg_split("~(?<!\\\\)(?:\\\\{2})*'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'(*SKIP)(*F)|\s+~s" , $eachline);  
    • Від FantoM_EscapE
      Хочу перенести свій білінг NODENY із фізичного сервера на віртуальний. Шукаю адміна який зможе допомогти у цьому питанні, так як нашого адміна банально призвали до війська. Вся схема на даний момент робоча, маю доступи до всього. Потрібно проінсталити на новішу версію FREEBSD, бо на моїй 10 річній вже не працюють нові SSL сертифікати. Кого зацікавила дана пропозиція - прошу у приватні повідомлення. обсудимо ціну і строки. або пишіть на будь-який месенджер 0677792091
    • Від rusol
      Добрый вечер.
       
      Есть от провайдера блок реальных адресов, к примеру 100.1.1.192/26
       
      Раньше сеть была в одном влане и записи в /etc/rc.conf были такие:

       
      ifconfig_ix0="inet 192.168.0.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP ifconfig_ix0_alias0="inet 100.1.1.193 netmask 255.255.255.192" # Шлюз для пользователей с реальными IP  
      После чего стала задача часть пользователей переводить во вланы тоже с разделением на локальные IP и реальные, первый влан создал где-то пару лет назад и все работает:
       
      ifconfig_vlan1="vlan 1 vlandev ix0 192.168.1.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP во Влане 1 ifconfig_vlan1_alias0="inet 100.1.1.248 netmask 255.255.255.248" # Шлюз для пользователей с реальными IP  во Влане 1  
      И вот стоит задача создать еще один влан, делаю по аналогии с вланом 1, только маску смещаю назад:
       
      ifconfig_vlan2="vlan 2 vlandev ix0 192.168.1.1 netmask 255.255.255.0" # Шлюз для пользователей с локальным IP во Влане 2 ifconfig_vlan2_alias0="inet 100.1.1.246 netmask 255.255.255.254" # Шлюз для пользователей с реальными IP во Влане 2  
      Когда я внес это в /etc/rc.conf и прописал команду:
       
      ifconfig vlan2 create  
      Все заработало.
       
      Но как только перезагрузился сервер, перестали работать реальные IP без вланов, в первом влане и во втором. Не пойму что не так делаю, возможно я с маской подсети что-то недопонимаю...

×
×
  • Створити нове...