Перейти к содержимому
Калькуляторы

теорию без практики подзабывать начал. L1 разве не кэш инструкций ?

 

irqbalance и HT конечно отключены.

попробую обойти 2 ядро прерываниями сетевух. если это может - замечательно. только вот как бы это потом на автомате делать после ребута. бывало что эти же самые спецэффекты были на нулевом ядре.

 

L1 разделен на 2 части: кеш инструкций и кеш данных.

 

Честно говоря я не думаю, что поможет, поэтому переживать как сделать чтобы всё было после ребута я бы не стал. Это просто подтвердит ( или опровергнет ) теорию о том, что ipt_NETFLOW моет кеш.

 

В любом случае надо общаться с автором. Начиная с одного ядра это всё выглядит странно. Но я не эксперт по ipt_NETFLOW, увы. У меня он работает без нареканий и с меньшей нагрузкой на ядра. Правда у меня обычно 1-2 правила. Можете как вариант попробовать сделать агрегированное правило вместо ваших 8.

 

И еще: сколько примерно соединений активно одновременно ( ну или за 1-5 минут, без аггрегации ) и какой pps? Может у вас трафик не большой, но куча пакетов и соединений. Если не агрегировать, получается куча результатов, о которых NETFLOW радостно вещает.

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

поставил v2.0-38-g54c3227. тоже самое.

 

# grep Hash /proc/net/stat/ipt_netflow
Hash: size 800000 (mem 6250K), metric 1.04 [1.02, 1.00, 1.00]. InHash: 21648276 pkt, 14981741 K, InPDU 137, 85860.

 

А у Вас?

 

p.s. настройки hash по default (8192 buckets) не предназначены для highload

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И еще: сколько примерно соединений активно одновременно ( ну или за 1-5 минут, без аггрегации ) и какой pps? Может у вас трафик не большой, но куча пакетов и соединений. Если не агрегировать, получается куча результатов, о которых NETFLOW радостно вещает.

Flows: active 218680 (peak 611012 reached 1d18h44m ago)

pps максимум что видел 1.6mpps

эксперимент по поводу обхода второго ядра решил отложить. сейчас нет постоянной нагрузки на 2 ядро. нагрузка периодически подскакивает рандомно на разных ядрах и буквально на 1-3 секунды после чего падает. поднимаю нагрузку. пока раскачал до 5gbit.

 

поставил v2.0-38-g54c3227. тоже самое.

 

# grep Hash /proc/net/stat/ipt_netflow
Hash: size 800000 (mem 6250K), metric 1.04 [1.02, 1.00, 1.00]. InHash: 21648276 pkt, 14981741 K, InPDU 137, 85860.

 

А у Вас?

 

p.s. настройки hash по default (8192 buckets) не предназначены для highload

странно. в sysctl.conf net.netflow.hashsize = 327680

а оно почему то не применилось. хотя возможно я просто потом руками модуль перезагружал и оно сбросилось.

поднял. посмотрим что будет вечером.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Одно из ядер приобретает сильную нагрузку.

 

Смотрите статистику /proc/net/stat/ipt_netflow по тому сколько трафика модуль видит на каждом ядре (первый столбец, pps). В строке "Flows:" в конце написано на каком проце висит экспортер (пример "[cpu1]").

Запустите утилиту irqtop (в дире с исходниками модуля) и проверьте, что прерывания идут равномерно по ядрам.

 

И вообще, покажите эту статистику (/proc/net/stat/ipt_netflow) во время нагрузки.

 

Я так понимаю они вымывают кэш процессора.

 

На каком основании вы так решили? Измеряли чем-то "вымывание кэша процессора"?

 

Освободил одно из ядер для этих задач.

Вопрос: как высадить эти процессы на отдельное свободное ядро ?

 

Дано - не понятно какие процессы грузят оно ядро, вопрос - как их высадить на одно ядро?

 

Видимо, сначала нужно выяснить какие процессы грузят ядро.

 

То что вы видите в "perf top", это не "процессы".

 

Если на одно из ядер приходит значительно больше трафика, то сделайте так, чтоб приходило равномерно (настройками RSS и RPS).

 

Может ipt_do_table хотя бы можно разпаралелить по ядрам ?

 

ipt_do_table это softirq NET_RX.

Изменено пользователем aabc

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Интересная ситуация тем, что ядерный модуль не размазывается по ядрам. Видимо написан не паралельным.

 

Он написан параллельным.

 

И aggregation - это костыль, вы же понимаете.

 

Кстати, в модуле есть и flow sampling.

 

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

 

Он агрегирует порты, как я понял, все соединения остаются.

 

Если новая версия не помогла, то надо либо связываться с автором, либо копать самому функцию. Ядро процессора, которое выполняет модуль ядра, на сколько я понимаю, выбирается во время добавления правил и загрузки соответствующего модуля. Навскид вариант без гугла, можно выгружать, загружать, модуль пока он не окажется у нужного kworker.

 

Модуль обрабатывает пакеты на том проце на котором ему их даёт ядро. Ядро распределяет пакеты равномерно про процам. Но это можно контролировать настройками драйвера сетевой карты, RSS, RPS.

 

Еще как вариант попробуйте убрать трафик с ядра, которому достался NETFLOW. Подтвердите теорию о вымывании кеша.

Думаю, "вымывание кеша" вообще не имеет отношения к делу.

 

А вот я что-то сомневаюсь, что правила файрвола будут проверяться не в контексте прерывания сетевухи...

 

Правильно сомневаетесь, правило обрабатывается в контексте прерывания, затем после отработки правила, зовется модуль ipt_NETFLOW ( контекст переключается на следующее прерывание или что там ). Сам модуль прибит гвоздями к kworker и само исполнение правила переходит уже физически на другое ядро.

 

Всё не так. Есть hardware irq, которые создает сетевая карта. В этом месте есть контроль опциями драйвера карты - сколько создавать rx очередей и настройками smp_affinity - на какие процы эти прерывания направлять. Hardware irq быстро обрабатывается, ставит пакет в очередь softirq, больше оно ничего не делает. Его нагрузку видно как "%irq" в "mpstat -P ALL", или "% hi" в "top". В этом месте есть контроль настройками rps_cpus на какие процы направлять пакеты, обычно, если настроен RSS, то RPS трогать не надо. В свободную минутку ядро решает обработать softirq - на каждом проце свой обработчик и своя очередь. Это не kworker, а контекст softirq. (Наблюдать нагрузку от softirq можно "% si" в 'top' или "%soft" в "mpstat -P ALL") Здесь пакет стоит в очереди случайного проца или согласно предыдущим настройкам. В softirq ядро начинает парсить пакет, роутить, обрабатывать iptables. В iptables, если было правило с -j NETFLOW, вызывается функция обработчика netflow без переключения контекстов, просто вызов функции.

 

Есть еще отсылка собранной статистики коллектору, она висит на одном из процов (случайном и может перескакивать по решению ядра). Её можно залочить на любой проц параметром модуля exportcpu= или после загрузки записать значение в /sys/module/ipt_NETFLOW/parameters/exportcpu. Но обычно она не так сильно грузит, чтоб что-то там менять.

Изменено пользователем aabc

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Значит дело было в маленьком значении хэш таблицы? Это было бы сразу ясно если бы вы посмотрели/запостили статистику.

 

странно. в sysctl.conf net.netflow.hashsize = 327680

а оно почему то не применилось. хотя возможно я просто потом руками модуль перезагружал и оно сбросилось.

поднял. посмотрим что будет вечером.

 

Например, после ребута sysctl.conf применился до загрузки модуля. Поэтому лучше указывать опции к модулям через конфиги modprobe. А sysctl.conf применять только для общих настроек ядра, а не модулей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Он агрегирует порты, как я понял, все соединения остаются.

 

Я другого и не говорил. src-dst-port-time - это и есть соединение. В данной ситуации аггрегация будет по времени. То есть если у меня за период аггрегации будет 2 соединения с одним и тем же src-dst например на порт 22, то у меня будет 1 строка во флов. Без агрегации - 2.

 

Поправьте если я не прав.

 

Он написан параллельным.

 

У меня такое же наблюдение, но автор говорит о том, что пакеты размазываются, а вот генерация флов - нет. Кстати, а модуль ipt_NETFLOW самособранный? Может он как-то криво собран?

 

