The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"По непонятной причине растет загрузка сервера."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Маршрутизация, NAT / FreeBSD)
Изначальное сообщение [ Отслеживать ]

"По непонятной причине растет загрузка сервера."  +/
Сообщение от shtirlic email(ok) on 21-Фев-13, 20:14 
Здравствуйте товарищи! Есть сервер-NAS (4-ядра проц, 4 гб оперативки, две карточки Intel 82576, mpd+radius+для каждого ng создается по два правила ipfw). Сервак без проблем обрабатывает до 400мб трафика. Такая проблема, ни стого ни с сего, загрузка процессора прерываниями увеличивается до предела, при этом растет пинг падает пропускная способность и в dmesg сыпятся ошибки от named. Это все длится минут 20-30 и снова все становится на круги своя.  При этом на внешнем интерфейсе трафик и pps падает,число сесий стандартное для этого времени. Есть какие идеи?
int:r{irq25 igb0 - сетевая смотрит на внутреннюю сеть
65.67% intr{irq263: igb1 -внешняя
65.67% intr{irq263: igb1 - внешняя

Feb 21 13:44:23 xxxx named[1282]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:1890: unexpected error:
Feb 21 13:44:23 xxxxx named[1282]: internal_send: 10.250.11.98#52436: Cannot allocate memory


last pid: 67788;  load averages:  2.34,  2.10,  2.02  up 26+06:06:12    12:26:00
136 processes: 7 running, 103 sleeping, 26 waiting
Mem: 344M Active, 2629M Inact, 714M Wired, 52M Cache, 417M Buf, 185M Free
Swap: 2048M Total, 60K Used, 2048M Free
  PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   12 root       -92    -     0K   432K CPU1    1 169.3H 82.86% intr{irq25 igb0:que}
   12 root       -92    -     0K   432K WAIT    2  62.6H 65.67% intr{irq263: igb1:que}
   12 root       -92    -     0K   432K WAIT    0  62.0H 51.37% intr{irq265: igb1:que}
   12 root       -60    -     0K   432K WAIT    2  17.1H 43.55% intr{swi4: clock}
   12 root       -92    -     0K   432K WAIT    3  66.3H 41.89% intr{irq262: igb1:que}
   11 root       155 ki31     0K    64K RUN     3 552.6H 37.79% idle{idle: cpu3}
   12 root       -92    -     0K   432K WAIT    0  60.9H 27.20% intr{irq264: igb1:que}
   11 root       155 ki31     0K    64K RUN     0 489.7H 24.37% idle{idle: cpu0}
   11 root       155 ki31     0K    64K CPU2    2 554.2H 22.66% idle{idle: cpu2}
   11 root       155 ki31     0K    64K RUN     1 452.3H 10.99% idle{idle: cpu1}
    0 root       -92    0     0K   288K -       0 346:12  1.17% kernel{igb0 que}
    0 root       -92    0     0K   288K -       3  69:44  0.88% kernel{dummynet}
1407 root        20    0 42976K  7952K select  2 267:34  0.39% snmpd
    0 root       -92    0     0K   288K -       1  51:05  0.20% kernel{igb1 que}
1396 root        20    0   311M   209M select  3 116:52  0.00% mpd5{mpd5}
1282 bind        20    0   170M   133M uwait   0  72:33  0.00% named{named}
1282 bind        20    0   170M   133M uwait   3  72:30  0.00% named{named}
1282 bind        20    0   170M   133M uwait   1  72:19  0.00% named{named}

---------- Netstat -m:
32855/8245/41100 mbufs in use (current/cache/total)
32827/7291/40118/262144 mbuf clusters in use (current/cache/total/max)
32827/6597 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/192000 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)
73868K/16643K/90511K 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
14 requests for I/O initiated by sendfile
0 calls to protocol drain routines

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "По непонятной причине растет загрузка сервера."  +/
Сообщение от pavlinux (ok) on 22-Фев-13, 00:35 
>  Cannot allocate memory

Купи оператифке

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "По непонятной причине растет загрузка сервера."  +/
Сообщение от shtirlic email(ok) on 22-Фев-13, 12:18 
>>  Cannot allocate memory
> Купи оператифке

Проблема не в памяти, ее хватает с головой. В нормальном режиме работы сервер обрабатывает до 400мб трафика и всем все хватает. Мне кажется, это скорее следствие, а не причина.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "По непонятной причине растет загрузка сервера."  +/
Сообщение от YuryD (??) on 22-Фев-13, 07:23 
> Здравствуйте товарищи! Есть сервер-NAS (4-ядра проц, 4 гб оперативки, две карточки Intel
> 82576, mpd+radius+для каждого ng создается по два правила ipfw). Сервак без
> проблем обрабатывает до 400мб трафика. Такая проблема, ни стого ни с
> сего, загрузка процессора прерываниями увеличивается до предела, при этом растет пинг
> падает пропускная способность и в dmesg сыпятся ошибки от named. Это
> все длится минут 20-30 и снова все становится на круги своя.

DDосят. Посмотрите траффик по udp, ограничьте кол-во коннектов по src/dst ip. Мне недавно валили teamspeak сервер.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "По непонятной причине растет загрузка сервера."  +/
Сообщение от shtirlic email(ok) on 22-Фев-13, 12:20 
>  DDосят. Посмотрите траффик по udp, ограничьте кол-во коннектов по src/dst ip.
> Мне недавно валили teamspeak сервер.

Спасибо за совет, понаблюдаю.Что вы имели ввиду под "ограничьте кол-во коннектов по src/dst ip"?

Может у кого еще какие идеи?

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "По непонятной причине растет загрузка сервера."  +/
Сообщение от fantom (ok) on 22-Фев-13, 12:26 
>>  DDосят. Посмотрите траффик по udp, ограничьте кол-во коннектов по src/dst ip.
>> Мне недавно валили teamspeak сервер.
> Спасибо за совет, понаблюдаю.Что вы имели ввиду под "ограничьте кол-во коннектов по
> src/dst ip"?
> Может у кого еще какие идеи?

Посмотрите статистику не мегабитов, а ППС-ов, причем юникаст/бродкаст/мультикаст.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "По непонятной причине растет загрузка сервера."  +/
Сообщение от YuryD (??) on 22-Фев-13, 14:07 
>>  DDосят. Посмотрите траффик по udp, ограничьте кол-во коннектов по src/dst ip.
>> Мне недавно валили teamspeak сервер.
> Спасибо за совет, понаблюдаю.Что вы имели ввиду под "ограничьте кол-во коннектов по
> src/dst ip"?

для teamspeak например помогло следующее
ipfw add nnn allow udp from any to me dst-port 9987 limit src-addr 4

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

8. "По непонятной причине растет загрузка сервера."  +/
Сообщение от LSTemp (ok) on 23-Фев-13, 08:44 
>>  DDосят. Посмотрите траффик по udp, ограничьте кол-во коннектов по src/dst ip.
>> Мне недавно валили teamspeak сервер.
> Спасибо за совет, понаблюдаю.Что вы имели ввиду под "ограничьте кол-во коннектов по
> src/dst ip"?
> Может у кого еще какие идеи?

Немного расшифрую пост от fantom (раз уж Вы про src/dst спрашивали..):

PPS=ППС=Paket per Second=Количество пакетов в секунду

Кроме ограничения максимальной пропускной способности канала, есть еще и ограничения на количество пакетов, которые могут быть корректно обработаны целевым оборудованием/ОС за 1 секунду.

То есть Вам могут слать тысячи пакетов небольшого размера. И при широком канале трафик будет не особо значителен (вроде как загрузки канала нет и не о чем беспокоится). Однако железо/ОС умрет от большого наплыва пакетов, который будет не в состоянии обработать. Это одна из разновидностей Dos-атак.


Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "По непонятной причине растет загрузка сервера."  +/
Сообщение от старый сантехник on 22-Фев-13, 15:38 
Не спец по BSD, так что не судите строго :)

Но я бы помимо софтовых вот еще какую чисто аппаратную проблему проверил - распределение IRQ по процессорным ядрам. В линуксе оно смотрится просто - cat /proc/interrupts. Видел ситуации, когда ядро линукса привязывало IRQ от обеих сетевых карт к одному и тому же ядру. Симптомы были похожими - растущие пинги, падающая пропускная способность и т.д...

Когда IRQ принудительно разнесли по разным процессорным ядрам (программно в ядре линукса), стало лучше. Но недостаточно в конечном итоге. Дальше все уперлось в факт, что сервер был староват и имел всего одну аппаратную PCI шину, на кот. тоже происходил затык. Пришлось менять именно сервер, новый имел разные аппаратные PCI шины и сетевые карты разнесли по ним тоже.

Идею подал, как все это посмотреть в BSD наверняка кто-то лучше меня знает... :)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру