Перейти до

Роутер под FreeBSD 8\9 рандомно зависает.


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

Доброго дня.

Есть два самосборных сервера:

Мать: AsRock X79 Extreme3
Проц: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz
Сетевуха: Intel 10G X520-DA2 E10G42BTDA 82599ES
dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5
dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5
Память: 4 ГБ
БП: 460 Ватт FSP

Оба настроены АБСОЛЮТНО идентично - с первого сделан клон винчестера и поставлен на второй.

Ось:

FreeBSD bgp2_btm.crystal.in.ua 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Jun 26 19:57:19 EEST 2012 amd64

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

Оба используются только как БГП - один основной, второй резервный. Трафик бегает только по одному порту 10Г карты и в ЧНН допрыгивает до 2,8 ин 2,8 оут ГБ.

 

Проблема в следующем: в произвольные моменты времени (от 10 минут до суток) активный сервер зависает.

Причем зависает так, что не реагирует на клавиатуру. Перегрузить можно только нажатием на Ресет.

В этот момент на экране нет никаких сообщений об ошибках - просто висит надпись Логин.

Дампы не делаются, хотя включены. Судя по встроеному мониторингу температуры, перегрева нет, температура до 52 градусов самого горячего ядра. Память тестировали.

Зависнуть может в моменты и когда бегает 50 МБт трафа и когда 2500 МБт.

На обоих серверах стоят одинаковые комплектующие. Меняли уже все запчасти, кроме материнки и проца.

На драйвера от сетевой стоит патчик от 'amarao', отключающий проверку типа СФП на порту. Без него порт не поднимается и пишет "Unsupported SPF+ module", так как DA-кабель не интеловский.

Iperfом между серверами пролетает 8ГБ трафика. Тестировал два часа - ни один не завис.

Изначально на серверах стояла Фря 9.0 СТАБЛЕ. Так на ней сервера висли уже в течении пары часов после запуска в работу.

Еще интересное наблюдение: Точно такой же сервер (третий) стоит под систему виртуализации. У него аптайм уже больше месяца, таких проблем нет. Но и трафика там больше 10-20 МБт не пробегает и используется бортовая карта Broadcom bge.

 

Проштудированы уже и ЖЖ 'dadv'a, и ЭТА и ЭТА и ЭТА темы, загуглено всё до дыр.