Всё не так. Есть hardware irq, которые создает сетевая карта. В этом месте есть контроль опциями драйвера карты - сколько создавать rx очередей и настройками smp_affinity - на какие процы эти прерывания направлять. Hardware irq быстро обрабатывается, ставит пакет в очередь softirq, больше оно ничего не делает. Его нагрузку видно как "%irq" в "mpstat -P ALL", или "% hi" в "top". В этом месте есть контроль настройками rps_cpus на какие процы направлять пакеты, обычно, если настроен RRS, то RPS трогать не надо. В свободную минутку ядро решает обработать softirq - на каждом проце свой обработчик и своя очередь. Это не kworker, а контекст softirq. (Наблюдать нагрузку от softirq можно "% si" в 'top' или "%soft" в "mpstat -P ALL") Здесь пакет стоит в очереди случайного проца или согласно предыдущим настройкам. В softirq ядро начинает парсить пакет, роутить, обрабатывать iptables. В iptables, если было правило с -j NETFLOW, вызывается функция обработчика netflow без переключения контекстов, просто вызов функции.

 

Как же тогда получается, что пакеты обрабатываются на всех ядрах, а ipt_NETFLOW всё на одном? По вашей логике всё должно размазаться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поправьте если я не прав.

 

Подтверждаю что правы.

 

Как же тогда получается, что пакеты обрабатываются на всех ядрах, а ipt_NETFLOW всё на одном?

 

ipt_NETFLOW на всех ядрах.

 

Есть две основные функции - учёт потоков (что называется metering process) и экспорт статистики (exporting process) коллектору, это исходящий netflow/ipfix трафик. Первая - на всех процах (при этом ядро само решает на какие процы пойдут пакеты), вторая - на одном. Экспортер на одном, так как этого достаточно и на многих ему быть нет смысла (так как нет параллельного экспорта, хэш таблица со статистикой - одна). Можно перескакивать каждый раз на новый проц - но это ничего не даст в плане производительности, только скроет нагрузку.

 

То что у человека грузится один проц - 1) не факт что это от экспортера и скорей всего нет, 2) даже если нагрузка на том-же проце где и экспортер - не факт что от экспортера и скорей всего нет. Экспортер грузит мало. В среднем, 25 входящих пакетов создают один flow (вот уже снижение нагрузки на выходе в 25 раз), в одном netflow пакете на экспорт около 30 потоков (вот еще в 30 раз снижение нагрузки). То есть отсылка пакетов создает нагрузку около 750 раз меньшую чем нагрузка от входящего трафика.

Изменено пользователем aabc

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо за детальное объяснение работы ipt_NETFLOW. А как тогда из профайлера понять что такое ipt_NETFLOW? Получается, что никто кроме экспортера это быть не может?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо за детальное объяснение работы ipt_NETFLOW. А как тогда из профайлера понять что такое ipt_NETFLOW? Получается, что никто кроме экспортера это быть не может?

 

Конечно может. Большая нагрузка на машине где запущен ipt_NETFLOW вовсе не обязательно от ipt_NETFLOW.

 

Если net.netflow.hashsize слишком маленький (а значение по умолчанию маленькое и не рассчитано на большую нагрузку) то будет грузить 'metering process', в perf top он будет виден как netflow_target. А 'exporting' как netflow_scan_and_export.

 

Если видите какой-нибудь alloc_iova + rb_prev, то это глюк IOMMU, отключайте его или поставьте новое ядро.

 

Если много пакетов на одном проце - попробуйте регулировать средствами RSS. Не включайте RPS вместе с RSS.

 

В общем может быть сто причин.

Изменено пользователем aabc

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Просто выше по треду автор говорит, что в профайлере именно ipt_NETFLOW портит кайф.

 

Насчет RRS/RPS уже вижу вы не в первый раз пишите об этих механизмах, которые по умолчанию отключены. Не вижу ниодной причины их включать, если стоит нормальная сетевая ( а мы же в теме про софт роутеры ), которая имеет много очередей. Я не прав?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Просто выше по треду автор говорит, что в профайлере именно ipt_NETFLOW портит кайф.

 

Так как линукс система сложная, вполне легко неправильно установить источник проблемы.

 

