[Hawk128]

Есть сервак на 8.0 amd64. Проц Xeon 5570 на sr1600ur.

 

Стоит mpd5, mysql5.1, natd. Ну прочего по мелочи. Карточки встроенные igb.

 

Проблема в том, что раз в сутки-неделю процесс flowcleaner занимает 100% одного из ядер. При этом работа НАТа и мпд блокируется (трафик не идет, новые пользователи не цепляются, старые не отваливаются). К машине удаленно прицепиться можно, на пинги бодро отвечат. Перезагрузить себя не дает из-за этого процесса.

 

Описания его я не нашел, что это вообще и почему себя так ведет?

 

Речь вот об этом процессе:

 

stat# ps awx | grep flow

20 ?? DL 0:01.09 [flowcleaner]

Изменено 8 марта, 2010 пользователем Hawk128

[fenix-vt]

универсальный совет для FreeBSD 8.0, который, наверное, должен войти в FAQ: обновляйтесь до последней 8.0-STABLE :)

[Hawk128]

Была на момент проблемы snapshot 02.2010.

 

Час назад накатил через cvsup до текущей stable. Пока что жду.

[adeep]

а трафик нормально по ядрам делится? или все на одно ядро лезет?

покажите, пожалуйста, top -S

[Hawk128]

По работает - нормально. Когда впадет в глюк, все ядра свободны кроме одного - оно на этом процессер.

 

last pid: 11724;  load averages:  1.09,  0.93,  0.91                         up 0+02:32:24  18:55:16
1004 processes:9 running, 970 sleeping, 25 waiting
CPU:  2.8% user,  0.0% nice,  9.6% system,  5.3% interrupt, 82.4% idle
Mem: 560M Active, 1648M Inact, 899M Wired, 712K Cache, 617M Buf, 2729M Free
Swap: 2048M Total, 2048M Free

  PID USERNAME PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   11 root     171 ki31     0K   128K RUN     1 136:12 91.70% {idle: cpu1}
   11 root     171 ki31     0K   128K CPU7    7 136:20 89.89% {idle: cpu7}
   11 root     171 ki31     0K   128K RUN     4 133:56 87.99% {idle: cpu4}
   11 root     171 ki31     0K   128K CPU5    5 136:00 85.60% {idle: cpu5}
   11 root     171 ki31     0K   128K RUN     0 129:36 83.40% {idle: cpu0}
   11 root     171 ki31     0K   128K CPU6    6 134:38 81.88% {idle: cpu6}
   11 root     171 ki31     0K   128K RUN     2 126:22 77.49% {idle: cpu2}
   11 root     171 ki31     0K   128K CPU3    3 130:20 77.39% {idle: cpu3}
  666 root      76    0 44904K 33216K select  0  49:50 56.79% natd
   12 root     -44    -     0K   400K WAIT    7  19:26 22.17% {swi1: netisr 0}
   12 root     -68    -     0K   400K WAIT    6  10:55 12.06% {irq257: igb0}
   12 root     -68    -     0K   400K WAIT    1   5:55  5.47% {irq260: igb1}
   13 root      46    -     0K   128K sleep   4   3:01  3.66% {ng_queue2}
   13 root      45    -     0K   128K sleep   1   3:05  3.56% {ng_queue3}
   13 root      46    -     0K   128K sleep   3   3:02  3.08% {ng_queue7}
    0 root     -68    0     0K   144K -       2   3:06  2.98% {igb0 taskq}
   13 root      45    -     0K   128K sleep   3   3:03  2.98% {ng_queue0}
   13 root      46    -     0K   128K sleep   3   3:04  2.88% {ng_queue4}
   13 root      46    -     0K   128K sleep   2   2:59  2.88% {ng_queue5}
   13 root      45    -     0K   128K sleep   3   3:03  2.49% {ng_queue1}
    0 root     -68    0     0K   144K -       7   2:23  2.39% {igb1 taskq}
   13 root      45    -     0K   128K sleep   2   3:04  2.29% {ng_queue6}
   12 root     -68    -     0K   400K WAIT    5   1:55  1.66% {irq256: igb0}
   12 root     -68    -     0K   400K WAIT    0   1:38  1.56% {irq259: igb1}
