> From: Vladimir Yesakov <Vladimir.Yesakov@p202.f58.n461.z2.fidonet.org> > Date: Thu, 19 Mar 2015 19:37:47 +0300 > > VY> Я заранее прошу прощения, длинновато получилось... > > Дошли у меня наконец-то руки закончить с этим сервером... > > VY>>> В идеале хотелось бы получить полные 10G с сервера... ( карточка > VY>>> на 2 порта, в один принимаем l2tp, а в другом Internet ) > EG>> Это может быть нетривиально, но пробуй. > > Кому лень читать все, то сразу выводы: > >1) Фря 9.3 некорректно работает с двумя процессорами. Вынимание одного никак не >влияет на общую производительность системы при данном конкретном виде нагрузки. >Возможно, что на этой контретной маме (SuperMicro X9DRT). 10.0 у меня на такой >же задаче вешалась при 1k сессий (примерно), а 10.1 я не пробовал.
Как и говорилось с самого начала. DDR память - штука медленная.
>2) Похоже если взять _один_ процессор, но побыстрее и с большим числом ядер, то >до 10GB добратся будет можно. Процессор, правда под 2 килобакса, встанет, но
Чтобы добраться до 10 GB, достаточно одноядерного процессора о девятистах мегагерцах (см. статью Луиджи про netmap). Так что более быстрый процессор тебе вряд ли поможет, память-то останется та же самая. Hадо прежде всего алгоритмы оптимизировать, в направлении уменьшения числа копирований данных из памяти в память. Т.е. обрабатывать пакеты прямо в том буфере, куда их сетевая карта складывает. Как это сделано в том же нетмапе, в bpf с опцией BPF_BUFMODE_ZEROCOPY и т.д.
Как я понимаю, у тебя ведь просто роутер, то есть полтора килобайта тела пакета перелопачивать не надо, достаточно поправить несколько полей в заголовках и отправить пакет дальше, так? В этом случае от zero copy как раз больше всего толка.
>Cisco с 10G интерфейсами (подержанная) все равно тянет на $15k.
Да ещё и не факт, что циска потянет нагрузку без проблем.
>Теперь детали. > > VY> PPS взяты с "netstat -i 1" > >Текущие данные (до пика еще 2 часа...) >=== Cut === > input (Total) output > packets errs idrops bytes packets errs bytes colls > 859206 0 0 515649102 1085071 7 1214621518 0 > 947910 0 0 581993230 1216279 4 1321367893 0 > 953823 0 0 581299125 1222578 6 1387690664 0 > 925894 0 0 566564259 1184950 7 1354310104 0 > 877375 0 0 527778823 1109854 7 1271385911 0 > 924253 0 0 549384743 1166242 7 1287634128 0 > 939129 0 0 564925817 1196570 6 1330810876 0 > 953851 0 0 569204225 1212750 3 1351247171 0 > 949041 0 0 568973122 1212448 9 1367340259 0 >=== Cut === > >Похоже Фря не может эффективно использовать 2 CPU Sockets. Я вынул один >процессор и включил HT (чтоб прибивку к ядрам не править, вдруг пришлось бы >срочно откатывать на 2 CPU). Картина сильно изменилась по PMCSTAT и практически >без изменений по TOP -SHIP:
Теперь убери пиннинг и выключи гипертрединг. Производительность при этом не ухудшится, каналы-то останутся теми же самыми, а вот проценты полегчают.
>Как мы видим - "sched_idletd" исчез совсем. Больше никто никого не ждет, >похоже...
Гипертрединг - это аппаратное ожидание, оно в твоей статистике не показывается.
>Один вопрос пока остается. >Как я понимаю дополнительной фрагментации быть не должно. Все виртуальные >интерфейсы настроены с MTU 1492, а на другой стороне MTU 1500, без VLAN или >какого-либо тунелирования.
Ежели в обратную сторону пойдёт 1500-байтный пакет - то его таки придётся либо фрагментировать, либо дропать и слать соответствующий icmp в надежде, что у отправителя pmtud сработает.
Вал. Дав.
--- ifmail v.2.15dev5.4 * Origin: Demos online service (2:5020/400)