Плюс, вроде бы выяснилось, что у него было низкое значение net.netflow.hashsize, так как настройки из sysctl.conf не установилось. Новых результатов, после исправления этой ошибки он ещё не сообщил.

 

Насчет RRS/RPS уже вижу вы не в первый раз пишите об этих механизмах, которые по умолчанию отключены. Не вижу ниодной причины их включать, если стоит нормальная сетевая ( а мы же в теме про софт роутеры ), которая имеет много очередей. Я не прав?

 

Я не предлагаю их использовать, я лишь говорю что они контролируют нагрузку пакетами на процы. Если у вас есть дисбаланс нагрузки (скажем на одном проце в 10-100 раз больше трафика), то можно воспользоваться RSS, чтоб размазать трафик равномерно по процам. На сколько я понимаю, новые драйвера сами настраивают RSS по умолчанию. Это видно если посмотреть irqtop.

Изменено пользователем aabc

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мы случайно не путаем RRS ( ??? ) и RSS ( Receive side scaling ), т.к. второй нужен обязательно и всё как вы говорите, а что такое первый я найти не могу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мы случайно не путаем RRS ( ??? ) и RSS ( Receive side scaling ), т.к. второй нужен обязательно и всё как вы говорите, а что такое первый я найти не могу.

Да RSS я имел ввиду. Поправлю свои посты. Спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

вообщем теперь картина такая:

 

ipt_NETFLOW v2.0-38-g54c3227, srcversion 2D9D2E1F19E951BD1E36FD7; aggr llist
Protocol version 5 (netflow)
Timeouts: active 1800s, inactive 15s. Maxflows 2000000
Flows: active 506633 (peak 629918 reached 0d22h26m ago), mem 77495K, worker delay 1/250 [1..25] (0 ms, 0 us, 352:0 0 [cpu0]).
Hash: size 800000 (mem 6250K), metric 1.51 [1.50, 1.18, 0.53]. InHash: 387235936 pkt, 308018407 K, InPDU 42, 4370.
Rate: 5428845418 bits/sec, 843379 packets/sec; Avg 1 min: 5455167067 bps, 846323 pps; 5 min: 5370635896 bps, 835048 pps
cpu#     pps; <search found new [metric], trunc frag alloc maxflows>, traffic: <pkt, bytes>, drop: <pkt, bytes>
Total 843376; 5380167913351 273517684728 9284260499 [1560.44],    0    0    0    0, traffic: 282801945227, 215325245 MB, drop: 0, 0 K
cpu0       0;      0      0      0 [1.00],    0    0    0    0, traffic: 0, 0 MB, drop: 0, 0 K
cpu1   96604; 587841216125 30008463123 1015699971 [1.49],    0    0    0    0, traffic: 31024163094, 23416140 MB, drop: 0, 0 K
cpu2   85199; 585970499794 29848668569 1015470655 [1.53],    0    0    0    0, traffic: 30864139224, 23608223 MB, drop: 0, 0 K
cpu3   87528; 591770187481 29989603720 1016108203 [1.48],    0    0    0    0, traffic: 31005711923, 23569537 MB, drop: 0, 0 K
cpu4   86224; 586031363593 29651185174 1015642784 [1.52],    0    0    0    0, traffic: 30666827958, 23223060 MB, drop: 0, 0 K
cpu5   97806; 585107051867 29621936067 1015719804 [1.48],    0    0    0    0, traffic: 30637655871, 23378563 MB, drop: 0, 0 K
cpu6   89432; 586299031406 29784012474 1015647323 [1.50],    0    0    0    0, traffic: 30799659797, 23445886 MB, drop: 0, 0 K
cpu7   96904; 581832408673 29873359107 1015340858 [1.49],    0    0    0    0, traffic: 30888699965, 23711121 MB, drop: 0, 0 K
cpu8  100359; 639396671221 32319288741 1086884706 [1.50],    0    0    0    0, traffic: 33406173447, 25613678 MB, drop: 0, 0 K
cpu9  103320; 635919483198 32421167763 1087746195 [1.49],    0    0    0    0, traffic: 33508913958, 25359032 MB, drop: 0, 0 K
Export: Rate 1329312 bytes/s; Total 309458462 pkts, 432059 MB, 9283753856 flows; Errors 0 pkts; Traffic lost 0 pkts, 0 Kbytes, 0 flows.
sock0: 10.10.4.111:9000, sndbuf 212992, filled 1, peak 92161; err: sndbuf reached 0, connect 0, cberr 0, other 0
aggr#0 port: ports 1024-65535 replace 0 (usage 1086409121)

 

