Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.

	Введите FGHI ссылку: Присутствуют сообщения из эхоконференции RU.UNIX.BSD с датами от 18 Jan 11 22:51:00 до 16 Sep 24 17:28:15, всего сообщений: 10763 Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение = Сообщение: 2578 из 10763 ===================================== RU.UNIX.BSD = От   : Vladimir Yesakov                 2:461/58.202       03 Mar 15 20:28:48 Кому : Eugene Grosbein                                     03 Mar 15 20:28:48 Тема : L2TP termination / mpd5 / CPU usage FGHI : area://RU.UNIX.BSD?msgid=2:461/58.202+54f65fd1 На   : area://RU.UNIX.BSD?msgid=grosbein.net+dcc50a2b = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.UNIX.BSD?msgid=grosbein.net+25df1f26 Ответ: area://RU.UNIX.BSD?msgid=2:461/58.202+550b64fe ============================================================================== * Replying to a msg in CARBON.AREA (CARBON.AREA)    Hello Eugene!     Я заранее прошу прощения, длинновато получилось... 03 Mar 15 15:05, you wrote to me: VY>> По спецификации эта карточка может 128 очередей, вроде... (линк VY>> разошелся на 2 строки) VY>> http://www.intel.com/content/www/us/en/ethernet-controllers/ VY>> 82599-10-gbe-controller-datasheet.html EG> Тут важны очереди на прием.     ну, 12 очередей на порт включилось... VY>> можно ли 2 порта карточки по 6(12) очередей прибить каждый к своему VY>> CPU ? EG> Можно; и драйвер, afaik, делает это по умолчанию.     Оказалось, что нет. Сделал 6 очередей, получил нагрузку на первые шесть ядер. Обе карты прицепились к CPU 0-5. Разобрался как прибить руками через setcpu, прибил ix0 к CPU 0-5 и ix1 к 6-11. Получилось вроде красиво. VY>> 2) lro - стоит включить/выключить ? интернет очень противоречив на VY>> эту тему. EG> Эта опция не для роутеров, а для контент-серверов, для TCP. EG> Роутер почти весь трафик обрабатывает уровнем ниже.     Уровнем ниже чего? TCP ? Это да. Или "large" там подразумевает несколько пакетов относящихся к одному TCP соединению сразу в socket? Я не нашел такой информации.     Однако принять-то пакет все равно надо. И я прочитал, что с этой опцией карта сама кладет принятый пакет в буфер, без использования CPU.     И еще на этом сервере L2TP (mpd5) терминация. Короче с этим непонятно... Сколько людей - столько мнений... VY>> 3) net.isr.dispatch, net.isr.numthreads и net.isr.bindthreads - VY>> как лучше ? Сейчас поставил direct,12 и 1 (без HT) EG> Так и оставь. VY>> В идеале хотелось бы получить полные 10G с сервера... ( карточка VY>> на 2 порта, в один принимаем l2tp, а в другом Internet ) EG> Это может быть нетривиально, но пробуй.     PPS взяты с "netstat -i 1"     Пока вижу следующее: CPU 81%, 2700 tunnels, 3.7Gbps, 1.3M pps IN, 1.4M pps OUT, ядра загружены более-менее равномерно, потерь нет. > HO !!!     CPU загружен 40% system, 40% interrupt и pmcstat показывает такую вот фигню: PMC: [INSTR_RETIRED_ANY] Samples: 123604 (100.0%) , 1069 unresolved %SAMP IMAGE      FUNCTION             CALLERS  11.9 kernel     sched_idletd         fork_exit   5.1 kernel     _rw_rlock            rtalloc1_fib:1.8 ng_address_hook:1.7   5.1 kernel     _mtx_lock_sleep      _mtx_lock_flags   4.3 kernel     _mtx_lock_spin       wakeup_one:1.9 turnstile_trywait:0.9 pmclog_reserve:0.8 _sleep:0.6   4.1 kernel     select_check_badfd   kern_select   2.4 kernel     _rw_runlock          ng_address_hook:0.9 arpresolve:0.5   2.3 kernel     rn_match             rtalloc1_fib   2.3 kernel     cpu_search_lowest    cpu_search_lowest:1.4 sched_pickcpu:0.9   2.1 pmcstat    _init   2.0 kernel     in_pcblookup_hash_lo in_pcblookup_hash > Соседний сервер, где один физический CPU, такая же карточка и нету L2TP, > но есть немножко PF правил.     CPU 1% system, 27% interrupt, 3Gbps, 0.5M pps IN, 0.5M pps OUT, ядра загружены более-менее равномерно, потерь нет. PMC: [INSTR_RETIRED_ANY] Samples: 85109 (100.0%) , 4803 unresolved %SAMP IMAGE      FUNCTION             CALLERS   7.0 kernel     bcmp                 ng_apply_item   6.4 pf.ko      pf_test_rule         pf_test   6.2 kernel     cpu_search_highest   cpu_search_highest:5.0 sched_idletd:1.1   3.6 pf.ko      pf_test              pf_check_in:2.0 pf_check_out:1.7   2.9 kernel     bzero                pf_test:0.6 ng_package_data:0.5   2.6 kernel     __rw_rlock           pf_test:0.8 in_lltable_lookup:0.6   2.5 kernel     __mtx_unlock_flags   ng_address_hook:0.8 pf_find_state:0.6 ixgbe_rxeof:0.5   2.4 libc.so.7  bsearch   2.4 kernel     _rw_runlock_cookie   pf_test:0.8 arpresolve:0.8 in_localip:0.5   2.4 kernel     jenkins_hash32       pf_find_state   2.2 kernel     cpu_search_lowest    cpu_search_lowest   2.1 kernel     uma_zalloc_arg       ng_package_data:1.0 m_dup:0.6   2.1 kernel     __mtx_lock_flags     ng_address_hook:1.0 pf_find_state:0.6   2.0 kernel     ip_fastforward       ether_demux Я не могу понять 2 вещи: трафика примерно одинаково, а PPS в три раза отличается; CPU system - на одном ~0%, на другом половина от общей загрузки, да еще и в "sched_idletd" - в ожидании грубо говоря. Я уже подумываю, а не выдернуть ли один CPU и посмотреть что будет? Vladimir --- GoldED+/W32-MSVC 1.1.5-b20130111 * Origin: Living in interesting times (2:461/58.202) К главной странице гейта

Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.071309 секунды