Kucher2 122 Опубліковано: 2010-11-07 20:50:59 Автор Share Опубліковано: 2010-11-07 20:50:59 Тут не сервер менять нужно, а структуру софта. Не должно быть на двухядерной машине при 50мбит трафика загрузки в 50%.. Или фаервол излишне перегружен правилами, или шейпер без хешей тупит(падение загрузки в 2 раза это подтверждает в принципе). Даже NAT при таком трафике должен быть незаметен. Двухядерник самый слабый правда, старенький Celeron. И материнка непонятного производства. "Шейпер без хешей" - вас ис дас, конкретнее? net.inet.ip.dummynet.hash_size=64 Попробовал net.inet.ip.dummynet.hash_size=16384 Без изменений. Думаю действительно не справляется железо. Или ему тоже время надо, чтоб подействовало? После применения net.inet.ip.dummynet.hash_size=16384 В течении 5-10 мин interrupt упал примерно с 45% до 25%. Сижу играюсь с правилами allow all from any to any: после их применения перед pipe - interrupt падает с 25% теперь всего лишь до 18-20%. Посмотрел трафик - такой же как был и пакетов около 5000 на внешнем ИФ. Помогло, что ли? Ссылка на сообщение Поделиться на других сайтах
KaYot 3 710 Опубліковано: 2010-11-07 21:17:54 Share Опубліковано: 2010-11-07 21:17:54 Ну 20% для хилой машины при 50мбит в принципе нормально. 200мбит в нее влезет, а больше и не нужно Ссылка на сообщение Поделиться на других сайтах
Kucher2 122 Опубліковано: 2010-11-07 21:26:28 Автор Share Опубліковано: 2010-11-07 21:26:28 Я думаю trafshow врёт, т.к. периодически ещё 50Мбит бывает дополнительно, када народ с паритетов качает, но видно их чётко только на графике, который по count рисуется. На trafshow показаний выше 60Мбит я у себя вообще никогда не видел, к тому же эта штука сильно грузит ситему когда его стартуешь на "-i <ext_if> -n", поэтому в его показания не особо верится. По графику внизу видно как повлияли Ваши советы и мои манипуляции. Может ещё чего-то не учёл, помониторю-погляжу. 200мбит в нее влезет, а больше и не нужно Я почему-то так и думал, 200-250. Всем большое спасибо, отпишусь как оно. P.S. И всё равно я почти счастлив, что перешёл на ipfw nat. Ссылка на сообщение Поделиться на других сайтах
gurov 0 Опубліковано: 2010-11-08 04:35:59 Share Опубліковано: 2010-11-08 04:35:59 Доброго времени суток всем. Прошу помочь советом это мой второй сервер на Freebsd. Вышел из строя действующий сервер, пришлось в срочном порядке принимать меры. На новое железо (core 2 duo e7400, ddr2 kingston 1066, мать gygabyte ep45-ds3 с двумя интегрированными сетевыми) поставил 8.0-RELEASE#0 Было собрано ядро с добавлением опций options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_PRIQ options ALTQ_NOPCC device pf device pflog device pfsync Поднят кеширующий dns, dhcp, openvpn. Выход в Интернет посредством ppp поднимается tun интерфейс, нат средствами PF. Что беспокоит - пинги. При простое все в норме, но только запускается торрент или тянут видео с видеохостингов даже если не полностью грузят канал (хотя он и так узковат 2Мб) пинг с 60мс вырастает до 300 и выше! При соединении через ВПН работать по RDP уже не реально. Выключил все правила фильтрации греша на PF - не помогло, отключил PF вовсе, запустил NAT средствами самого ppp - ни каких изменений. Решил вернуть PF и разделить трафик по приоритетами через cbq - пинги по прежнему высокие, но работать стало еще хуже. Даже будучи в сети набирать команды по SSH стало невыносимо, отключил оставил только НАТ опять. Загрузка на проц в норме interrupt более 2-х процентов не поднимается. Подскажите куда копать пожалуйста. Ссылка на сообщение Поделиться на других сайтах
KaYot 3 710 Опубліковано: 2010-11-08 06:11:30 Share Опубліковано: 2010-11-08 06:11:30 Я думаю trafshow врёт, т.к. периодически ещё 50Мбит бывает дополнительно, када народ с паритетов качает, но видно их чётко только на графике, который по count рисуется. На trafshow показаний выше 60Мбит я у себя вообще никогда не видел, к тому же эта штука сильно грузит ситему когда его стартуешь на "-i <ext_if> -n", поэтому в его показания не особо верится. Поставь утилиту ifstat, показывает трафик через интерфейсы с точностью до байта на любых скоростях в онлайне и совершенно не грузит систему. Трафшоу у меня на гигабитном потоке мегабит 100 показывает Ссылка на сообщение Поделиться на других сайтах
KaYot 3 710 Опубліковано: 2010-11-08 06:13:31 Share Опубліковано: 2010-11-08 06:13:31 Что беспокоит - пинги. При простое все в норме, но только запускается торрент или тянут видео с видеохостингов даже если не полностью грузят канал (хотя он и так узковат 2Мб) пинг с 60мс вырастает до 300 и выше! При соединении через ВПН работать по RDP уже не реально. Выключил все правила фильтрации греша на PF - не помогло, отключил PF вовсе, запустил NAT средствами самого ppp - ни каких изменений. Решил вернуть PF и разделить трафик по приоритетами через cbq - пинги по прежнему высокие, но работать стало еще хуже. Даже будучи в сети набирать команды по SSH стало невыносимо, отключил оставил только НАТ опять. Загрузка на проц в норме interrupt более 2-х процентов не поднимается. Подскажите куда копать пожалуйста. Conntrack скорее всего забыли увеличить. Ссылка на сообщение Поделиться на других сайтах
gurov 0 Опубліковано: 2010-11-08 06:30:53 Share Опубліковано: 2010-11-08 06:30:53 Conntrack скорее всего забыли увеличить. Честно говоря даже не думал что это необходимо. Нагрузка на сервер все таки не большая, до 20 пользователей плюс около 5 удаленных. Задача стабильно раздавать интернет с определенными приоритетами и обеспечивать работу удаленных пользователей, все это на 2Мб. А такое поведение наблюдается даже при самой малой нагрузке, достаточно с одного хоста торрент запустить. Почитав тему грешил на pf, но его отключение ни к чему не привело. Нагрузка на процессор минимальная, думаю может в сетевых проблема или в ppp, неоднократно слышал рекомендации использовать вместо ppp mpd. Ссылка на сообщение Поделиться на других сайтах
KaYot 3 710 Опубліковано: 2010-11-08 07:11:09 Share Опубліковано: 2010-11-08 07:11:09 Ну раз используется НАТ и при большом числе сессий сервер начинает тупить - логично грешить на контрак, благо его увеличить для проверки проще всего.. Ссылка на сообщение Поделиться на других сайтах
gurov 0 Опубліковано: 2010-11-08 07:14:19 Share Опубліковано: 2010-11-08 07:14:19 Ну раз используется НАТ и при большом числе сессий сервер начинает тупить - логично грешить на контрак, благо его увеличить для проверки проще всего.. Спасибо за помощь, обязательно попробую. Ссылка на сообщение Поделиться на других сайтах
Kucher2 122 Опубліковано: 2010-11-08 08:34:10 Автор Share Опубліковано: 2010-11-08 08:34:10 Доброго времени суток всем. Прошу помочь советом это мой второй сервер на Freebsd. Вышел из строя действующий сервер, пришлось в срочном порядке принимать меры. На новое железо (core 2 duo e7400, ddr2 kingston 1066, мать gygabyte ep45-ds3 с двумя интегрированными сетевыми) поставил 8.0-RELEASE#0 Было собрано ядро с добавлением опций options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_PRIQ options ALTQ_NOPCC device pf device pflog device pfsync Поднят кеширующий dns, dhcp, openvpn. Выход в Интернет посредством ppp поднимается tun интерфейс, нат средствами PF. Что беспокоит - пинги. При простое все в норме, но только запускается торрент или тянут видео с видеохостингов даже если не полностью грузят канал (хотя он и так узковат 2Мб) пинг с 60мс вырастает до 300 и выше! При соединении через ВПН работать по RDP уже не реально. Выключил все правила фильтрации греша на PF - не помогло, отключил PF вовсе, запустил NAT средствами самого ppp - ни каких изменений. Решил вернуть PF и разделить трафик по приоритетами через cbq - пинги по прежнему высокие, но работать стало еще хуже. Даже будучи в сети набирать команды по SSH стало невыносимо, отключил оставил только НАТ опять. Загрузка на проц в норме interrupt более 2-х процентов не поднимается. Подскажите куда копать пожалуйста. Почитайте эту тему с самого начала, здесь пройден путь из той же точки, что и у Вас. Начните с того что показывают утилиты о состоянии загрузки системы и канала. И как Вы шейпите трафик PF в обе стороны? Лично я так и не смог заставить PF резать трафик нормально, поэтому сидел на связке ipfw + PF. Не лучший вариант, как оказалось, но по крайней мере ipfw с нарезкой справлялся "на ура". 2Мбита - развернуться негде, не завидую. Какие уж тут торренты на такое кол-во клиентов. Ссылка на сообщение Поделиться на других сайтах
gurov 0 Опубліковано: 2010-11-08 09:32:19 Share Опубліковано: 2010-11-08 09:32:19 Почитайте эту тему с самого начала, здесь пройден путь из той же точки, что и у Вас. Начните с того что показывают утилиты о состоянии загрузки системы и канала. И как Вы шейпите трафик PF в обе стороны? Лично я так и не смог заставить PF резать трафик нормально, поэтому сидел на связке ipfw + PF. Не лучший вариант, как оказалось, но по крайней мере ipfw с нарезкой справлялся "на ура". 2Мбита - развернуться негде, не завидую. Какие уж тут торренты на такое кол-во клиентов. У меня особо резать и нечего 2Мб\512Кб С таким upload -ом даже не стал ничего делать, так как шансов на увеличение скорости в дальнейшем нет. А вот 2Мб довольно успешно, средствами pf на внутреннем интерфейсе, разбил по приоритетам с возможностью занятия свободной полосы при неактивности отдельных пользователей. И все было бы хорошо если бы не эти чудеса с повышением задержек. Тему читаю по n-му кругу, отслеживаю нагрузку при любых изменениях - придраться не к чему, можно было бы попробовать ipfw , но почти уверен что дело не в pf, так как и при нате средствами ppp без всяких правил, банальным тестом speedtest.net запущенным с любого хоста в сети, можно добиться повышения пингов до 500 мс. Модификаций в ядре ни каких кроме указанных не делал, даже устройства которые не используются не убирал, все штатное на чистой ОС. P.S. Как увеличить сonntrack во freebsd не нашел, пробовал как в линуксе через sysctl не получилось (правда и в логах чисто по этому параметру). Я к сожалению вообще в Unix системах пока еще новичек, еще не давно сидел только на WIN серверных ОС. Так что если подскажете подробнее буду благодарен. Ссылка на сообщение Поделиться на других сайтах
Kucher2 122 Опубліковано: 2010-11-08 09:54:12 Автор Share Опубліковано: 2010-11-08 09:54:12 Поскольку у Вас канал мал и несимметричен и скорее всего ещё и ADSL (или я не прав? ), то "уложить" его банальным speedtest, а уж тем более торрентами - раз плюнуть. А Вы пробовали просто подкинуть машину на Windows и сделать то же самое, например speedtest, при этом замеряя пинг? Может дело не в сервере? И потом, Вы уверены, что pf правильно режет трафик? У меня была проблема порезать именно исходящий трафик на pf. Стоит та же операционка, что и у Вас - FreeBSD 8. Тоже почти ничего не трогал. Она с небольшой нагрузкой обычно по-умолчанию замечательно работает. Ссылка на сообщение Поделиться на других сайтах
gurov 0 Опубліковано: 2010-11-08 10:26:21 Share Опубліковано: 2010-11-08 10:26:21 Поскольку у Вас канал мал и несимметричен и скорее всего ещё и ADSL (или я не прав? ), то "уложить" его банальным speedtest, а уж тем более торрентами - раз плюнуть. А Вы пробовали просто подкинуть машину на Windows и сделать то же самое, например speedtest, при этом замеряя пинг? Может дело не в сервере? И потом, Вы уверены, что pf правильно режет трафик? У меня была проблема порезать именно исходящий трафик на pf. Стоит та же операционка, что и у Вас - FreeBSD 8. Тоже почти ничего не трогал. Она с небольшой нагрузкой обычно по-умолчанию замечательно работает. Вы совершенно правы это ADSL (от Укртелекома). Для чистоты эксперимента я до того как писать пытался проводить замеры используя в качестве сервера машину на WIN 2003 с ISA, на спидтесте она тоже показала завышенный пинг но не такой как сейчас (хотя это было в 12 часов ночи и пользователей еще не было, сейчас же они тоже включились в тестирование потягивая трафик ) поэтому вполне может быть что результаты ухудшились. Более не представляется возможным тестить на WIN машине так как она окончательно вышла из строя(вздутые кондеры больше не выдержали),а новый сервер к утру надо было поставить. Возможно бессонная ночь и настройка в сжатые сроки и сказались, правила по нарезке пока отключил но пока пользователей было с утра немного, я отслеживал скорость их соединения все работало так как указал (резал входящий трафик согласно документации на внутреннем сетевом интерфейсе) результатом работы очередей и приоритетов доволен, но при этом пинг был на грани и как уже писал выше зайти по ssh и вызвать тот же MC - как будто через gprs удаленно работаешь, а не из локальной сети. Ранее в этом месте не был поэтому сказать как было раньше затрудняюсь, но пользуясь тем что сейчас в здании отключат свет до вечера, увезу сервер к себе и запущу в проверенном месте на хорошем канале. О результатах напишу. Большое спасибо за желание помочь. Ссылка на сообщение Поделиться на других сайтах
gurov 0 Опубліковано: 2010-11-08 16:21:48 Share Опубліковано: 2010-11-08 16:21:48 Ув. Kucher2, вы оказались правы. Я зря грешил на сервер и тщетно искал причину. Перевез сервер в место со стабильным Интернетом, подправил конфиги и таких проблем больше не было. Вернулся назад нашел ПК с двумя сетевыми и WIN XP на борту, поднял на нем PPOE от модема и через ICS раздал в сеть, при спидтесте и торрентах пинг растет в гору. Так что это проблема линии, заметил только что пинги относительно в пределах нормы (80-95мс) когда не выше 1Мб то есть половины канала. Но как только начинаю резать средствами pf все работает, но пинги возрастают в полтора раза, неужели из-за технологии приоритезации трафика? Надо наверно искать альтернативный способ для шейпинга. Вы кстати говорили что решили с помощью pf и ipfw, можете натолкнуть на этот путь если такой способ работает. P.S. но главная проблема снята и это радует. С самим сервером все ок Ссылка на сообщение Поделиться на других сайтах
Kucher2 122 Опубліковано: 2010-11-08 17:23:39 Автор Share Опубліковано: 2010-11-08 17:23:39 Рад за Вас. По поводу Вашей проблемы - я могу ошибаться, но по-моему pf плохо справляется с нарезкой исходящего трафика. Возможно отсюда все беды. Во всяком случае именно поэтому я им и не стал ничего резать, а воспользовался ipfw. Сейчас конечно может уже сделали чего-то, давно было. По поводу ADSL - можно попробовать поиграться настройками модема и потестить. Возможно изменение модуляции даст свои плоды ещё какие-нибудь настройки. Как крайняя мера - снижение скорости соединения. На двух мегабитах, особенно с исходом в 512К - пинг и будет расти, от этого никуда не денешься. Ясное дело, что если у Вас забит исходящий - будет та же свистопляска (вот почему я заговорил на счёт pf, сомнения у меня что он режет исход). Приоретизация и нарезка трафика на такой скорости естественно повысит пинги (особенно если ICMP у Вас имеет низкий приоритет), ибо механизм того же шейпа подразумевает дроп (отброс) пакетов, когда переполняется очередь шейпа. Чем уже канал, тем это заметнее. Повышение пинга на более узком канале по сравнени с широким - закономерность. Я у себя это наблюдаю, когда тестирую нарезку, допустим, 256Кбит. Разница в пингах между 256К и 2048К - довольно существенная. Я не настолько хорошо разбираюсь в этом, чтоб конкретно к Вашей ситуации советовать применить тот или иной способ: у меня до сих по существует проблема в работе сервера, как сегодня оказалось. Но на Вашем канале пожалуй это нормально будет работать и никаких заморочек с правилами. Смысл в том, чтобы оставить за pf право натить внутренню сеть в Инет и заниматься пробросом портов/адресов, а ipfw прикрутить как шейпер. Почитайте это: http://local.com.ua/forum/topic/20228-помогите-с-pf/page__p__149597__hl__ipfw%2Bpf__fromsearch__1#entry149597 и ещё тут: http://local.com.ua/forum/topic/20234-шейпер-на-pf/page__p__149645__hl__ipfw%2Bpf__fromsearch__1#entry149645 Там кстати человек пишет, что pf по дефолту шейпит только в одну сторону. PF не работает с gre-пакетами, которые нужны для работы VPN. Лечится пробросом портов, но работать сможет одновременно только одна машина (подключаться к мировым VPN) или проброс белого IP на машину в сеть. Я натыкался на ешё один способ, в котором рассматривалась проблема работы связки ipfw+nat и настройка VPN через это всё, но у меня не заработало почему-то. Так и промучался, пока не вернулся на родной NAT. Ссылка на сообщение Поделиться на других сайтах
Kucher2 122 Опубліковано: 2010-11-08 18:34:55 Автор Share Опубліковано: 2010-11-08 18:34:55 Эта какой-то ППЦ. Трафик 4-8Мбайт входящего и 2-4Мбайт исходящий. 3000-5000pps. Потери пакетов (пингую с сервера - шлюз провайдера) до 10%. Выходит зря промучался. Конечно если не считать побеждённый IPFW NAT. Судя по графику загрузки системы - это связано именно с нагрузкой на тазик, т.е. медный линк (5-7метров) между мегабитной сетевой картой и медиаконвертером тут ни при чём, равно как и провайдер не виноват. Не виноват и софтовый роутер на FreeBSD, тем более что он ничем кроме роутинга не занят и по идее может прокачать дохрени трафа (старенький пень 2,8ГГЦ и 2ГГБ ОЗУ, 3 реалтека и одна встроенная гигабитная карточка). Гложет мысль, что валится это всё числом сессий, но пока не нашёл способа выяснить как всё же посмотреть такую статистику на ipfw nat (на pf это можно было делать, но не догадался глянуть в своё время). А счастье было так близко. Придётся таки менять железку. ipfw nat 1 show nat 1: icmp=7, udp=16490, tcp=35463, sctp=0, pptp=0, proto=0, frag_id=1 frag_ptr=0 / tot=51961 Ссылка на сообщение Поделиться на других сайтах
andryas 1 059 Опубліковано: 2010-11-08 18:51:17 Share Опубліковано: 2010-11-08 18:51:17 Поллинг с ядра выброшен? Всё-же проц аномально загружен, как для такого траффика. Потери на интерфейсах есть? Траффик и потери: netstat -w 1 -d netstat -w 1 -I igb0 Также смотреть траффик: systat -ifstat 1 или поставить ifstat, и ifstat -bi igb0 Ссылка на сообщение Поделиться на других сайтах
KaYot 3 710 Опубліковано: 2010-11-08 19:06:13 Share Опубліковано: 2010-11-08 19:06:13 Судя по top'у загрузка в норме, <50%. А по последнему графику загрузка под 100%, кто из них прав? Ну и если шейперы временно выкинуть из схемы(ничего страшного если в час пик делать, если у юзеров чуть просядет скорость но исчезнут потери они только рады будут), ситуация меняется? И что используется в качестве шейпера? Может это банальная перегрузка канала и как раз шейпер дает потери? Посмотрите ifstat'ом реальный трафик через интерфейсы. У меня ненамного лучше машина работающая в качестве временного НАСа по linux(какой-то младший core2 duo 2.0Ггц) сейчас лопатит мегабит 300, с натом, шейперами, pppoe и обменом маршрутами по ospf.. Загрузка в час пик до 40% на ядро, никаких чудес. Ссылка на сообщение Поделиться на других сайтах
Kucher2 122 Опубліковано: 2010-11-08 19:13:02 Автор Share Опубліковано: 2010-11-08 19:13:02 Поллинг выключен и вообще выкинут из ядра, т.к. стоит сетевая Intel двухголовая. ifstat -bi igb0 Kbps in Kbps out 29538.57 32567.03 27824.76 29472.26 26665.32 29232.82 28348.63 35206.67 29320.35 31845.23 33039.57 30827.58 30806.07 32500.48 30298.16 33006.48 30034.11 33646.15 28354.57 34425.53 28079.93 32097.64 26523.55 32525.14 30895.39 34709.90 27648.48 35777.17 27251.39 34492.13 27995.45 33320.69 27723.84 30988.97 27858.69 30926.13 25976.54 32575.26 28588.74 32604.11 27886.45 35328.21 25322.13 32181.69 netstat -w 1 -d input (Total) output packets errs bytes packets errs bytes colls drops 12151 0 9174157 11964 0 9117579 0 0 12204 0 9105880 12068 0 9109103 0 0 12198 0 9328634 11991 0 9276049 0 0 11977 0 8946527 11786 0 8903867 0 0 12159 0 9224388 12019 0 9196752 0 0 12113 0 9165911 11782 0 8979819 0 0 12229 0 9090506 12046 0 9123520 0 0 12161 0 8868137 11925 0 8741512 0 0 11748 0 8780555 11464 0 8628909 0 0 11809 0 8758810 11539 0 8609003 0 0 12376 0 9051216 12116 0 8957422 0 0 11651 0 8455918 11521 0 8479200 0 0 12411 0 9084297 12191 0 8948253 0 0 11757 0 8456806 11567 0 8433097 0 0 11666 0 8751484 11408 0 8609047 0 0 11608 0 8654554 11399 0 8564594 0 0 11000 0 7839972 10836 0 7748067 0 0 11687 0 8499644 11487 0 8472204 0 0 11731 0 8493201 11452 0 8334278 0 0 12564 0 8757841 12234 0 8576710 0 0 netstat -w 1 -l igb0 input (Total) output packets errs bytes packets errs bytes colls 11472 0 8330377 11314 0 8310082 0 11613 0 8624010 11440 0 8551662 0 12418 0 8992147 12085 0 8784117 0 11280 0 8376651 11157 0 8340652 0 11903 0 8670950 11790 0 8717275 0 12595 0 9333740 12276 0 9152489 0 12402 0 9058609 12181 0 8894729 0 11565 0 8889805 11263 0 8783651 0 11604 0 8475820 11436 0 8442891 0 11985 0 8925220 11689 0 8663824 0 11307 0 8466162 11247 0 8599252 0 11997 0 8994348 11860 0 8993543 0 11384 0 8678503 11098 0 8477892 0 11453 0 8709887 11272 0 8636005 0 11470 0 8901509 11367 0 8916036 0 Пинг вырос с 1 до 6-10мс, ну и дропы пакетов идут. Бл#. Причём поблемы с дропом и высоким пингом толко наружу, из сетки я свой шлюз пингую - всё ок. Ссылка на сообщение Поделиться на других сайтах
andryas 1 059 Опубліковано: 2010-11-08 19:14:23 Share Опубліковано: 2010-11-08 19:14:23 Нету никаких потерь, судя по листингам. Посмотрите ещё на втором интерфейсе. и ещё: netstat -s |grep drop netstat -ssp udp vmstat -z Вообще-то с таким детским траффиком легко справится микротик, благо, в нём всё уже оттюнено. По моим наблюдениям, фря примерно на 30% быстрее, но, возможно, не в Вашем случае. Для теста поставьте мтик и сравните. Ссылка на сообщение Поделиться на других сайтах
Kucher2 122 Опубліковано: 2010-11-08 19:25:15 Автор Share Опубліковано: 2010-11-08 19:25:15 У меня просто кончились идеи. Нагрузка на систему действительно аномальная. Материнка ASUS P5KPL-AM SE, вот такая. Я подозреваю, что сначала надо сменить таки железку. netstat -s |grep drop 12921 connections closed (including 713 drops) 3 embryonic connections dropped 33 connections dropped by rexmit timeout 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 connections dropped by keepalive 63 dropped 25251621 dropped due to no socket 0 dropped due to full socket buffers Packet drop statistics: 0 where process_chunk_drop said break 0 number of in data drops due to chunk limit reached 0 number of in data drops due to rwnd limit reached 0 fragments dropped (dup or out of space) 2 fragments dropped after timeout 0 output packets dropped due to no bufs, etc. 0 group-source queries dropped 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 output packets dropped due to no bufs, etc. 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers netstat -ssp udp udp: 28591703 datagrams received 12 with bad data length field 3540 with bad checksum 543227 with no checksum 25256380 dropped due to no socket 146 broadcast/multicast datagrams undelivered 3331625 delivered 3381967 datagrams output vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 128, 0, 91, 29, 91, 0 UMA Zones: 888, 0, 91, 1, 91, 0 UMA Slabs: 284, 0, 899, 11, 31574, 0 UMA RCntSlabs: 544, 0, 5867, 6, 5867, 0 UMA Hash: 128, 0, 3, 27, 4, 0 16 Bucket: 76, 0, 58, 42, 79, 0 32 Bucket: 140, 0, 84, 0, 107, 0 64 Bucket: 268, 0, 113, 13, 159, 13 128 Bucket: 524, 0, 1120, 0, 107466, 479 VM OBJECT: 136, 0, 58438, 9190, 86118571, 0 MAP: 140, 0, 7, 21, 7, 0 KMAP ENTRY: 72, 77910, 26, 239, 95275, 0 MAP ENTRY: 72, 0, 3506, 681, 167957112, 0 DP fakepg: 72, 0, 0, 0, 0, 0 SG fakepg: 72, 0, 0, 0, 0, 0 mt_zone: 2056, 0, 279, 0, 279, 0 16: 16, 0, 2627, 621, 31977391, 0 32: 32, 0, 2738, 1556, 11378462, 0 64: 64, 0, 5545, 8792, 31828327, 0 128: 128, 0, 86040, 11400, 104947906, 0 256: 256, 0, 1221, 1314, 2540536370, 0 512: 512, 0, 400, 184, 3945519, 0 1024: 1024, 0, 35, 145, 114634, 0 2048: 2048, 0, 361, 103, 862, 0 4096: 4096, 0, 106, 87, 5388483, 0 Files: 56, 0, 243, 494, 45056181, 0 TURNSTILE: 72, 0, 211, 29, 211, 0 umtx pi: 52, 0, 0, 0, 0, 0 MAC labels: 20, 0, 0, 0, 0, 0 PROC: 680, 0, 69, 63, 5217770, 0 THREAD: 572, 0, 183, 27, 265, 0 SLEEPQUEUE: 32, 0, 211, 143, 211, 0 VMSPACE: 232, 0, 51, 102, 5217743, 0 cpuset: 40, 0, 2, 182, 2, 0 audit_record: 816, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 0, 384, 1198, 0 mbuf: 256, 0, 16684, 2912, 5348327211, 0 mbuf_cluster: 2048, 25600, 8845, 2889, 2755792782, 0 mbuf_jumbo_page: 4096, 12800, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 406, 119406, 0 NetGraph items: 36, 4130, 0, 177, 22, 0 NetGraph data items: 36, 531, 0, 236, 947232, 0 g_bio: 140, 0, 0, 3472, 7105865, 0 ttyinq: 152, 0, 150, 84, 15465, 0 ttyoutq: 256, 0, 80, 40, 8248, 0 ata_request: 200, 0, 0, 931, 1789133, 0 ata_composite: 180, 0, 0, 0, 0, 0 VNODE: 268, 0, 82087, 9053, 1479039, 0 VNODEPOLL: 60, 0, 0, 0, 0, 0 S VFS Cache: 72, 0, 90331, 8143, 1674598, 0 L VFS Cache: 292, 0, 197, 713, 12885, 0 NAMEI: 1024, 0, 0, 48, 78807575, 0 DIRHASH: 1024, 0, 908, 52, 973, 0 NFSMOUNT: 520, 0, 0, 0, 0, 0 NFSNODE: 464, 0, 0, 0, 0, 0 pipe: 392, 0, 9, 61, 3265184, 0 ksiginfo: 80, 0, 121, 935, 121, 0 itimer: 220, 0, 0, 0, 0, 0 KNOTE: 68, 0, 34, 358, 13659230, 0 socket: 412, 32769, 87, 264, 1382453, 0 ipq: 32, 904, 0, 339, 773, 0 udp_inpcb: 220, 32778, 38, 268, 1248689, 0 udpcb: 8, 32886, 38, 571, 1248689, 0 tcp_inpcb: 220, 32778, 25, 83, 12947, 0 tcpcb: 632, 32772, 24, 48, 12947, 0 tcptw: 52, 6624, 1, 359, 2720, 0 syncache: 112, 15365, 0, 175, 13466, 0 hostcache: 76, 15400, 23, 127, 729, 0 tcpreass: 20, 1690, 0, 338, 783, 0 sackhole: 20, 0, 0, 338, 1466, 0 sctp_ep: 848, 32768, 0, 0, 0, 0 sctp_asoc: 1460, 40000, 0, 0, 0, 0 sctp_laddr: 24, 80040, 0, 290, 10, 0 sctp_raddr: 420, 80001, 0, 0, 0, 0 sctp_chunk: 96, 400000, 0, 0, 0, 0 sctp_readq: 76, 400000, 0, 0, 0, 0 sctp_stream_msg_out: 64, 400020, 0, 0, 0, 0 sctp_asconf: 24, 400055, 0, 0, 0, 0 sctp_asconf_ack: 24, 400055, 0, 0, 0, 0 ripcb: 220, 32778, 3, 87, 50330, 0 unpcb: 172, 32775, 20, 95, 70460, 0 rtentry: 108, 0, 31, 77, 33, 0 IPFW dynamic rule: 108, 0, 0, 0, 0, 0 selfd: 28, 0, 174, 461, 1447055671, 0 ip4flow: 40, 4140, 3881, 259, 19046066, 105285 ip6flow: 64, 4118, 0, 0, 0, 0 SWAPMETA: 276, 121576, 0, 0, 0, 0 Mountpoints: 644, 0, 5, 13, 5, 0 FFS inode: 116, 0, 82050, 9096, 1478957, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 82050, 9075, 1478932, 0 netstat -w 1 -l igb1 input (Total) output packets errs bytes packets errs bytes colls 10788 0 8151785 10479 0 7888692 0 11241 0 8662970 11021 0 8522010 0 11369 0 8433869 11163 0 8342184 0 10788 0 8047539 10461 0 7808241 0 10949 0 8135217 10741 0 8004784 0 11253 0 8455210 11006 0 8323388 0 11438 0 8597379 11280 0 8481065 0 11868 0 9020864 11552 0 8851724 0 11366 0 8559007 11056 0 8351789 0 11437 0 8834409 11260 0 8770704 0 10467 0 7786539 10227 0 7644304 0 11154 0 8263959 10934 0 8139978 0 10997 0 7718177 10759 0 7587859 0 10064 0 7351179 9871 0 7218422 0 11050 0 8186555 10784 0 8031280 0 11158 0 8115181 10964 0 8027404 0 11189 0 8244352 10902 0 8002226 0 11156 0 8324024 10898 0 8181903 0 11042 0 8111127 10796 0 7977523 0 10832 0 7705592 10603 0 7610330 0 Ссылка на сообщение Поделиться на других сайтах
andryas 1 059 Опубліковано: 2010-11-08 19:28:46 Share Опубліковано: 2010-11-08 19:28:46 Возможно, загрузка высока, но потерь нет. Есть подозрение, что что-то не так в шейперах, возможно какой-то шейпер случайно обрабатывает общий траффик. Потери обычно начинаются при загрузке проц. в 100% либо при проблемах с буфферами. Но судя по листингам на igb0 у Вас всё идеально. Ссылка на сообщение Поделиться на других сайтах
KaYot 3 710 Опубліковано: 2010-11-08 19:39:41 Share Опубліковано: 2010-11-08 19:39:41 Если потери только на внешний мир, а в локалку нет - сервер не виноват 100%. Ищите перегрузку внешнего канала или неверную конфигурацию шейперов. Ссылка на сообщение Поделиться на других сайтах
Kucher2 122 Опубліковано: 2010-11-08 19:51:14 Автор Share Опубліковано: 2010-11-08 19:51:14 Если потери только на внешний мир, а в локалку нет - сервер не виноват 100%. Ищите перегрузку внешнего канала или неверную конфигурацию шейперов. Тоже над этим думал. По поводу перегрузки канала. Канал 50Мбит, график привожу ниже. Инет сейчас заметно тупит, Speedtest показывает всего 3Мбит запаса, как ни странно. Может конечно count рисующий график и врёт, тем более что там масштаб в 24 часа... Изменил масштаб, второй график рисуется в масштабе 1 час - не похоже на перегруз канала и сопоставление с ifstat это подтверждает, там запас 10-15Мбит. На счёт шейпера не понял. Что значит неверная конфигурация? Вот такой у меня шейп. Ссылка на сообщение Поделиться на других сайтах
KaYot 3 710 Опубліковано: 2010-11-08 20:09:04 Share Опубліковано: 2010-11-08 20:09:04 К сожалению в bsd я ни в зуб ногой) Мониторьте загрузку внешнего канала, смотрите при каком значении начинаются чудеса. Может проблемы вообще не у вас, а у аплинка? Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВхід
Уже зарегистрированы? Войдите здесь.
Войти сейчас