вроде всё красиво. раньше netflow ложился на второе ядро. подозреваю что сперва модуль загрузился а позже запустился скрипт который по ядрам прерывания раскидал. после этого я модуль руками перезагружал. тогда то netflow и разделился по ядрам. сталобыть к ipt_netflow притензий нет.

 

теперь другая проблема. quagga сильно проц жрёт временами. на машине поднят bgp. маршрутов несколько сотен. а вот интерфейсов ~9k и постоянно добавляются и убавляются. процесс zebra ругается

 

2014/11/19 19:07:07 ZEBRA: SLOW THREAD: task work_queue_run (7f78b19862c7) ran for 6294ms (cpu time 5840ms)

 

подозреваю что это из за большого количества интерфейсов. зачем zebra их сканит ? чтоб конфиг добавить ? а можно это както отключить ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

раньше netflow ложился на второе ядро. подозреваю что сперва модуль загрузился а позже запустился скрипт который по ядрам прерывания раскидал. после этого я модуль руками перезагружал. тогда то netflow и разделился по ядрам.

 

Раскидывание по ядрам и модуль никак не свазаны, поэтому порядок этих событий не важен. Вы можете еще увеличить hashsize, чтоб [metric] (эффективность работы хэша) приблизилась к единице, что ещё снизит нагрузку на проц. Скажем, у вас пик потоков 629918, сделайте hashsize=1200000.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

раньше netflow ложился на второе ядро. подозреваю что сперва модуль загрузился а позже запустился скрипт который по ядрам прерывания раскидал. после этого я модуль руками перезагружал. тогда то netflow и разделился по ядрам.

 

Раскидывание по ядрам и модуль никак не свазаны, поэтому порядок этих событий не важен. Вы можете еще увеличить hashsize, чтоб [metric] (эффективность работы хэша) приблизилась к единице, что ещё снизит нагрузку на проц. Скажем, у вас пик потоков 629918, сделайте hashsize=1200000.

 

возможно я гдето протупил. но после обновления я видел netflow только на 2 ядре, о чём здесь и написал. дальше перезагрузка модуля с опциями по агрегации решила проблему. тогда я ещё мог ребутить сервер. сейчас мне уже сложно это делать. hashsize увеличил. нагрузки от netflow не вижу. тем временем трафик дорос до 7gbit.

 

 

p.s большое всем спасибо за помощь. многое понял. остался только впорос по зебре с её сканированием интерфейсов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

p.s большое всем спасибо за помощь. многое понял. остался только впорос по зебре с её сканированием интерфейсов.

А не пробовали смотреть на альтернативы? На ту же bird? На ~2k интерфейсов процесс даже не в первой десятке top'а. Квагга, кстати, до недавнего времени не умела назначать netxhop для iBGP. Из-за чего пришлось осваивать bird.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

прощу помощи, не могу понять почему в perf top такая нагрузка

