Перейти до

PPOE сервер на Freebsd 7.4. регулярные перезагрузки.


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

День добрый. Прошу помощи в поиске и устранении причин перезагрузки NAS-сервера.

Исходный данные таковы

проц Intel® Core™ i5-3570 CPU @ 3.40GHz

RAM 4G

мать Z68A-D3H-B3

сетевые 4х портовая интел

 

Схема включения такова - igb1 смотрит в dgs3610-26G. на этом интерфейсе подняты vlan в количестве 600. igb0 смотрит в корень сети.

 

История болезни

Сервер работал как NAS для pppoe соединений(mpd5). количество сессий, которое принимал сервер составляло 1000. присутствует NAT.

В час пик нагрузка на сетевом интерфейсе порядка 800-900 мегабит. пекетов 80Кpps.

CPU ifle time 75% в час пик.

 

Так как мощностей хватает на большую нагрузук, то было принято решение использовать lacp

было пересобранно ядро с переметром

device lagg

настройки интерфесов

ifconfig_igb0="up -polling -vlanhwtag -rxcsum -txcsum -tso"

ifconfig_igb1="up -polling -vlanhwtag -rxcsum -txcsum -tso"

ifconfig_igb2="up -polling -vlanhwtag -rxcsum -txcsum -tso"

ifconfig_igb3="up -polling -vlanhwtag -rxcsum -txcsum -tso"

cloned_interfaces="lagg0 lagg1 vlan1 vlan2 vlan3.... "" # тут происаны все вланы

 

ifconfig_lagg0="laggproto lacp laggport igb2 laggport igb3 10.100.110.64 netmask 255.255.255.0"

ifconfig_lagg1="laggproto lacp laggport igb0 laggport igb1 10.100.100.64 netmask 255.255.255.0"

ifconfig_lagg1_alias0="inet x.x.x.x netmask 255.255.255.224"

ifconfig_lagg1_alias1="inet y.y.y.y netmask 255.255.255.240"

 

ifconfig_vlan2="vlan 2 vlandev lagg0"

ifconfig_vlan3="vlan 3 vlandev lagg0"

ifconfig_vlan4="vlan 4 vlandev lagg0"

 

где x.x.x.x y.y.y.y белые адреса, я их использую для нат-а

 

теперь в час пик имеем следующую картину

количество pppoe сесий 1600-1700

трафик 1,2 -1,4G на прием и 0,6-0,8G на отдачу.

cpu idle time 40-50% .

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

Подскажите, в какую сторону копать?

из параметров

cat /boot/loader.conf | grep -v "#"
net.graph.maxalloc=64000
net.link.ether.inet.log_arp_permanent_modify=0
net.link.ether.inet.log_arp_movements=0
net.link.ether.inet.log_arp_wrong_iface=0
net.link.log_link_state_change=0
net.link.ether.inet.max_age=60
kern.maxfiles=50000
if_lagg_load="YES"

 

cat /etc/sysctl.conf | grep -v "#"
kern.ipc.somaxconn=1024
kern.ipc.maxsockbuf=8388608
kern.ipc.maxsockets=131072
net.inet.ip.intr_queue_maxlen=5000
net.inet.ip.intr_queue_drops=0
net.inet.ip.redirect=0
net.inet.ip.fw.one_pass=0
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.icmp.bmcastecho=1
net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=1
net.graph.maxdgram=768000
net.graph.recvspace=768000
net.inet6.ip6.redirect=0
kern.polling.enable=0
kern.polling.user_frac=0
net.link.ether.inet.log_arp_permanent_modify=0
net.link.ether.inet.log_arp_movements=0
net.link.ether.inet.log_arp_wrong_iface=0
net.link.log_link_state_change=0
net.inet.ip.dummynet.hash_size=512
kern.ipc.nmbclusters=65536

vmstat -i
interrupt total rate
irq18: ehci0 7 0
irq19: atapci0+ 178161 2
irq23: ehci1 9 0
cpu0: timer 267580230 4000
irq256: igb0 492123476 7356
irq257: igb0 205995552 3079
irq258: igb0 215108537 3215
irq259: igb0 205141038 3066
irq260: igb0 5 0
irq261: igb1 509699078 7619
irq262: igb1 215899619 3227
irq263: igb1 212905420 3182
irq264: igb1 215361483 3219
irq265: igb1 6 0
irq266: igb2 509892819 7622
irq267: igb2 205148 3
irq268: igb2 204286 3
irq269: igb2 380026 5
irq270: igb2 5 0
irq271: igb3 477285468 7135
irq272: igb3 187914 2
irq273: igb3 200212 2
irq274: igb3 198526 2
irq275: igb3 6 0
cpu1: timer 267580049 4000
cpu3: timer 267580049 4000
cpu2: timer 267580049 4000
Total 4331287178 64750

 

 netstat -m
17050/7145/24195 mbufs in use (current/cache/total)
17038/4680/21718/204800 mbuf clusters in use (current/cache/total/max)
613/667 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/12800 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
38340K/11146K/49486K 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

pfctl -sn
No ALTQ support in kernel
ALTQ related functions disabled
nat pass on lagg1 inet from 10.10.0.0/16 to ! <trust_networks> -> y.y.y.y/27 source-hash 0x6b6b5d8666236378ab72de2d391bff62

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

а чем ipv6 мешает?

Симптоматическим путем определенно что с ипв6 ребутилось без предупреждения 9 фриха. Без него вроде как номрально. Хотя мне кажется что проблема сугубо железного характера.

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

Проблема скорее в становлении звезд в тот или иной момент НО - на машинах на которых включен ипв6 - раз в 6-8 дней стабильно ребут. Закоментили ипв6, полгода без ребутов.

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

сейчас поднимаю на тестовой машине 9-ку.

на 8-ке пытался работать, но ее работа с igb картами оставляла желать лучшего.

а вот за http://dadv.livejour...com/138951.html - спасибо. как-то упустил я эту статью.

попробую поиграться с

# netgraph queue sizes tuning, see vmstat -z|egrep 'ITEM|NetGraph'
net.graph.maxdata=65536
net.graph.maxalloc=65536

так как на данный момент имею

net.graph.maxdata: 512
net.graph.maxalloc: 64000

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

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

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

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

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

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

Вхід

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

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

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

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