Просветление так и не наступило =(

 

На что можно обратить внимание? Что посоветуете? Какие еще конфигитесты приложить?

 

 

 

Конфиги:

 

ядро:

Закомментированы все ненужные устройства, включен DEBUG=-g, ВЫКЛЮЧЕН options INET6.

От себя добавлены

device		  coretemp
device		  cpuctl
options		 HZ=2000
options		 IPFIREWALL
options		 IPDIVERT
options		 IPFIREWALL_FORWARD
options		 IPFIREWALL_DEFAULT_TO_ACCEPT
options		 IPFIREWALL_VERBOSE
options		 IPFIREWALL_VERBOSE_LIMIT=999
options		 DUMMYNET
options		 NETGRAPH
options		 NETGRAPH_SOCKET
options		 NETGRAPH_IPFW
options		 NETGRAPH_NETFLOW
options		 NETGRAPH_KSOCKET

options		 SC_NORM_ATTR=(FG_GREEN|BG_BLACK)
options		 SC_KERNEL_CONS_ATTR=(FG_YELLOW|BG_BLACK)

На ядре GENERIC тоже проверялось - виснет =(

 

loader.conf

vm.pmap.pg_ps_enabled="1"
net.inet.tcp.tcbhashsize=16384
net.inet.tcp.syncache.hashsize=1024
net.inet.tcp.syncache.bucketlimit=512
net.graph.maxdata=4096
net.isr.defaultqlimit=4096
net.link.ifqmaxlen=1024
net.isr.maxthreads=1
net.isr.direct=0
net.isr.direct_force=0
kern.ipc.nmbclusters=262800

Если сделать kern.ipc.nmbclusters выставлено по умолчанию или меньше 65000, то при загрузке драйвер сетевой карты пишет - "Невозможно установить значение буферов, будет использовано значение по умолчанию" (както так)

 

sysctl.conf

net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
net.inet.ip.portrange.first=1024
net.inet.ip.portrange.last=65535
net.inet.ip.random_id=1
net.inet.udp.blackhole=1
net.inet.tcp.blackhole=2
net.inet.tcp.nolocaltimewait=1
net.inet.tcp.fast_finwait2_recycle=1
net.inet.tcp.sendspace=131072
net.inet.tcp.recvspace=131072
net.inet.udp.recvspace=131072
net.inet.raw.recvspace=262800
net.inet.tcp.maxtcptw=40960
net.inet.tcp.syncookies=1
net.inet.tcp.keepidle=40000
net.inet.tcp.keepintvl=40000
net.inet.tcp.keepinit=40000

net.route.netisr_maxqlen=4096
net.inet.ip.intr_queue_maxlen=4096
net.inet.icmp.icmplim=600

net.inet.ip.fw.dyn_max=16384
net.inet.ip.fw.dyn_buckets=32768
net.inet.ip.dummynet.hash_size=2048
net.inet.ip.dummynet.io_fast=1
net.inet.ip.dummynet.expire=0
net.inet.ip.dummynet.pipe_slot_limit=1000

###net.graph.recvspace=350000
###net.graph.maxdgram=350000

kern.ipc.maxsockbuf=83886080
kern.ipc.somaxconn=4096

net.inet.ip.redirect=0
net.inet.ip.fastforwarding=1

dev.ix.0.fc=0
dev.ix.1.fc=0
dev.ix.0.rx_processing_limit=4000
dev.ix.1.rx_processing_limit=4000

Если kern.ipc.maxsockbuf выставлено в значение по умолчанию или меньше 1000000, то даже пинг пишет "No space buffer available"

 

netstat -m

25085/2695/27780 mbufs in use (current/cache/total)
25083/1163/26246/262800 mbuf clusters in use (current/cache/total/max)
25083/1157 mbuf+clusters out of packet secondary zone in use (current/cache)
0/5/5/131400 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/65700 9k jumbo clusters in use (current/cache/total/max)
0/0/0/32850 16k jumbo clusters in use (current/cache/total/max)
56437K/3019K/59457K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/0/0 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines

 

netstat -Q

Configuration:
Setting						  Value	  Maximum
Thread count						 1			1
Default queue limit			   4096		10240
Direct dispatch			   disabled		  n/a
Forced direct dispatch		disabled		  n/a
Threads bound to CPUs		 disabled		  n/a

Protocols:
Name   Proto QLimit Policy Flags
ip		 1   4096   flow   ---
igmp	   2   4096 source   ---
rtsock	 3   4096 source   ---
arp		7   4096 source   ---

Workstreams:
WSID CPU   Name	 Len WMark   Disp'd  HDisp'd   QDrops   Queued  Handled
  0   0  ip		 0	 3		0		0		0	35752	35752
	  igmp	   0	 0		0		0		0		0		0
	  rtsock	 0	 2		0		0		0	34293	34293
	  arp		0	 8		0		0		0	70179	70179

 

vmstat -i

interrupt						  total	   rate
irq16: ehci0					   20863		  1
irq23: ehci1					   44164		  3
cpu0: timer					 27679535	   1999
irq256: ix0:que 0			  150825498	  10897
irq257: ix0:que 1			  149848455	  10827
irq258: ix0:que 2			  143558676	  10372
irq259: ix0:que 3			  145734821	  10529
irq260: ix0:que 4			  147141456	  10631
irq261: ix0:que 5			  148140406	  10703
irq262: ix0:link					   2		  0
irq263: ix1:que 0				  13816		  0
irq264: ix1:que 1				  13816		  0
irq265: ix1:que 2				  13816		  0
irq266: ix1:que 3				  13816		  0
irq267: ix1:que 4				  13816		  0
irq268: ix1:que 5				  13816		  0
irq269: ix1:link					  11		  0
irq271: bge0						   1		  0
irq272: ahci1					   4694		  0
cpu5: timer					 27679401	   1999
cpu1: timer					 27679136	   1999
cpu3: timer					 27679415	   1999
cpu2: timer					 27679333	   1999
cpu4: timer					 27679339	   1999
Total						 1051478102	  75973

 

top -SHPI

last pid:  2552;  load averages:  0.52,  0.64,  0.58	 up 0+03:51:43  12:29:30
137 processes: 8 running, 90 sleeping, 39 waiting
CPU 0:	 % user,	 % nice,	 % system,	 % interrupt,	 % idle
CPU 1:	 % user,	 % nice,	 % system,	 % interrupt,	 % idle
CPU 2:	 % user,	 % nice,	 % system,	 % interrupt,	 % idle
CPU 3:	 % user,	 % nice,	 % system,	 % interrupt,	 % idle
CPU 4:	 % user,	 % nice,	 % system,	 % interrupt,	 % idle
CPU 5:	 % user,	 % nice,	 % system,	 % interrupt,	 % idle
Mem: 31M Active, 9960K Inact, 185M Wired, 152K Cache, 17M Buf, 3660M Free
Swap: 2048M Total, 2048M Free

 PID USERNAME PRI NICE   SIZE	RES STATE   C   TIME   WCPU COMMAND
  11 root	 171 ki31	 0K	96K CPU5	5 216:47 98.73% idle{idle: cpu5}
  11 root	 171 ki31	 0K	96K CPU4	4 216:48 98.54% idle{idle: cpu4}
  11 root	 171 ki31	 0K	96K CPU3	3 215:10 96.34% idle{idle: cpu3}
  11 root	 171 ki31	 0K	96K CPU2	2 212:52 94.92% idle{idle: cpu2}
  11 root	 171 ki31	 0K	96K RUN	 0 209:56 93.51% idle{idle: cpu0}
  11 root	 171 ki31	 0K	96K RUN	 1 211:01 93.41% idle{idle: cpu1}
  12 root	 -68	-	 0K   640K WAIT	0  15:30  8.01% intr{irq256: ix0:q
  12 root	 -68	-	 0K   640K WAIT	3  14:49  8.01% intr{irq259: ix0:q
  12 root	 -68	-	 0K   640K CPU1	1  15:12  7.86% intr{irq257: ix0:q
  12 root	 -68	-	 0K   640K WAIT	2  15:03  7.86% intr{irq258: ix0:q
  12 root	 -68	-	 0K   640K WAIT	5  14:30  7.71% intr{irq261: ix0:q
  12 root	 -68	-	 0K   640K WAIT	4  14:10  7.08% intr{irq260: ix0:q
0 root	 -68	0	 0K   400K -	   3   2:51  0.98% kernel{ix0 que}
0 root	 -68	0	 0K   400K -	   3   2:40  0.88% kernel{ix0 que}
0 root	 -68	0	 0K   400K -	   0   2:36  0.88% kernel{ix0 que}
0 root	 -68	0	 0K   400K -	   0   2:42  0.78% kernel{ix0 que}
0 root	 -68	0	 0K   400K -	   2   2:39  0.78% kernel{ix0 que}
0 root	 -68	0	 0K   400K -	   5   2:43  0.63% kernel{ix0 que}

 

systat -if

					/0   /1   /2   /3   /4   /5   /6   /7   /8   /9   /10
 Load Average   ||||

  Interface		   Traffic			   Peak				Total
... skip...

		ix0  in	215.106 MB/s		215.106 MB/s			2.152 TB
			 out   214.945 MB/s		214.945 MB/s			2.150 TB

 

sysctl dev.ix.0

dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5
dev.ix.0.%driver: ix
dev.ix.0.%location: slot=0 function=0
dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x0003 class=0x020000
dev.ix.0.%parent: pci3
dev.ix.0.fc: 0
dev.ix.0.advertise_gig: 0
dev.ix.0.enable_aim: 1
dev.ix.0.advertise_speed: 0
dev.ix.0.rx_processing_limit: 4000
dev.ix.0.dropped: 0
dev.ix.0.mbuf_defrag_failed: 0
dev.ix.0.no_tx_dma_setup: 0
dev.ix.0.watchdog_events: 0
dev.ix.0.tso_tx: 307
dev.ix.0.link_irq: 2
dev.ix.0.queue0.interrupt_rate: 11235
dev.ix.0.queue0.txd_head: 1877
dev.ix.0.queue0.txd_tail: 1877
dev.ix.0.queue0.no_desc_avail: 0
dev.ix.0.queue0.tx_packets: 522247016
dev.ix.0.queue0.rxd_head: 764
dev.ix.0.queue0.rxd_tail: 754
dev.ix.0.queue0.rx_packets: 522423035
dev.ix.0.queue0.rx_bytes: 439349665008
dev.ix.0.queue0.lro_queued: 0
dev.ix.0.queue0.lro_flushed: 0
dev.ix.0.queue1.interrupt_rate: 250000
dev.ix.0.queue1.txd_head: 1922
dev.ix.0.queue1.txd_tail: 1922
dev.ix.0.queue1.no_desc_avail: 0
dev.ix.0.queue1.tx_packets: 499340467
dev.ix.0.queue1.rxd_head: 908
dev.ix.0.queue1.rxd_tail: 905
dev.ix.0.queue1.rx_packets: 499393418
dev.ix.0.queue1.rx_bytes: 433420059450
dev.ix.0.queue1.lro_queued: 0
dev.ix.0.queue1.lro_flushed: 0
dev.ix.0.queue2.interrupt_rate: 55555
dev.ix.0.queue2.txd_head: 476
dev.ix.0.queue2.txd_tail: 479
dev.ix.0.queue2.no_desc_avail: 0
dev.ix.0.queue2.tx_packets: 502389134
dev.ix.0.queue2.rxd_head: 1992
dev.ix.0.queue2.rxd_tail: 1990
dev.ix.0.queue2.rx_packets: 502468551
dev.ix.0.queue2.rx_bytes: 447423791311
dev.ix.0.queue2.lro_queued: 0
dev.ix.0.queue2.lro_flushed: 0
dev.ix.0.queue3.interrupt_rate: 41666
dev.ix.0.queue3.txd_head: 341
dev.ix.0.queue3.txd_tail: 343
dev.ix.0.queue3.no_desc_avail: 0
dev.ix.0.queue3.tx_packets: 489592945
dev.ix.0.queue3.rxd_head: 241
dev.ix.0.queue3.rxd_tail: 239
dev.ix.0.queue3.rx_packets: 489627888
dev.ix.0.queue3.rx_bytes: 438060012259
dev.ix.0.queue3.lro_queued: 0
dev.ix.0.queue3.lro_flushed: 0
dev.ix.0.queue4.interrupt_rate: 1000000
dev.ix.0.queue4.txd_head: 952
dev.ix.0.queue4.txd_tail: 952
dev.ix.0.queue4.no_desc_avail: 0
dev.ix.0.queue4.tx_packets: 471091610
dev.ix.0.queue4.rxd_head: 1578
dev.ix.0.queue4.rxd_tail: 1577
dev.ix.0.queue4.rx_packets: 471164458
dev.ix.0.queue4.rx_bytes: 409881181720
dev.ix.0.queue4.lro_queued: 0
dev.ix.0.queue4.lro_flushed: 0
dev.ix.0.queue5.interrupt_rate: 55555
dev.ix.0.queue5.txd_head: 584
dev.ix.0.queue5.txd_tail: 584
dev.ix.0.queue5.no_desc_avail: 0
dev.ix.0.queue5.tx_packets: 482597087
dev.ix.0.queue5.rxd_head: 1815
dev.ix.0.queue5.rxd_tail: 1813
dev.ix.0.queue5.rx_packets: 482629398
dev.ix.0.queue5.rx_bytes: 414473310965
dev.ix.0.queue5.lro_queued: 0
dev.ix.0.queue5.lro_flushed: 0
dev.ix.0.mac_stats.crc_errs: 0
dev.ix.0.mac_stats.ill_errs: 0
dev.ix.0.mac_stats.byte_errs: 0
dev.ix.0.mac_stats.short_discards: 0
dev.ix.0.mac_stats.local_faults: 0
dev.ix.0.mac_stats.remote_faults: 2
dev.ix.0.mac_stats.rec_len_errs: 0
dev.ix.0.mac_stats.link_xon_txd: 0
dev.ix.0.mac_stats.link_xon_rcvd: 0
dev.ix.0.mac_stats.link_xoff_txd: 0
dev.ix.0.mac_stats.link_xoff_rcvd: 0
dev.ix.0.mac_stats.total_octets_rcvd: 2606615322672
dev.ix.0.mac_stats.good_octets_rcvd: 2606325113515
dev.ix.0.mac_stats.total_pkts_rcvd: 2970506195
dev.ix.0.mac_stats.good_pkts_rcvd: 2967678482
dev.ix.0.mac_stats.mcast_pkts_rcvd: 867
dev.ix.0.mac_stats.bcast_pkts_rcvd: 122071
dev.ix.0.mac_stats.rx_frames_64: 90966031
dev.ix.0.mac_stats.rx_frames_65_127: 1041294326
dev.ix.0.mac_stats.rx_frames_128_255: 85729000
dev.ix.0.mac_stats.rx_frames_256_511: 44289698
dev.ix.0.mac_stats.rx_frames_512_1023: 66616039
dev.ix.0.mac_stats.rx_frames_1024_1522: 1638783388
dev.ix.0.mac_stats.recv_undersized: 0
dev.ix.0.mac_stats.recv_fragmented: 0
dev.ix.0.mac_stats.recv_oversized: 0
dev.ix.0.mac_stats.recv_jabberd: 0
dev.ix.0.mac_stats.management_pkts_rcvd: 0
dev.ix.0.mac_stats.management_pkts_drpd: 0
dev.ix.0.mac_stats.checksum_errs: 58309085
dev.ix.0.mac_stats.good_octets_txd: 2604466960626
dev.ix.0.mac_stats.total_pkts_txd: 2967230280
dev.ix.0.mac_stats.good_pkts_txd: 2967230280
dev.ix.0.mac_stats.bcast_pkts_txd: 7837
dev.ix.0.mac_stats.mcast_pkts_txd: 0
dev.ix.0.mac_stats.management_pkts_txd: 0
dev.ix.0.mac_stats.tx_frames_64: 543929978
dev.ix.0.mac_stats.tx_frames_65_127: 587900462
dev.ix.0.mac_stats.tx_frames_128_255: 85715330
dev.ix.0.mac_stats.tx_frames_256_511: 44286755
dev.ix.0.mac_stats.tx_frames_512_1023: 66615662
dev.ix.0.mac_stats.tx_frames_1024_1522: 1638782093
dev.ix.0.mac_stats.fc_crc: 0
dev.ix.0.mac_stats.fc_last: 0
dev.ix.0.mac_stats.fc_drpd: 0
dev.ix.0.mac_stats.fc_pkts_rcvd: 0
dev.ix.0.mac_stats.fc_pkts_txd: 0
dev.ix.0.mac_stats.fc_dword_rcvd: 0
dev.ix.0.mac_stats.fc_dword_txd: 0

Присутствует dev.ix.0.mac_stats.checksum_errs: 58309085

Но менялась и сетевая карта, и кабели и порты на свиче: ошибки по счетчику есть, а реальных потерь пакетов - нет.

 

vmstat -z

Ошибок нет. Везде, кроме buckets, нули.

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

была проблема один в один

 

также пробовал и 8 и 9-ую ветку фряхи.

 

выкинул, поставил дебиан 6, беспроблемный полет уже >2 месяцев

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

Как бЭ поставить дебиан не проблема, если бы планировался только чистый БГП.

НО. ЕСЛИ БЫ все работало нормально, то была задача повесить туда еще и шейпера.

А так как связка биллинг-шейпер заточена под Фрю, то поставить линуха туда не вариант.

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

ЕСЛИ БЫ все работало нормально, то была задача повесить туда еще и шейпера.

А так как связка биллинг-шейпер заточена под Фрю, то поставить линуха туда не вариант.

А чего готовый шейпер под линукс не взять-то? Если самому лень писать скрипты...

В том же LEAF к примеру я запилил шейпер для своих нужд, которому после инициализации ним таблиц нужно только подавать ип, ифейс и скорость - не задумываясь о том, как оно "под капотом" классы/фильтры нумерует...

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

Почитал. Вопрос: оно умеет шейпить один ип с разными скоростями ? С одной скоростью в мир, с другой (или вообще БЕЗ шейпов) - в уа-икс ?

У нас просто есть шейпер, адекватно решающий все вопросы со скоростьюитд, но он только под Фрю.

Поэтому бы и хотелось остаться на ней же, так как не нужно никаких переделок.

Да и вопрос то хотелось бы решить, ибо уже прочитал немало тем с подобными симптомами, а решения либо нет, либо шаманства с бубном. И не факт, что поможет.

Вот нам эти советы не помогли =(

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

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

Модифицируете немного - будет шейпить и входящий к абону (либо - по подклассам абонского класса в зависимости от меток раскидывать, метки же назначать в iptables, либо - вообще повешать на ifb, ifb прибить к аплинкам, вот только придется добавить выбор src/dst маски для ифейсов при инициализации)

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

Нюанс в том, что я фряшник и в линуксовом шейпере знаю только его название )

Поэтому спасибо, за совет, буду думать.

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

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

Абсолютно.

Стандартный процесс загрузки, нигде нет видимых ошибокварнингов.

После зависания в логе по этому поводу пусто - сразу начинается лог следующей загрузки.

 

Гдето гуглилось, что это ВОЗМОЖНЫЕ проблемы с переполнением КАКИХ-ТО внутренних буферовпамяти ядра.

Так, что виснет наглухо.

Но, опять же, ГДЕ нужно посмотреть на это что поправить - не нашлось.

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

Нюанс в том, что я фряшник и в линуксовом шейпере знаю только его название )

Поэтому спасибо, за совет, буду думать.

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

Ваше дело. Как по мне - в шейпере проще разобраться, чем найти критическую ошибку в коде ядра...

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

Абсолютно.

Стандартный процесс загрузки, нигде нет видимых ошибокварнингов.

После зависания в логе по этому поводу пусто - сразу начинается лог следующей загрузки.

 

Гдето гуглилось, что это ВОЗМОЖНЫЕ проблемы с переполнением КАКИХ-ТО внутренних буферовпамяти ядра.

Так, что виснет наглухо.

Но, опять же, ГДЕ нужно посмотреть на это что поправить - не нашлось.

А графики вы не рисуете никакие? Нагрузки на проц, кол-во прерываний на сетевушках, и тд и тп. Просто слишком уж мало симптомов для того чтобы что-то диагностировать. Но вобще похоже на "чета с железом". Было что на i5 кору сыпало, помогло выключение ACPI, но у вас симптом другой.

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

+1, больше похоже на какую-то половую несовместимость железа. Например сетевки и мамки от великой и ужасной AsRock. Я бы начал с замены матери, благо не сложная операция при наличии 2ух серверов.

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

То maxx:

Не рисую, но пару раз пациент "умер" у меня на руках как раз в момент рассматривания этих самых цифер вживую.

Отклонений в этот момент не было ((

Выкл ACPI - попробую.

 

То KaYot:

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

 

То Sargas:

Включено. Выключу.

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

Попробуйте семёрку.

Было такое, на igb правда.

 

Мы с семерки как раз и ушли на 89.

В 7ке при большом количестве правилпайпов в фаерволе быстро заканчивались ресурсы проца.

У нас сейчас есть два работающих сервера. На одном 9ка и 4хголовая Интел РТ, на втором 7ка и тоже 4х Интел РТ (которая em).

Там все жужжит и не чихает, причем при одинаковом трафике загрузка проца на 9ке в полтора раза меньше, чем на 7ке.

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

То maxx:

Не рисую, но пару раз пациент "умер" у меня на руках как раз в момент рассматривания этих самых цифер вживую.

Отклонений в этот момент не было ((

Выкл ACPI - попробую.

 

То KaYot:

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

 

То Sargas:

Включено. Выключу.

 

1. Упр питанием и всякие C-state отключил

2. Пока жужжит

3. Выключил.

 

Пока там бегает тестово метров 100 трафика.

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

То maxx:

Не рисую, но пару раз пациент "умер" у меня на руках как раз в момент рассматривания этих самых цифер вживую.

Отклонений в этот момент не было ((

Выкл ACPI - попробую.

 

То KaYot:

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

 

То Sargas:

Включено. Выключу.

 

1. Упр питанием и всякие C-state отключил

2. Пока жужжит

3. Выключил.

 

Пока там бегает тестово метров 100 трафика.

А айпикада там случаем нету на сервере?

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

А зачем там в таком случае шейпер?

Линуксы всякие в таком виде работают годами, в любой версии - у нас есть сервера на fedora 6(актуальная - 17), желания обновлять как-то не возникает.

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

Так же придерживаюсь мысли, что что-то с железом.

По поводу мониторига: глазом можно не заметить изменения одновременно нескольких показателей, а тот же Zabbix к примеру дал бы Вам возможность спокойно рассмотреть что происходило в системе перед "смертью".

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

А зачем там в таком случае шейпер?

Линуксы всякие в таком виде работают годами, в любой версии - у нас есть сервера на fedora 6(актуальная - 17), желания обновлять как-то не возникает.

Затем, что даже в таком МИНИМАЛЬНОМ наборе - зависает.

Поэтому было выключено/вырезано почти все, что не нужно в данный момент времени.

А ядро сразу собрано с нужными параметрами, так как без них оно не нужно вообще, само собой.

По поводу "годами работает" - наши два старых шейпера вот как раз таки "годами" и работают на 7.3 и вот поставили недавно 9.0 - всё ок. Только там железо брендовое, а не самосбор.

п.с. Кстати, на ядре GENERIC самосборные сервера тоже виснут.

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

Так же придерживаюсь мысли, что что-то с железом.

По поводу мониторига: глазом можно не заметить изменения одновременно нескольких показателей, а тот же Zabbix к примеру дал бы Вам возможность спокойно рассмотреть что происходило в системе перед "смертью".

Возможно. Что мониторить то?

Имхо, при потоке в 50 МБт врятли может случится перегревнехватка памятивообще чего-нибуть, нормально мониторящееся.

п.с. У нас есть сервачек на Атоме - жует 300 МБт с шейперами, НАТом, БГП итд. Стоит и есть не просит.

А тут железка - гигабиты можно прокидывать - и на 50 МБт ночью виснет.

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

Может, процы слишком шустрые, и где-то в ведре (в драйвере сетевухи либо в части ядра, связанной с обработкой MSI-X прерываний) вылазит race condition? Попробуйте еще ради эксперимента все 10 гбит зафлудить чем-то и посмотреть на результат (упадет раньше/позже/не упадет вообще). Хотя может и железо глюкавое таки - нет под рукой какой-то офисной лга1155 мамки на тест, убедиться, что мат.плата ни при чем?

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

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

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

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

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

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

Вхід

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

Войти сейчас
  • Зараз на сторінці   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 та перевірю...
       

    • Від Parallels
      Продам конвертори 10g CX4-SFP+ D-Link DMC-805x
      Ціна 3000 грн
       
      Також є в наявності до них кабелі стеку CX4-CX4

    • Від Михаил Гордиенко
      Продам Комутатор світч Cisco Nexus 2348TQ 10GE. Привезли з Європи. з'ясувалось, що мені він не потрібен, немає де використати. Ціна для форума 250$ Кому потрібен - запитуйте, торгуємо.










    • Від 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);  
×
×
  • Створити нове...