64120 root      44  -15   321M   239M select  2   0:55  0.88% {ipcad}
57168 root      44    0 50900K 20792K select  5   0:51  0.00% {mpd5}
   12 root     -32    -     0K   400K WAIT    2   0:38  0.00% {swi4: clock}
    0 root     -68    0     0K   144K -       3   0:18  0.00% {dummynet}
3967 mysql     44    0   507M   205M sbwait  1   0:18  0.00% {mysqld}
54286 root      44    0  6972K  1532K select  3   0:16  0.00% syslogd
   14 root      44    -     0K    16K -       7   0:14  0.00% yarrow
  896 bind      44    0   107M 97184K kqread  2   0:11  0.00% {named}
  896 bind      44    0   107M 97184K ucond   0   0:08  0.00% {named}
  896 bind      44    0   107M 97184K ucond   7   0:08  0.00% {named}
  896 bind      44    0   107M 97184K ucond   0   0:08  0.00% {named}
  896 bind      44    0   107M 97184K ucond   0   0:08  0.00% {named}
  896 bind      44    0   107M 97184K ucond   3   0:08  0.00% {named}
  896 bind      44    0   107M 97184K ucond   1   0:08  0.00% {named}
  896 bind      44    0   107M 97184K ucond   0   0:08  0.00% {named}
  896 bind      44    0   107M 97184K ucond   2   0:08  0.00% {named}
3967 mysql     44    0   507M   205M sbwait  0   0:06  0.00% {mysqld}
   12 root     -64    -     0K   400K WAIT    2   0:06  0.00% {irq19: uhci0 uhc}
15745 root      44    0 12032K  9388K select  4   0:05  0.00% dhcpd
2105 root      44    0 22932K  5448K select  3   0:04  0.00% nmbd
64120 root      44  -15   321M   239M select  6   0:03  0.00% {ipcad}
64120 root      44  -15   321M   239M select  4   0:03  0.00% {ipcad}
   12 root     -64    -     0K   400K WAIT    3   0:03  0.00% {irq18: atapci0}
   15 root     -68    -     0K   528K -       1   0:03  0.00% {usbus1}
9710 root      44    0   130M 14852K select  0   0:03  0.00% httpd

 

 

Ну и нагрузка вообщем то невелика на сервак:

 

stat# netstat -hdw1 -q3
            input        (Total)           output
   packets  errs idrops      bytes    packets  errs      bytes colls drops
       44K     0     0        29M        42K     0        27M     0     0 
       45K     0     0        30M        43K     0        28M     0     0 
       46K     0     0        30M        43K     0        28M     0     0

 

Самое удивительное, нигде не смог нормальную инфу найти по этому процессу. Всего пара ссылок попадалась на похожие проблемы, но кроме самой проблемы там больше ничего и не было.

Изменено 8 марта, 2010 пользователем Hawk128

[_longhorn_]

Hawk128

Если проблема повторится попробуйте net.inet.flowtable.enable=0

[yadvlz]

Проще всего удалить flowtable из ядра

[Hawk128]

Не могу найти почти никакой нормальной информации об этой опции.

 

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

[fenix-vt]

отпишите, пожалуйста, как полет?

[Diman]

если убрать из ядра, то процесса flowcleaner больше не будет... но будет ли это хорошо?

Изменено 10 марта, 2010 пользователем Diman

[yadvlz]

если убрать из ядра, то процесса flowcleaner больше не будет... но будет ли это хорошо?

Если у вас не 10GbE-карты с соответствующим трафиком - плохо не будет.

[adeep]

а если 10GbE карты, то чем это хуже?

[yadvlz]

Запись в блоге Кипа (kmacy@freebsd.org). Ещё можно заглянуть в рассылку.

Изменено 11 марта, 2010 пользователем yadvlz

[adeep]

т.е. для наших случаев (куча маршрутов при роутинге, small isp) это не подходит и надо выключать.

[kaats]

