Dark_Angel Опубликовано 12 ноября, 2014 (изменено) · Жалоба теорию без практики подзабывать начал. L1 разве не кэш инструкций ? irqbalance и HT конечно отключены. попробую обойти 2 ядро прерываниями сетевух. если это может - замечательно. только вот как бы это потом на автомате делать после ребута. бывало что эти же самые спецэффекты были на нулевом ядре. L1 разделен на 2 части: кеш инструкций и кеш данных. Честно говоря я не думаю, что поможет, поэтому переживать как сделать чтобы всё было после ребута я бы не стал. Это просто подтвердит ( или опровергнет ) теорию о том, что ipt_NETFLOW моет кеш. В любом случае надо общаться с автором. Начиная с одного ядра это всё выглядит странно. Но я не эксперт по ipt_NETFLOW, увы. У меня он работает без нареканий и с меньшей нагрузкой на ядра. Правда у меня обычно 1-2 правила. Можете как вариант попробовать сделать агрегированное правило вместо ваших 8. И еще: сколько примерно соединений активно одновременно ( ну или за 1-5 минут, без аггрегации ) и какой pps? Может у вас трафик не большой, но куча пакетов и соединений. Если не агрегировать, получается куча результатов, о которых NETFLOW радостно вещает. Изменено 12 ноября, 2014 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
enots Опубликовано 16 ноября, 2014 · Жалоба поставил 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
emp Опубликовано 17 ноября, 2014 · Жалоба И еще: сколько примерно соединений активно одновременно ( ну или за 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 а оно почему то не применилось. хотя возможно я просто потом руками модуль перезагружал и оно сбросилось. поднял. посмотрим что будет вечером. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 17 ноября, 2014 (изменено) · Жалоба Одно из ядер приобретает сильную нагрузку. Смотрите статистику /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. Изменено 18 ноября, 2014 пользователем aabc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 17 ноября, 2014 (изменено) · Жалоба Интересная ситуация тем, что ядерный модуль не размазывается по ядрам. Видимо написан не паралельным. Он написан параллельным. И 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. Но обычно она не так сильно грузит, чтоб что-то там менять. Изменено 18 ноября, 2014 пользователем aabc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 17 ноября, 2014 · Жалоба Значит дело было в маленьком значении хэш таблицы? Это было бы сразу ясно если бы вы посмотрели/запостили статистику. странно. в sysctl.conf net.netflow.hashsize = 327680а оно почему то не применилось. хотя возможно я просто потом руками модуль перезагружал и оно сбросилось. поднял. посмотрим что будет вечером. Например, после ребута sysctl.conf применился до загрузки модуля. Поэтому лучше указывать опции к модулям через конфиги modprobe. А sysctl.conf применять только для общих настроек ядра, а не модулей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 18 ноября, 2014 · Жалоба Он агрегирует порты, как я понял, все соединения остаются. Я другого и не говорил. 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 всё на одном? По вашей логике всё должно размазаться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 18 ноября, 2014 (изменено) · Жалоба Поправьте если я не прав. Подтверждаю что правы. Как же тогда получается, что пакеты обрабатываются на всех ядрах, а ipt_NETFLOW всё на одном? ipt_NETFLOW на всех ядрах. Есть две основные функции - учёт потоков (что называется metering process) и экспорт статистики (exporting process) коллектору, это исходящий netflow/ipfix трафик. Первая - на всех процах (при этом ядро само решает на какие процы пойдут пакеты), вторая - на одном. Экспортер на одном, так как этого достаточно и на многих ему быть нет смысла (так как нет параллельного экспорта, хэш таблица со статистикой - одна). Можно перескакивать каждый раз на новый проц - но это ничего не даст в плане производительности, только скроет нагрузку. То что у человека грузится один проц - 1) не факт что это от экспортера и скорей всего нет, 2) даже если нагрузка на том-же проце где и экспортер - не факт что от экспортера и скорей всего нет. Экспортер грузит мало. В среднем, 25 входящих пакетов создают один flow (вот уже снижение нагрузки на выходе в 25 раз), в одном netflow пакете на экспорт около 30 потоков (вот еще в 30 раз снижение нагрузки). То есть отсылка пакетов создает нагрузку около 750 раз меньшую чем нагрузка от входящего трафика. Изменено 18 ноября, 2014 пользователем aabc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 18 ноября, 2014 · Жалоба Спасибо за детальное объяснение работы ipt_NETFLOW. А как тогда из профайлера понять что такое ipt_NETFLOW? Получается, что никто кроме экспортера это быть не может? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 18 ноября, 2014 (изменено) · Жалоба Спасибо за детальное объяснение работы 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. В общем может быть сто причин. Изменено 18 ноября, 2014 пользователем aabc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 18 ноября, 2014 · Жалоба Просто выше по треду автор говорит, что в профайлере именно ipt_NETFLOW портит кайф. Насчет RRS/RPS уже вижу вы не в первый раз пишите об этих механизмах, которые по умолчанию отключены. Не вижу ниодной причины их включать, если стоит нормальная сетевая ( а мы же в теме про софт роутеры ), которая имеет много очередей. Я не прав? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 18 ноября, 2014 (изменено) · Жалоба Просто выше по треду автор говорит, что в профайлере именно ipt_NETFLOW портит кайф. Так как линукс система сложная, вполне легко неправильно установить источник проблемы. Плюс, вроде бы выяснилось, что у него было низкое значение net.netflow.hashsize, так как настройки из sysctl.conf не установилось. Новых результатов, после исправления этой ошибки он ещё не сообщил. Насчет RRS/RPS уже вижу вы не в первый раз пишите об этих механизмах, которые по умолчанию отключены. Не вижу ниодной причины их включать, если стоит нормальная сетевая ( а мы же в теме про софт роутеры ), которая имеет много очередей. Я не прав? Я не предлагаю их использовать, я лишь говорю что они контролируют нагрузку пакетами на процы. Если у вас есть дисбаланс нагрузки (скажем на одном проце в 10-100 раз больше трафика), то можно воспользоваться RSS, чтоб размазать трафик равномерно по процам. На сколько я понимаю, новые драйвера сами настраивают RSS по умолчанию. Это видно если посмотреть irqtop. Изменено 18 ноября, 2014 пользователем aabc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 18 ноября, 2014 · Жалоба Мы случайно не путаем RRS ( ??? ) и RSS ( Receive side scaling ), т.к. второй нужен обязательно и всё как вы говорите, а что такое первый я найти не могу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 18 ноября, 2014 · Жалоба Мы случайно не путаем RRS ( ??? ) и RSS ( Receive side scaling ), т.к. второй нужен обязательно и всё как вы говорите, а что такое первый я найти не могу. Да RSS я имел ввиду. Поправлю свои посты. Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
emp Опубликовано 19 ноября, 2014 · Жалоба вообщем теперь картина такая: 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 их сканит ? чтоб конфиг добавить ? а можно это както отключить ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 19 ноября, 2014 · Жалоба раньше netflow ложился на второе ядро. подозреваю что сперва модуль загрузился а позже запустился скрипт который по ядрам прерывания раскидал. после этого я модуль руками перезагружал. тогда то netflow и разделился по ядрам. Раскидывание по ядрам и модуль никак не свазаны, поэтому порядок этих событий не важен. Вы можете еще увеличить hashsize, чтоб [metric] (эффективность работы хэша) приблизилась к единице, что ещё снизит нагрузку на проц. Скажем, у вас пик потоков 629918, сделайте hashsize=1200000. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
emp Опубликовано 19 ноября, 2014 · Жалоба раньше netflow ложился на второе ядро. подозреваю что сперва модуль загрузился а позже запустился скрипт который по ядрам прерывания раскидал. после этого я модуль руками перезагружал. тогда то netflow и разделился по ядрам. Раскидывание по ядрам и модуль никак не свазаны, поэтому порядок этих событий не важен. Вы можете еще увеличить hashsize, чтоб [metric] (эффективность работы хэша) приблизилась к единице, что ещё снизит нагрузку на проц. Скажем, у вас пик потоков 629918, сделайте hashsize=1200000. возможно я гдето протупил. но после обновления я видел netflow только на 2 ядре, о чём здесь и написал. дальше перезагрузка модуля с опциями по агрегации решила проблему. тогда я ещё мог ребутить сервер. сейчас мне уже сложно это делать. hashsize увеличил. нагрузки от netflow не вижу. тем временем трафик дорос до 7gbit. p.s большое всем спасибо за помощь. многое понял. остался только впорос по зебре с её сканированием интерфейсов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 20 ноября, 2014 · Жалоба p.s большое всем спасибо за помощь. многое понял. остался только впорос по зебре с её сканированием интерфейсов. А не пробовали смотреть на альтернативы? На ту же bird? На ~2k интерфейсов процесс даже не в первой десятке top'а. Квагга, кстати, до недавнего времени не умела назначать netxhop для iBGP. Из-за чего пришлось осваивать bird. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
linx Опубликовано 20 ноября, 2014 · Жалоба прощу помощи, не могу понять почему в 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 20 ноября, 2014 · Жалоба 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%. Так что у вас нагрузки нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
linx Опубликовано 20 ноября, 2014 (изменено) · Жалоба Раскрытие показало это: 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 Изменено 20 ноября, 2014 пользователем linx Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 20 ноября, 2014 (изменено) · Жалоба linx Выяснять на сервере где нет нагрузки, почему на другом сервере нагрузка - не имеет смысла. "Раскрытие показало" - что-то не то оно показало, должен быть список функций следующего уровня (expand callchain), а не код на асме (как у annotate). Не забудьте про опцию -g, не надо делать "Annotate", надо раскрывать enter-ом строчки с "+" в начале строки. Изменено 20 ноября, 2014 пользователем aabc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
linx Опубликовано 20 ноября, 2014 (изменено) · Жалоба 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, в опциях ничего такого не заметил Изменено 20 ноября, 2014 пользователем linx Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 20 ноября, 2014 (изменено) · Жалоба А вообще имеет смысл ставить тиклесс ядро на роутер? Мне всегда казалось, что это фича для мобильного железа. Изменено 20 ноября, 2014 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zulu_radist Опубликовано 30 декабря, 2014 · Жалоба кто может подсказать есть загруженая машинка, хочу заменить процессор i5-650 2 ядра 4 потока 3.2 GHz на X3440 4 ядра 8 потоков 2.53 GHz стоит ли игра свеч? сервер молотит pptp сессии на accel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...