Elisium Опубликовано 27 января, 2010 · Жалоба Доброго дня всем. Стояла-жила себе машинка под биллинг+дхцп на какойто древней дешевой мамке Интел с одним гигом памяти. После ее благополучной кончины винты (зеркальный рейд) были перенесены на новую материнку + два гига памяти. Поработавши несколько часов, глянул на биллинг и увидел такую картину: last pid: 18516; load averages: 0.39, 0.44, 0.42 up 0+03:46:19 01:15:17 149 processes: 4 running, 130 sleeping, 15 waiting CPU: 8.6% user, 0.0% nice, 2.8% system, 0.0% interrupt, 88.5% idle Mem: 1084M Active, 506M Inact, 264M Wired, 21M Cache, 207M Buf, 41M Free Swap: 1024M Total, 756M Used, 268M Free, 73% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1909 root 1 46 0 1965M 767M select 0 2:59 0.00% flow-capture 1886 mysql 38 44 0 532M 117M ucond 0 0:04 1.95% mysqld 10052 root 1 8 -15 196M 157M nanslp 0 11:08 7.08% perl5.8.9 18226 www 1 20 0 168M 10096K lockf 1 0:00 0.00% httpd 18225 www 1 20 0 168M 9980K lockf 1 0:00 0.00% httpd 18227 www 1 20 0 168M 9980K lockf 1 0:00 0.00% httpd 18394 www 1 20 0 168M 9960K lockf 0 0:00 0.00% httpd 18384 www 1 20 0 168M 9960K lockf 1 0:00 0.00% httpd 18395 www 1 4 0 168M 9960K kqread 0 0:00 0.00% httpd 18140 www 1 20 0 168M 9948K lockf 1 0:00 0.00% httpd 18469 www 1 20 0 168M 9940K lockf 1 0:00 0.00% httpd 18479 www 1 20 0 168M 9940K lockf 1 0:00 0.00% httpd 17889 www 1 20 0 168M 6820K lockf 0 0:00 0.00% httpd 1967 root 1 44 0 167M 9440K select 0 0:01 0.00% httpd 12275 root 1 44 0 36668K 5668K select 0 0:01 0.00% mc 12125 kuger 1 44 0 33772K 3464K select 1 0:00 0.00% sshd 12113 root 1 4 0 33772K 0K sbwait 1 0:00 0.00% <sshd> 2098 root 1 59 -15 32816K 8708K select 0 3:30 0.00% perl5.8.9 2099 root 1 8 -15 27652K 5668K nanslp 0 7:52 0.88% perl5.8.9 1542 root 1 44 0 27452K 2580K select 0 5:01 0.00% snmpd 1985 root 1 44 0 22880K 0K select 1 0:00 0.00% <sshd> 1991 root 1 44 0 10700K 1144K select 0 0:00 0.00% sendmail 1995 smmsp 1 20 0 10700K 0K pause 0 0:00 0.00% <sendmail> 12277 root 1 8 0 9020K 1232K wait 1 0:00 0.00% bash 12128 root 1 8 0 9020K 0K wait 0 0:00 0.00% <bash> 12127 kuger 1 8 0 9020K 0K wait 0 0:00 0.00% <bash> 18507 root 1 44 0 8116K 1924K CPU0 0 0:00 0.00% top 1947 root 1 -58 0 7848K 3388K bpf 0 0:00 0.00% arpwatch 1944 root 1 -58 0 7848K 3380K bpf 1 0:00 0.00% arpwatch 1950 root 1 -58 0 7848K 3356K bpf 0 0:00 0.00% arpwatch 1920 root 1 -58 0 7848K 3228K bpf 0 0:00 0.00% arpwatch 1926 root 1 -58 0 7848K 3124K bpf 0 0:00 0.00% arpwatch 1938 root 1 -58 0 7848K 3120K bpf 0 0:00 0.00% arpwatch 1929 root 1 -58 0 7848K 3116K bpf 0 0:00 0.00% arpwatch 1917 root 1 -58 0 7848K 3116K bpf 0 0:00 0.00% arpwatch 1923 root 1 -58 0 7848K 3116K bpf 0 0:00 0.00% arpwatch 1932 root 1 -58 0 7848K 3112K bpf 0 0:00 0.00% arpwatch 1941 root 1 -58 0 7848K 3112K bpf 0 0:00 0.00% arpwatch 1959 root 1 -58 0 7848K 3104K bpf 0 0:00 0.00% arpwatch 1914 root 1 -58 0 7848K 3096K bpf 1 0:00 0.00% arpwatch 1953 root 1 -58 0 7848K 3096K bpf 0 0:00 0.00% arpwatch 1956 root 1 -58 0 7848K 3096K bpf 0 0:00 0.00% arpwatch а конкретнее ВОТ: 1909 root 1 46 0 1965M 767M select 0 2:59 0.00% flow-capture Материнки отличаются чипсетом (ICH10 вместо вроде ICH7), памятью (2ГБ вместо 1 ГБ) и сетевухой (em0 вместо re0) На старой материнке flow-capture изредка падал и поднимался обратно скриптом, но СТОЛЬКО он не отьедал. Проц Е6300. FreeBSD nodeny 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 2 08:22:32 UTC 2009 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Все установленые проги последние из портов. Гугль по отьеданию памяти именно flow-capture не выдал ничего внятного. Может кто сталкивался/видел/решил подобное ? Спасибо заранеее всем комментаторам по делу )) п.с. на текущий момент вопрос решается рестартом flow-capture раз в три часа ((((( п.п.с. ах да ... средний суммарный поток через шлюз, с которого снимается нетфлов статистика, 400 МБт, а в пиках 1,5 ГБт Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 28 января, 2010 · Жалоба В портах есть flow-tools и flow-tools-ng. Какой из них установлен? Гугл по запросу "flow-capture memory" выдаёт много описаний похожей проблемы, в т.ч. с патчами, например: http://code.google.com/p/flow-tools/issues/detail?id=9 http://mailman.splintered.net/pipermail/fl...ary/003073.html Одна из проблем возникает на amd64 из-за 32-битных типов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ash Опубликовано 28 января, 2010 · Жалоба А вы патчили flow-tools для работы в 64ой freebsd? Если интересно скину патчики. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Elisium Опубликовано 29 января, 2010 (изменено) · Жалоба Ilya Evseev О!! Спасибо за ссылки!! Будем пробовать ... ash Нет, не патчил. У меня даже и мысли не возникло, что такая давняя проблема и до сих пор не решена официально. Да и ДО этого всего стояла версия х32 и только позже перелез на х64. Но вот такой отжор памяти заметил только сейчас ((( Изменено 29 января, 2010 пользователем Elisium Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Elisium Опубликовано 31 января, 2010 · Жалоба Ой .. забыл отписАться: поставил вместо flow-tools flow-tool-ng. Пока полет нормальный - память не есть, трафик считает вроде как верно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...