Samples: 203K of event 'cycles', Event count (approx.): 115459632603
95,93%  [kernel]                  [k] cpu_startup_entry
 0,19%  [kernel]                  [k] _raw_spin_lock
 0,13%  [kernel]                  [k] igb_poll
 0,12%  [kernel]                  [k] ipt_do_table
 0,12%  [kernel]                  [k] igb_clean_rx_irq
 0,11%  [kernel]                  [k] htb_dequeue
 0,10%  [kernel]                  [k] fib_table_lookup
 0,08%  [kernel]                  [k] __hrtimer_start_range_ns
 0,08%  [kernel]                  [k] hash_net4_test
 0,08%  [kernel]                  [k] irq_entries_start
 0,08%  [kernel]                  [k] u32_classify
 0,07%  [kernel]                  [k] sfq_enqueue
 0,07%  [kernel]                  [k] ____nf_conntrack_find
 0,06%  [kernel]                  [k] igb_xmit_frame_ring
 0,06%  [kernel]                  [k] add_interrupt_randomness
 0,06%  [kernel]                  [k] nf_iterate
 0,05%  [kernel]                  [k] native_read_tsc
 0,05%  [kernel]                  [k] _raw_spin_unlock_irqrestore
 0,05%  [kernel]                  [k] ip_set_test
 0,05%  [kernel]                  [k] irq_exit
 0,04%  [kernel]                  [k] __netif_receive_skb_core
 0,04%  perf                      [.] 0x0000000000065d54
 0,04%  [kernel]                  [k] get_nohz_timer_target
 0,04%  [kernel]                  [k] ip_route_input_noref
 0,03%  [kernel]                  [k] _raw_spin_lock_irqsave
 0,03%  [kernel]                  [k] htb_enqueue
 0,03%  [kernel]                  [k] __napi_complete
 0,03%  [kernel]                  [k] sfq_dequeue
 0,03%  [kernel]                  [k] __do_softirq
 0,03%  [kernel]                  [k] igb_msix_ring
 0,03%  [kernel]                  [k] find_busiest_group
 0,03%  [kernel]                  [k] nf_conntrack_in
 0,03%  [kernel]                  [k] ip_finish_output
 0,03%  [kernel]                  [k] dev_queue_xmit
 0,03%  [kernel]                  [k] sched_clock_cpu
 0,03%  [kernel]                  [k] _raw_spin_lock_bh
 0,03%  [kernel]                  [k] local_clock
 0,02%  [kernel]                  [k] ip_rcv
 0,02%  [kernel]                  [k] check_leaf.isra.7
 0,02%  [kernel]                  [k] ktime_get
 0,02%  [kernel]                  [k] find_next_bit
 0,02%  [kernel]                  [k] apic_timer_interrupt
 0,02%  [kernel]                  [k] native_sched_clock
 0,02%  [kernel]                  [k] htb_lookup_leaf
 0,02%  [kernel]                  [k] hrtimer_interrupt
 0,02%  [kernel]                  [k] tick_nohz_stop_sched_tick
 0,02%  [kernel]                  [k] skb_flow_dissect
 0,02%  [kernel]                  [k] tcp_in_window
 0,02%  [kernel]                  [k] dev_hard_start_xmit
 0,02%  [kernel]                  [k] local_bh_enable

 

Пытался искать инфу, cpu_startup_entry это похоже тиклес режим ядра, в документации редхата, есть рекомендации использовать nohz. В итоге в щагрухчик добавил:

intel_idle.max_cstate=0 processor.max_cstate=0 idle=poll pcie_aspm=off nohz_full=1-11

 

Причем такая же ситуация и на другом сервере в с ядром 3.10 но там стоит gentoo (используется routing, shaper, netflow), на centos 7 с которым пытаюсь разобратся используется bgp, nat и ipset (реестр запрещенных сайтов). Трафика не много 500Мбит, но 90% nat.

 

Смущает то, что вижу в perf top. нагрузка на процессор не большая

09:49:59     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
09:49:59     all    0,11    0,00    0,40    0,00    2,89    0,00    0,00    0,00    0,00   96,59
09:49:59       0    0,08    0,00    0,14    0,00    0,00    0,00    0,00    0,00    0,00   99,77
09:49:59       1    0,04    0,00    0,04    0,00    0,00    0,00    0,00    0,00    0,00   99,91
09:49:59       2    0,02    0,00    0,01    0,00    0,00    0,00    0,00    0,00    0,00   99,96
09:49:59       3    0,02    0,00    0,01    0,00    0,00    0,00    0,00    0,00    0,00   99,97
09:49:59       4    0,07    0,00    0,58    0,00    4,45    0,00    0,00    0,00    0,00   94,90
09:49:59       5    0,02    0,00    0,56    0,00    4,46    0,00    0,00    0,00    0,00   94,96
09:49:59       6    0,55    0,00    0,57    0,00    4,22    0,00    0,00    0,00    0,00   94,66
09:49:59       7    0,26    0,00    0,59    0,00    4,29    0,00    0,00    0,00    0,00   94,85
09:49:59       8    0,07    0,00    0,64    0,00    4,71    0,00    0,00    0,00    0,00   94,58
09:49:59       9    0,08    0,00    0,57    0,00    4,25    0,00    0,00    0,00    0,00   95,09
09:49:59      10    0,09    0,00    0,56    0,00    4,16    0,00    0,00    0,00    0,00   95,19
09:49:59      11    0,05    0,00    0,57    0,00    4,14    0,00    0,00    0,00    0,00   95,23

 