Есть сервак на 8.0 amd64. Проц Xeon 5570 на sr1600ur.

 

Стоит mpd5, mysql5.1, natd. Ну прочего по мелочи. Карточки встроенные igb.

 

Проблема в том, что раз в сутки-неделю процесс flowcleaner занимает 100% одного из ядер. При этом работа НАТа и мпд блокируется (трафик не идет, новые пользователи не цепляются, старые не отваливаются). К машине удаленно прицепиться можно, на пинги бодро отвечат. Перезагрузить себя не дает из-за этого процесса.

 

Описания его я не нашел, что это вообще и почему себя так ведет?

 

Речь вот об этом процессе:

 

stat# ps awx | grep flow

20 ?? DL 0:01.09 [flowcleaner]

Только что слетел с такой же проблемой - в топе для одного ядра (FreeBSd 8.0 stable mpd5.4)

19 root        1  44    -     0K     8K CPU4    4   8:09 100.00% [flowcleaner]

Отпишитесь , как у вас решилось?

Спасибо.

помогает убрать с ядра flowtable?

 

 

[Hawk128]

Сорри, что долго не писал.

 

Сегодня сервак опять встал. До этого работал, поэтому нечего было писать. Встал вообще глухо, ни на консоль, ни на что другое не регируя.

 

Есть идеи? На пробу выключил HT в биосе. Отсюда еще вопрос, там есть еще пара тройка интеловских улучшателей, есть у кого опыт по проблемам от них? Стоит ли flowtables выносить из ядра? Или ждать и надеяться на решение проблемы выключением HT?

[_longhorn_]

Hawk128

Не думаю что проблема в HT. Попробуйте собрать ядро без flowatble. Хотя у меня и с ним работает.

[kapa]

мы тут все думали, что Вы попробовали давно уже, а у Вас мазохизм... :)

[Hawk128]

Значит без flowtable рекомендуете собрать ядро и проверять? HT точно не может влиять?

 

Еще попутно вопрос, пробовал на обычно Athlon 64 x2 гонять Freebsd amd64 различные версии, никаких проблем все хорошо, а вот на интеле после меню выбора загрузки перед загрузкой ядра долгая пауза (30-40 сек примерно). Что это может быть? Поиск уже измучил, ничего не нашел. На АМДшной системе этот момент проходит без задержки (0-0.5 сек).

[kaats]

Вот тут тоже обсуждают полезность отключения Flowtable если вы не мегТранспортныйУзел. Сыылка Там же читал и о наличии патчей для Flowtable

[Hawk128]

Не стал дальше эксперементировать на пользователях. Убрал эту опцию из ядра.

[kaats]

Не стал дальше эксперементировать на пользователях. Убрал эту опцию из ядра.

Ииии...?

Стало работать?

[Hawk128]

Ждемс...

Обычно зависал раз в 3-5 дней.

[Hawk128]

Полет пока что нормальный.

 

Не получил ответа на свой второй вопрос, на всякий случай повторяю:

 

Еще попутно вопрос, пробовал на обычно Athlon 64 x2 гонять Freebsd amd64 различные версии, никаких проблем все хорошо, а вот на интеле после меню выбора загрузки перед загрузкой ядра долгая пауза (30-40 сек примерно). Что это может быть? Поиск уже измучил, ничего не нашел. На АМДшной системе этот момент проходит без задержки (0-0.5 сек).

[Diman]

Не стал дальше эксперементировать на пользователях. Убрал эту опцию из ядра.

Ииии...?

Стало работать?

[root@serv11 ~]# uname -a

FreeBSD serv11 8.0-STABLE FreeBSD 8.0-STABLE #1: Tue Mar 9 14:08:12 MSK 2010 diman@serv11:/usr/src/sys/amd64/compile/SERV11v8 amd64

[root@serv11 ~]# uptime

14:24 up 3 days, 3:33, 1 user, load averages: 0,63 0,43 0,40

[root@serv11 ~]# ifconfig | grep ng | wc -l

96

[root@serv11 ~]# ps ax | grep flowcleaner | grep -v grep

[root@serv11 ~]#