Jugernault Опубликовано 27 апреля, 2010 · Жалоба Ну и дальше наверное только oprofile...а разве много нового после perf top покажет? Не много - но мало ли... Тут уже похоже метод зачистки пора применять и смотреть везде куда возможно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dbask Опубликовано 27 апреля, 2010 · Жалоба sysstat-9.1.1:mpstat -P ALL 2 Linux 2.6.33.2-zebra (zebra) 04/27/2010 _x86_64_ (8 CPU) 01:02:13 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 01:02:15 PM all 0.00 0.00 0.06 0.00 0.19 10.91 0.00 0.00 88.84 01:02:15 PM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 01:02:15 PM 1 0.00 0.00 0.00 0.00 0.00 21.29 0.00 0.00 78.71 01:02:15 PM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 01:02:15 PM 3 0.00 0.00 0.00 0.00 0.00 24.26 0.00 0.00 75.74 01:02:15 PM 4 0.00 0.00 0.50 0.00 0.00 0.00 0.00 0.00 99.50 01:02:15 PM 5 0.00 0.00 0.00 0.00 0.99 18.32 0.00 0.00 80.69 01:02:15 PM 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 01:02:15 PM 7 0.00 0.00 0.00 0.00 0.50 23.27 0.00 0.00 76.24 mpstat -I SUM -P ALL 2 01:09:33 PM CPU intr/s 01:09:35 PM all 25443.41 01:09:35 PM 0 26.83 01:09:35 PM 1 6174.63 01:09:35 PM 2 27.32 01:09:35 PM 3 6187.32 01:09:35 PM 4 26.83 01:09:35 PM 5 6140.49 01:09:35 PM 6 27.32 01:09:35 PM 7 6123.41 Насколько я понимаю, то достаточно пристойные показатели.Сколько в этот момент было трафика и пакетов в секунду? cat /proc/cpuinfo | grep -E "processor|physical id|apicid|core id" processor : 0 physical id : 0 core id : 0 apicid : 0 processor : 1 physical id : 0 core id : 2 apicid : 2 processor : 2 physical id : 1 core id : 0 apicid : 4 processor : 3 physical id : 1 core id : 2 apicid : 6 processor : 4 physical id : 0 core id : 1 apicid : 1 processor : 5 physical id : 0 core id : 3 apicid : 3 processor : 6 physical id : 1 core id : 1 apicid : 5 processor : 7 physical id : 1 core id : 3 apicid : 7 В вашем случае получается что работают 3 и 4 ядра обеих процессоров. p.s. cat /usr/src/linux-2.6.33.2 /.config | grep CONFIG_HZ cat /usr/src/linux-2.6.33.2 /.config | grep CONFIG_PREEMPT ? Ну и дальше наверное только oprofile... CONFIG_HZ=100 CONFIG_PREEMPT_NONE=y скорость на одном из интерфейсов: 5 minute input rate 534189000 bits/sec, 83227 packets/sec 5 minute output rate 411308000 bits/sec, 84504 packets/sec Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 27 апреля, 2010 (изменено) · Жалоба HZ = 100 ???? Кроме того, я считаю, что 24К прерываний на 8 очередей - это много. Я бы поставил бы по 1К на каждую очередь. Они ведь у Вас всеравно Rx-Tx. Изменено 27 апреля, 2010 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dbask Опубликовано 27 апреля, 2010 · Жалоба x CONFIG_HZ_100: x x 100 Hz is a typical choice for servers, SMP and NUMA systems x with lots of processors that may show reduced performance if x too many timer interrupts are occurring. с ITR поэкспериментируем, но неудобство в том что из за отсутствия полноценного генератора трафика, дергать сетевухи приходится только рано утром Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 27 апреля, 2010 · Жалоба Мне кажется, что Вы просто теряете тики ядра, из-за того, что у Вас тик длится больше чем нужно. Я первый раз вижу роутер с HZ=100. Нет, ну меня они тоже когда-то были с 100, когда ядро не позволяло это нормально менять. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 27 апреля, 2010 · Жалоба Мне кажется, что Вы просто теряете тики ядра, из-за того, что у Вас тик длится больше чем нужно. Я первый раз вижу роутер с HZ=100. Нет, ну меня они тоже когда-то были с 100, когда ядро не позволяло это нормально менять."Assigning Interrupts to Processor Cores using 82576 controller" - Не, я конечно понимаю что брошюрка старовата, но если честно, то не вижу почему бы ей не доверять в отношении данного параметра.Каким по Вашему должно быть значение HZ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lynx10 Опубликовано 27 апреля, 2010 · Жалоба у меня CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 а сколько должно быть кто то в курсе ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dbask Опубликовано 27 апреля, 2010 (изменено) · Жалоба после перераспределения smp_affinity в соответствии с /proc/cpuinfo а именно: /bin/echo 4 > /proc/irq/`cat /proc/interrupts | grep 'eth2-TxRx-0' | awk -F \: '{printf $1}'| tr -d ' '`/smp_affinity /bin/echo 4 > /proc/irq/`cat /proc/interrupts | grep 'eth2-TxRx-1' | awk -F \: '{printf $1}'| tr -d ' '`/smp_affinity /bin/echo 40 > /proc/irq/`cat /proc/interrupts | grep 'eth2-TxRx-2' | awk -F \: '{printf $1}'| tr -d ' '`/smp_affinity /bin/echo 40 > /proc/irq/`cat /proc/interrupts | grep 'eth2-TxRx-3' | awk -F \: '{printf $1}'| tr -d ' '`/smp_affinity /bin/echo 8 > /proc/irq/`cat /proc/interrupts | grep 'eth3-TxRx-0' | awk -F \: '{printf $1}'| tr -d ' '`/smp_affinity /bin/echo 8 > /proc/irq/`cat /proc/interrupts | grep 'eth3-TxRx-1' | awk -F \: '{printf $1}'| tr -d ' '`/smp_affinity /bin/echo 80 > /proc/irq/`cat /proc/interrupts | grep 'eth3-TxRx-2' | awk -F \: '{printf $1}'| tr -d ' '`/smp_affinity /bin/echo 80 > /proc/irq/`cat /proc/interrupts | grep 'eth3-TxRx-3' | awk -F \: '{printf $1}'| tr -d ' '`/smp_affinity perftop: -------------------------------------------------------------------------------------------------------------------------------------- PerfTop: 4128 irqs/sec kernel:99.2% [1000Hz cycles], (all, 8 CPUs) -------------------------------------------------------------------------------------------------------------------------------------- samples pcnt function DSO _______ _____ ___________________________ __________________________________________________________________ 5768.00 14.3% ip_route_input /lib/modules/2.6.33.2-zebra/build/vmlinux 4779.00 11.8% igb_poll /lib/modules/2.6.33.2-zebra/kernel/drivers/net/igb/igb.ko 2690.00 6.7% _raw_spin_lock /lib/modules/2.6.33.2-zebra/build/vmlinux 1806.00 4.5% ip_forward /lib/modules/2.6.33.2-zebra/build/vmlinux 1804.00 4.5% __slab_free /lib/modules/2.6.33.2-zebra/build/vmlinux 1537.00 3.8% skb_release_head_state /lib/modules/2.6.33.2-zebra/build/vmlinux 1476.00 3.7% __alloc_skb /lib/modules/2.6.33.2-zebra/build/vmlinux 1456.00 3.6% igb_xmit_frame_ring_adv /lib/modules/2.6.33.2-zebra/kernel/drivers/net/igb/igb.ko 945.00 2.3% kfree /lib/modules/2.6.33.2-zebra/build/vmlinux 912.00 2.3% eth_type_trans /lib/modules/2.6.33.2-zebra/build/vmlinux динамика загрузки цпу: 2010-04-27_21:17 0.0 0.0 40.3 55.2 0.0 0.0 45.8 50.2 2010-04-27_21:18 0.0 0.0 36.4 43.7 0.0 0.0 40.6 36.5 2010-04-27_21:19 0.0 0.0 39.1 50.9 0.0 0.0 36.7 41.7 2010-04-27_21:20 0.0 0.0 37.2 49.3 0.0 0.0 37.6 44.6 2010-04-27_21:21 0.0 0.0 40.5 43.1 0.0 0.0 38.0 42.5 2010-04-27_21:22 0.0 0.0 40.8 48.1 0.0 0.0 34.8 51.3 2010-04-27_21:23 0.0 0.0 63.9 68.5 0.0 0.0 43.6 55.0 2010-04-27_21:24 0.0 0.0 40.8 45.0 0.0 0.0 35.4 35.3 динамика дропов eth2: 2010-04-27_21:18 rx_queue_0_drops: 5910 rx_queue_1_drops: 1992 rx_queue_2_drops: 0955 rx_queue_3_drops: 0020 2010-04-27_21:19 rx_queue_0_drops: 5910 rx_queue_1_drops: 1992 rx_queue_2_drops: 0955 rx_queue_3_drops: 0020 2010-04-27_21:20 rx_queue_0_drops: 6163 rx_queue_1_drops: 2073 rx_queue_2_drops: 3361 rx_queue_3_drops: 1671 2010-04-27_21:21 rx_queue_0_drops: 7217 rx_queue_1_drops: 2623 rx_queue_2_drops: 3613 rx_queue_3_drops: 1671 2010-04-27_21:22 rx_queue_0_drops: 7217 rx_queue_1_drops: 2623 rx_queue_2_drops: 3613 rx_queue_3_drops: 1671 2010-04-27_21:23 rx_queue_0_drops: 7728 rx_queue_1_drops: 2623 rx_queue_2_drops: 6329 rx_queue_3_drops: 4136 2010-04-27_21:24 rx_queue_0_drops: 7640 rx_queue_1_drops: 2740 rx_queue_2_drops: 8935 rx_queue_3_drops: 5959 скорость на одном из физ интерфейсов: 5 minute input rate 654057000 bits/sec, 109452 packets/sec 5 minute output rate 667326000 bits/sec, 126387 packets/sec показатели не идеальные, но на порядок лучше вчерашних P.S. у кого какие мысли на счет того, на сколько полезен параметр для igb: LLIPort=80 (low latency interrupt port) ? Изменено 27 апреля, 2010 пользователем dbask Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 27 апреля, 2010 · Жалоба Поставьте HZ=1000. Если бы эксперементировал с частотой выше, мог бы порекомендовать еще что-то, но выше 1000 не ставил. У ребят c FreeBSD обсуждаемой в соседних топиках бывает и 2000, на сколько я видел. А вообще по поводу почему HZ надо ставить как можно больше - есть инфа в Инете. Поищите темы про роутинг 1 Гбита. Там ребята, когда только Гбит появился и у всех жестко в ядрах стояло HZ=100 не могли нормально разобраться, почему же Гбит не пролазит и начинаются дропы. В кратце это происходит так: например ядро должно 100 раз в секунду переключится на выполнение другой задачи. Задачи поступают блоками и в случае с трафиком - это пачка пакетов, например забраных прерываниями. Далее ядро начинает эти пакеты разгребать. Скажем, разгребать пакеты в данной задаче, текущему ядру - 0.005 сек. Это означает, что по завершению задачи, оно еще будет 0.005 сек колупаться в попе, после чего перейдет к другой задаче. В результате Вы получите свои softirq в топе и в тиках, но реально работа делаться не будет. Если же ядру сказать переключаться 1000 раз в секунду, а задачи например на 0.005 сек, то оно эту задачу выполнит за 5 подходов, после чего пакеты будут просто плавно догружаться в новую задачу для ядра и когда оно будет к ней возвращаться - для него будет всегда работа. То есть в данном случае тики будут, но и работа будет делаться. Смысл ставить HZ=100 я особо не вижу вообще никогда. Наверное это имеет смысл только если нужно обрабатывать большие массивы данных, например видео, когда задача есть всегда в достаточном объеме, чтобы загрузить современные ядра. Но вообще, для современных процессоров, с кучей ядер, 100 переключений в секунду - это ерунда. Накладные расходы при таком низком переключении намного выше засчет простоев в выполненой задаче. Это если на пальцах рассказывать. Отрицательный момент для высокого HZ только один: накладные расходы на переключение. Очевидно, чем чаще - тем больше. Вот умные дядьки пишущие ядро для линукса решили, что чаще 1000 раз переключаться не нужно будет никому и никогда и жестко прибили эту настройку. Уроды. А насчет LLIPort я Вам сказал еще в самом начале. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 27 апреля, 2010 · Жалоба CONFIG_NO_HZ=y но если используется NET_SCHED, желательно CONFIG_HZ_1000=y, т.к. где-то в коде осталась привязка Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 27 апреля, 2010 · Жалоба А вот NO_HZ - это, мне кажется, плохая идея, т.к. ядро в этом случае будет само выбирать как часто ему переключаться. Че-то я не верю в магию автоматики. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 27 апреля, 2010 · Жалоба Dark_Angel, я думаю что все далеко не так просто. http://thread.gmane.org/gmane.linux.kernel/831840 Там же высказана крамольная мысль следующего характера: I would think that 60 HZ would be sufficientВидимо scheduler опирается еще на какой-то таймер, потому что иначе это безумие предлагать 60 HZ. P.S.: В Ubuntu Server Edition HZ=100 (в desktop - 250). Лично я предпочитаю безопасное значение 250. Хотя есть сервера и с 1000. Дропов там не больше и не меньше чем на серверах, где HZ=250. DemYaN, NET_SCHED уже давно сконвертирован в hrtimers. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dbask Опубликовано 27 апреля, 2010 · Жалоба попробую с HZ=250, а что скажете насчет параметра ring buffer tx/rx: ethtool -G 1024 eth(x) (max 4096) ? есть ли подобранное оптимальное значение для гигабит роутинга? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 27 апреля, 2010 (изменено) · Жалоба А вот NO_HZ - это, мне кажется, плохая идея, т.к. ядро в этом случае будет само выбирать как часто ему переключаться. Че-то я не верю в магию автоматики.ну если шейпа нет, то фиксированное значение HZ и отказ от hrtimers может будет и лучше... но если шейп то hrtimers и соответственно NO_HZ DemYaN, NET_SCHED уже давно сконвертирован в hrtimers.оно то кончено да, но помнится были какие-то проблемы еще в 2.6.28....порылся и нашел: http://lists.openwall.net/netdev/2009/01/09/63 http://lists.openwall.net/netdev/2009/01/13/14 Изменено 27 апреля, 2010 пользователем DemYaN Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 27 апреля, 2010 · Жалоба попробую с HZ=250, а что скажете насчет параметра ring buffer tx/rx: ethtool -G 1024 eth(x) (max 4096) ? есть ли подобранное оптимальное значение для гигабит роутинга? Насколько я понимаю, то панацеи нет.Стоит следить за rx_no_buffer_count: 0 rx_missed_errors: 0 и если начинают сыпаться ошибки, то постепенно увеличивать кольцевой буфер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 27 апреля, 2010 · Жалоба DemYaN, там потом выяснилось, что у товарища оказался включен nmi_watchdog, который всегда вырубает hrtimers. В такой ситуации он конечно же зависел от HZ. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 27 апреля, 2010 · Жалоба 2Умник: прочитал всё обсуждение в присланном Вами линке. Там немного не наш случай. Они говорят о декстопах, говорят о сбережении енергии для idle. Потом проводят дибильные опыты, которые показывают, что HZ=100 и HZ=1000 генерирют разное количество прерываний timers. Божемой какая находка. То что сеть пытаются отвязать от HZ - да, попытки есть, но факт в том, что даже для функций ядра, а я уже не говорю про user-space, HZ влияет. Возможно даже сеть работает на hrtimers, но процессорное время, видимо, выделяется всеравно на основании переключений контекстов ядра. Влияет HZ по-разному. И в линке который Вы дали - только подтверждения моего объяснения. Дали задачу в форе прокрутится циклу, которому крутится 255s при HZ=100 и 264 при HZ=1000. Почему возникла разница - очевидно, я написал об этом. Почему лучше иметь ниже HZ - тоже очевидно. Только вот задача у нас другая. Я бы вообще с удовольствием ставил HZ=количеству решаемых задач на машине, но увы, так работать не будет, как Вы понимаете. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 27 апреля, 2010 · Жалоба nmi_watchdog, который всегда вырубает hrtimersоу, будем знать, ибо nmi_watchdog используется активно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 27 апреля, 2010 · Жалоба Dark_Angel, но мой опыт показывает, что HZ абсолютно не влияет на производительность forwarding-а и работоспособность NAPI: что 100, что 1000 - не важно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dbask Опубликовано 27 апреля, 2010 · Жалоба дождались, пошли дропы 2010-04-27_23:06 rx_queue_0_drops: 1339954 rx_queue_1_drops: 421509 rx_queue_2_drops: 7078168 rx_queue_3_drops: 373094 2010-04-27_23:07 rx_queue_0_drops: 1344670 rx_queue_1_drops: 426635 rx_queue_2_drops: 7083337 rx_queue_3_drops: 377748 2010-04-27_23:08 rx_queue_0_drops: 1348199 rx_queue_1_drops: 429243 rx_queue_2_drops: 7086293 rx_queue_3_drops: 382136 2010-04-27_23:09 rx_queue_0_drops: 1355417 rx_queue_1_drops: 434810 rx_queue_2_drops: 7095601 rx_queue_3_drops: 390017 2010-04-27_23:10 rx_queue_0_drops: 1365047 rx_queue_1_drops: 443653 rx_queue_2_drops: 7100754 rx_queue_3_drops: 396763 2010-04-27_23:11 rx_queue_0_drops: 1372977 rx_queue_1_drops: 451244 rx_queue_2_drops: 7109176 rx_queue_3_drops: 405901 2010-04-27_23:12 rx_queue_0_drops: 1380744 rx_queue_1_drops: 459095 rx_queue_2_drops: 7116157 rx_queue_3_drops: 419069 2010-04-27_23:13 rx_queue_0_drops: 1395332 rx_queue_1_drops: 468100 rx_queue_2_drops: 7126253 rx_queue_3_drops: 432735 2010-04-27_23:14 rx_queue_0_drops: 1404538 rx_queue_1_drops: 475213 rx_queue_2_drops: 7129817 rx_queue_3_drops: 437675 2010-04-27_23:15 rx_queue_0_drops: 1410845 rx_queue_1_drops: 480156 rx_queue_2_drops: 7135490 rx_queue_3_drops: 444030 2010-04-27_23:16 rx_queue_0_drops: 1426273 rx_queue_1_drops: 490986 rx_queue_2_drops: 7148307 rx_queue_3_drops: 455064 2010-04-27_23:17 rx_queue_0_drops: 1432640 rx_queue_1_drops: 497733 rx_queue_2_drops: 7155259 rx_queue_3_drops: 460590 скорость: 5 minute input rate 796667000 bits/sec, 134530 packets/sec 5 minute output rate 619538000 bits/sec, 136617 packets/sec ЦПУ: 2010-04-27_23:05 0.0 0.0 92.1 81.3 0.0 0.0 60.6 78.5 2010-04-27_23:06 0.0 0.0 60.7 71.6 0.0 0.0 77.9 78.9 2010-04-27_23:07 0.0 0.0 79.8 88.3 0.0 0.0 96.3 94.8 2010-04-27_23:08 0.0 0.0 96.8 93.6 0.0 0.0 96.0 96.0 2010-04-27_23:09 0.0 0.0 89.9 91.7 0.0 0.0 95.8 93.4 2010-04-27_23:10 0.0 0.0 96.6 91.1 0.0 0.0 95.8 97.0 2010-04-27_23:11 0.0 0.0 94.0 94.0 0.0 0.0 95.8 93.8 2010-04-27_23:12 0.0 0.0 94.8 95.0 0.0 0.0 95.2 91.9 2010-04-27_23:13 0.0 0.0 95.7 89.9 0.0 0.0 89.7 94.8 perf top: -------------------------------------------------------------------------------------------------------------------------------------- PerfTop: 4256 irqs/sec kernel:99.6% [1000Hz cycles], (all, 8 CPUs) -------------------------------------------------------------------------------------------------------------------------------------- samples pcnt function DSO _______ _____ ___________________________ __________________________________________________________________ 6081.00 16.4% ip_route_input /lib/modules/2.6.33.2-zebra/build/vmlinux 5393.00 14.5% igb_poll /lib/modules/2.6.33.2-zebra/kernel/drivers/net/igb/igb.ko 2394.00 6.4% _raw_spin_lock /lib/modules/2.6.33.2-zebra/build/vmlinux 2266.00 6.1% ip_forward /lib/modules/2.6.33.2-zebra/build/vmlinux 2235.00 6.0% __slab_free /lib/modules/2.6.33.2-zebra/build/vmlinux 1645.00 4.4% __alloc_skb /lib/modules/2.6.33.2-zebra/build/vmlinux 1618.00 4.4% igb_xmit_frame_ring_adv /lib/modules/2.6.33.2-zebra/kernel/drivers/net/igb/igb.ko 1401.00 3.8% skb_release_head_state /lib/modules/2.6.33.2-zebra/build/vmlinux 1117.00 3.0% eth_type_trans /lib/modules/2.6.33.2-zebra/build/vmlinux и что бросается в глаза: mpstat -I SUM -P ALL 2 Linux 2.6.33.2-zebra (zebra) 04/27/2010 _x86_64_ (8 CPU) 11:16:36 PM CPU intr/s 11:16:38 PM all 6366.19 11:16:38 PM 0 19.52 11:16:38 PM 1 19.52 11:16:38 PM 2 1093.33 11:16:38 PM 3 1399.52 11:16:38 PM 4 19.52 11:16:38 PM 5 19.52 11:16:38 PM 6 1939.05 11:16:38 PM 7 1141.43 11:16:38 PM CPU intr/s 11:16:40 PM all 4817.41 (при незагруженных процах всегда было ~24000) 11:16:40 PM 0 18.41 11:16:40 PM 1 18.41 11:16:40 PM 2 750.25 11:16:40 PM 3 880.60 11:16:40 PM 4 18.91 11:16:40 PM 5 18.91 11:16:40 PM 6 1460.70 11:16:40 PM 7 938.31 ^C Итак, будем уменьшать ITR Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 27 апреля, 2010 · Жалоба options igb IntMode=2,2,2,2 InterruptThrottleRate=3000,3000,3000,3000 RSS=4,4,4,4 QueuePairs=1,1,1,1 LLIPort=80Я бы посоветовал вообще убрать IntMode, InterruptThrottleRate, LLIPort и доверится драйверу. Еще RSS=4,4,4,4 превратить в RSS=0,0,0,0 - драйвер сам разберется с количеством очередей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 27 апреля, 2010 · Жалоба options igb IntMode=2,2,2,2 InterruptThrottleRate=3000,3000,3000,3000 RSS=4,4,4,4 QueuePairs=1,1,1,1 LLIPort=80При таких опциях ethtool -c eth2 что показывает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 27 апреля, 2010 (изменено) · Жалоба 2Умник: У меня просто опыт подсказывает как раз обратное, поэтому давайте анализировать. А можете пройтись по паре функций из перфтопа и сказать, что это за функции и почему они там? Нет ли странных? Насчет ITR - я бы ставил статически низкий. Драйвер по умолчанию идет в Dynamic conservative mode и может генерить десятки тысяч перываний. Они в данном случае совсем не нужны, даже учитывая, что они MSI-X. Изменено 27 апреля, 2010 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 27 апреля, 2010 · Жалоба Драйвер по умолчанию идет в Dynamic mode и может генерить десятки тысяч перываний.Ну и пусть генерит, если процессор при этом не умирает. Всяко лучше, чем неугомонный ksoftirqd, который в нормальных условиях вообще просыпаться не должен.А можете пройтись по паре функций из перфтопа и сказать, что это за функции и почему они там? Нет ли странных?Я не знаю как отличить странные функции от не странных... И как это поможет изучить влияние HZ на forwarding? Судя по этому http://downloadmirror.intel.com/13663/eng/README.txt - dynamic mode не может нагенерить > 20K прерываний в секунду. Что кстати подтверждает мой опыт. Никогда не видел больших значений. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dbask Опубликовано 27 апреля, 2010 · Жалоба options igb IntMode=2,2,2,2 InterruptThrottleRate=3000,3000,3000,3000 RSS=4,4,4,4 QueuePairs=1,1,1,1 LLIPort=80При таких опциях ethtool -c eth2 что показывает. ethtool -c eth2Coalesce parameters for eth2: Adaptive RX: off TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 0 pkt-rate-high: 0 rx-usecs: 325 rx-frames: 0 rx-usecs-irq: 0 rx-frames-irq: 0 tx-usecs: 0 tx-frames: 0 tx-usecs-irq: 0 tx-frames-irq: 0 rx-usecs-low: 0 rx-frame-low: 0 tx-usecs-low: 0 tx-frame-low: 0 rx-usecs-high: 0 rx-frame-high: 0 tx-usecs-high: 0 tx-frame-high: 0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...