версия ядра:

3.10.0-123.9.3.el7.x86_64 #1 SMP Thu Nov 6 15:06:03 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

два 6 ядерных без гипертрейдинга

Intel(R) Xeon(R) CPU X5650  @ 2.67GHz

сетевые набортные две 82576

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

linx

 

Samples: 203K of event 'cycles', Event count (approx.): 115459632603
95,93%  [kernel]                  [k] cpu_startup_entry

09:49:59     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
09:49:59     all    0,11    0,00    0,40    0,00    2,89    0,00    0,00    0,00    0,00   96,59

 

Вы меряете cycles, которые не учитывают, что у вас процессор на 96.59% idle. Из всего времени когда процессор работал, cpu_startup_entry отнимало 95.93%. Так что у вас нагрузки нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Раскрытие показало это:

 
 8,11 │198:   pause
65,35 │       mov    -0x1fc8(%rdx),%rax
26,54 │       test   $0x8,%al

 

Все началось с этого, сервер с 82576 Quad CPU Q9505 @ 2.83GHz на gentoo (ядро 3.10) понятно дело не справлялся в perf top видел туже не приглядную картину cpu_startup_entry в топе (уменьшалось по мере других растущих процесов), но была большая нагрузка по si, оптимизировать уже далее было некуда - ipcad заменен на netflow, iptables добавлены цепочки, это уменьшило нагрузку на 50%, в итоге почти год продержалось. Подвернулся dell c1100, вот на нем собрал новый сервер (centos 7) и опять вижу туже не приглядную картину, но с si все в порядке, весь положенный трафик в ЧНН прожевывает. Хотелось бы все-таки понять что это, общее что увидел это ядро 3.10

Изменено пользователем linx

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

linx

Выяснять на сервере где нет нагрузки, почему на другом сервере нагрузка - не имеет смысла. "Раскрытие показало" - что-то не то оно показало, должен быть список функций следующего уровня (expand callchain), а не код на асме (как у annotate). Не забудьте про опцию -g, не надо делать "Annotate", надо раскрывать enter-ом строчки с "+" в начале строки.

Изменено пользователем aabc

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

aabc

так понимаю, можно не обращать внимание на cpu_startup_entry, на gentoo посметрел на старом ядре 2.6.39 этой штуки нет. спасибо, за разъяснения.

 

должно быть что-то типа этого:

7fff81002000 7fff8100210f g startup_64                                                                                                                                          ◆
7fff81002110 7fff810021af g secondary_startup_64                                                                                                                                ▒
7fff810021b0 7fff810021c4 g start_cpu0                                                                                                                                          ▒
7fff810021c5 7fff810021c7 l bad_address                                                                                                                                         ▒
7fff810021c8 7fff81002fff g _stext                                                                                                                                              ▒
7fff81003000 7fff8100301f g xen_hypercall_set_trap_table                                                                                                                        ▒
7fff81003020 7fff8100303f g xen_hypercall_mmu_update                                                                                                                            ▒
7fff81003040 7fff8100305f g xen_hypercall_set_gdt                                                                                                                               ▒
7fff81003060 7fff8100307f g xen_hypercall_stack_switch                                                                                                                          ▒
7fff81003080 7fff8100309f g xen_hypercall_set_callbacks                                                                                                                         ▒
7fff810030a0 7fff810030bf g xen_hypercall_fpu_taskswitch                                                                                                                        ▒
7fff810030c0 7fff810030df g xen_hypercall_sched_op_compat                                                                                                                       ▒
7fff810030e0 7fff810030ff g xen_hypercall_platform_op                                                                                                                           ▒
7fff81003100 7fff8100311f g xen_hypercall_set_debugreg                                                                                                                          ▒
7fff81003120 7fff8100313f g xen_hypercall_get_debugreg                                                                                                                          ▒
7fff81003140 7fff8100315f g xen_hypercall_update_descriptor                                                                                                                     ▒
7fff81003160 7fff8100317f g xen_hypercall_ni                                                                                                                                    ▒
7fff81003180 7fff8100319f g xen_hypercall_memory_op                                                                                                                             ▒
7fff810031a0 7fff810031bf g xen_hypercall_multicall                                                                                                                             ▒
7fff810031c0 7fff810031df g xen_hypercall_update_va_mapping                                                                                                                     ▒
7fff810031e0 7fff810031ff g xen_hypercall_set_timer_op                                                                                                                          ▒
7fff81003200 7fff8100321f g xen_hypercall_event_channel_op_compat                                                                                                               ▒
7fff81003220 7fff8100323f g xen_hypercall_xen_version                                                                                                                           ▒
7fff81003240 7fff8100325f g xen_hypercall_console_io                                                                                                                            ▒
7fff81003260 7fff8100327f g xen_hypercall_physdev_op_compat                                                                                                                     ▒
7fff81003280 7fff8100329f g xen_hypercall_grant_table_op                                                                                                                        ▒
7fff810032a0 7fff810032bf g xen_hypercall_vm_assist                                                                                                                             ▒
7fff810032c0 7fff810032df g xen_hypercall_update_va_mapping_otherdomain                                                                                                         ▒
7fff810032e0 7fff810032ff g xen_hypercall_iret                                                                                                                                  ▒
7fff81003300 7fff8100331f g xen_hypercall_vcpu_op                                                                                                                               ▒
7fff81003320 7fff8100333f g xen_hypercall_set_segment_base                                                                                                                      ▒
7fff81003340 7fff8100335f g xen_hypercall_mmuext_op                                                                                                                             ▒
7fff81003360 7fff8100337f g xen_hypercall_xsm_op                                                                                                                                ▒
7fff81003380 7fff8100339f g xen_hypercall_nmi_op                                                                                                                                ▒
7fff810033a0 7fff810033bf g xen_hypercall_sched_op                                                                                                                              ▒
7fff810033c0 7fff810033df g xen_hypercall_callback_op                                                                                                                           ▒
7fff810033e0 7fff810033ff g xen_hypercall_xenoprof_op                                                                                                                           ▒
7fff81003400 7fff8100341f g xen_hypercall_event_channel_op                                                                                                                      ▒
7fff81003420 7fff8100343f g xen_hypercall_physdev_op                                                                                                                            ▒
7fff81003440 7fff8100345f g xen_hypercall_hvm_op                                                                                                                                ▒
7fff81003460 7fff8100347f g xen_hypercall_sysctl                                                                                                                                ▒
7fff81003480 7fff8100349f g xen_hypercall_domctl                                                                                                                                ▒
7fff810034a0 7fff810034bf g xen_hypercall_kexec_op                                                                                                                              ▒
7fff810034c0 7fff810034df g xen_hypercall_tmem_op                                                                                                                               ▒
7fff810034e0 7fff8100361f g xen_hypercall_rsvr                                                                                                                                  ▒
7fff81003620 7fff8100363f g xen_hypercall_mca                                                                                                                                   ▒
7fff81003640 7fff8100365f g xen_hypercall_arch_1                                                                                                                                ▒
7fff81003660 7fff8100367f g xen_hypercall_arch_2                                                                                                                                ▒
7fff81003680 7fff8100369f g xen_hypercall_arch_3                                                                                                                                ▒
7fff810036a0 7fff810036bf g xen_hypercall_arch_4      

 

Непонятное всегда смущает, просто раньше были проблемы, счас нет, но тем не менее хотелось посмотреть что все в норме и запас есть. И как смотреть perf top не по cycles, в опциях ничего такого не заметил

Изменено пользователем linx

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А вообще имеет смысл ставить тиклесс ядро на роутер? Мне всегда казалось, что это фича для мобильного железа.

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

кто может подсказать

есть загруженая машинка, хочу заменить процессор

 

i5-650 2 ядра 4 потока 3.2 GHz

на

X3440 4 ядра 8 потоков 2.53 GHz

 

стоит ли игра свеч?

сервер молотит pptp сессии на accel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.