Dark_Angel Опубликовано 27 апреля, 2010 (изменено) · Жалоба 2Умник: ksoftirqd - это само ядро. Например, как бы Вы не старались, если у Вас есть шейпинг, iptables на машине - у Вас будут идти тики на ksoftirqd. И хотя, название, отвечающее, якобы, за софт прерывания, но тем не менее, присутствует, даже когда софтпрерываний нет или очень мало. Кстати, уже обсуждалось в этой теме. Да, а в ядрах 2.4 было как Вы рассказываете. И больше прерываний - только хуже. Например при прерывании было забрано из буфера 100 пакетов и 1000 пакетов. Какое из них более еффективное? На задержке ни в том, ни в том случае это заметно не отразится, зато прерываний будет напорядок меньше и процессор сможет заниматься делом, а не спешно забирать пакеты из буферов карты которых предостаточно. Насчет функций, я просто уточнил, и к HZ это не имеет отношения. Насчет <= 20K - да, но это на каждую очередь. Изменено 27 апреля, 2010 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах 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 что показывает. 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 Все верно... Попробуйте порулить ITR-ом без релоада модуля: ethtool -C eth2 rx-usecs XXX где XXX=1000000/кол-во прерываний. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 27 апреля, 2010 · Жалоба У меня видимо неправильное ядро :) root 4 0.0 0.0 0 0 ? S Mar26 0:01 \_ [ksoftirqd/0] root 7 0.0 0.0 0 0 ? S Mar26 0:00 \_ [ksoftirqd/1] root 10 0.0 0.0 0 0 ? S Mar26 0:00 \_ [ksoftirqd/2] root 13 0.0 0.0 0 0 ? S Mar26 0:00 \_ [ksoftirqd/3] Насчет <= 20K - да, но это на каждую очередь.Почему? Я mpstat смотрю - в сумме на ядре не видел больше 20000. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 27 апреля, 2010 (изменено) · Жалоба 2Умник: может у Вас там просто форвардинг? На ядре или в системе? Просто если 4 ядра, то это 80К в системе. Изменено 27 апреля, 2010 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 27 апреля, 2010 (изменено) · Жалоба Dark_Angel, нет, там NAT + lISG. Правда pps не слишком высокий: в пиках до 180К (то есть 180 пришло, и еще 180 вышло). Просто если 4 ядра, то это 80К в системе.Именно так. Одно ядро - один интерфейс. Изменено 27 апреля, 2010 пользователем Умник Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 27 апреля, 2010 (изменено) · Жалоба 2Умник: NAT не дает ksoftirqd, уж не знаю почему. Возможно softirqd вылазит когда идет переключение контекста ядра. Что такое ISG не знаю. 180К пакетов при 20000 прерываний - это по 9 пакетов за заход. Мне кажется, что это расточительно. Можно минимум до 10 урезать, а то и до 8. У человека другая проблема - у него 2 интерфейса и 8 ядер. Тут можно разойтись по 1-2К на каждое ядро. Будет 4-8К прерываний на каждый интерфейс. Нормально. Изменено 27 апреля, 2010 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 27 апреля, 2010 · Жалоба Вот, господа, пдф-нашел... http://www.redhat.com/promo/summit/2008/do...Mark_Wagner.pdf В какой то степени из нашей темы... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 27 апреля, 2010 (изменено) · Жалоба 2Jugernault: Может я что-то пропустил, но по большей части ребята фигней занимаются. Поменяли вызов - получили 10% прирост, поменяли MTU - вообще шоколад. Для своего эксперимента могли сразу с MTU начать и не мучать мозк и уложится в 5 страниц. Не понимаю как это можно применить к сабжу. 2Уник: И кстати, зашел на одну машину посмотреть. Там 2.1.9, 82576, ITR стоит автоматом, как ни странно. Там 1 интерфейс размазан на 4 ядра. Драйвер делает по 2К на ядро. Выбор оставлен драйверу, наверное, потому что на данной машине нет проблем с продуктивностью. Там правда всего 100-110Kpps. Думал, что прибито статически, потому что больше прерываний там не видел. А потом я пошел почитать про драйвер и увидел: "NOTE: Dynamic interrupt throttling is only applicable to adapters operating in MSI or Legacy interrupt mode, using a single receive queue." "In order to limit the CPU utilization without impacting the overall throughput, we recommend that you load the driver as follows: modprobe igb InterruptThrottleRate=3000,3000,3000" Так что видимо все же надо прибивать статикой. Изменено 27 апреля, 2010 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Jugernault Опубликовано 28 апреля, 2010 · Жалоба 2Jugernault: Может я что-то пропустил, но по большей части ребята фигней занимаются. Поменяли вызов - получили 10% прирост, поменяли MTU - вообще шоколад.Это да... Да и роутингом тут не пахнет...2Jugernault: Может я что-то пропустилВы не обратили внимание на страницу 11 - у них в тестах rxusecs=5, т.е. ITR=200000. И при этом они еще чего то добиваются.А на 53 странице начинают рулить латентностью и снижают ITR до 1000. Странно все это - берут экстремально низкое и экстремально высокое значения и при этом всегда добиваются положительного результата. Правда при экстремально высоком только наворачивание МТУ помогло. А в нашем случае это не вариант. Не понимаю как это можно применить к сабжу.Не применить, а поразмыслить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 28 апреля, 2010 (изменено) · Жалоба NOTE: Dynamic interrupt throttling is only applicable to adapters operating in MSI or Legacy interrupt mode, using a single receive queue.""In order to limit the CPU utilization without impacting the overall throughput, we recommend that you load the driver as follows: modprobe igb InterruptThrottleRate=3000,3000,3000 Непонятное высказывание, учитывая что сейчас везде MSI-X. Если принимать это за истину, то получается, что значение по-умолчанию для подавляющего числа случаев просто неоптимально. Я спрошу в списке рассылки, что они имели ввиду. UPD: Про первую часть я понял. По умолчанию используется не dynamic, а dynamic conservative, так что все нормально. Изменено 28 апреля, 2010 пользователем Умник Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 28 апреля, 2010 · Жалоба 2Jugernault: Понимаете, когда люди страдают фигней, я могу пропустить важный момент, т.к. теряю к занятию интерес. Я вообще слабо представляю машину с 200К прерываний, пусть даже по MSI-X. Я бы не стал данный документ рассматривать как интересный с практической точки зрения. Так, почитать, на других посмотреть. 2Умник: Dynamic conservative и dynamic отличаются только количеством прерываний для разных паттернов трафика. Характерно, что на той машине, о которой я говорил, стоит автоматом IntMode. И другого числа, кроме 8K я не видел там за всё время, хотя трафик плавает от 30К до 110К. Так что я думаю, что данная заметка справедлива для обоих dynamic. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 10 января, 2011 · Жалоба Тоже столкнулся с проблемой ksoftirqd. Система двухпроцессорный Xeon 5502 (2 процессора по 2 ядра), Fedora 12, ядро 2.6.35.6-48.fc12.i686.PAE, сетевая карта, через которую ходит трафик, разбита на 2 вилана (входящий-исходящий), Intel 82574L (прерывания разбиты на tx rx по разным ядрам). Последние события dmesg [ 3541.596770] CE: hpet increased min_delta_ns to 7500 nsec [25375.071900] CE: hpet increased min_delta_ns to 11250 nsec [47283.578542] hrtimer: interrupt took 4046 ns perf top показывает ----------------------------------------------------------------------------------------- PerfTop: 1937 irqs/sec kernel:86.9% exact: 0.0% [1000Hz cycles], (all, 4 CPUs) ----------------------------------------------------------------------------------------- samples pcnt function DSO _______ _____ ______________________ ________ 2538.00 14.0% arc4_crypt [arc4] 1600.00 8.9% intel_idle [kernel] 1058.00 5.9% arc4_set_key [arc4] 967.00 5.3% crypto_ecb_crypt [ecb] 514.00 2.8% _raw_spin_lock [kernel] 510.00 2.8% nf_ct_tuple_equal [kernel] 463.00 2.6% sha_transform [kernel] 328.00 1.8% e1000_clean_rx_irq [e1000e] 273.00 1.5% e1000_intr_msi [e1000e] 243.00 1.3% ipt_do_table [kernel] 226.00 1.3% kmem_cache_alloc [kernel] 225.00 1.2% e1000_clean_tx_irq [e1000e] 191.00 1.1% hpet_next_event [kernel] 186.00 1.0% e1000_clean [e1000e] 185.00 1.0% skb_release_head_state [kernel] 164.00 0.9% __nf_conntrack_find [kernel] 153.00 0.8% kmem_cache_free [kernel] 152.00 0.8% ip_route_input_common [kernel] 141.00 0.8% system_call [kernel] arc4 - это шифрование mppe для pptp, ядро оно не трогает. А вот что такое intel_idle ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 10 января, 2011 · Жалоба Вроде нашел. https://bugzilla.redhat.com/show_bug.cgi?id=636384 В моем ядре по умолчанию включен дебаггинг и из-за этого падает производительность. Сейчас скомпилю новое ядро, посмотрим, исправит ли это ситуацию. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 12 января, 2011 · Жалоба Нет, не то. Ядро без дебаггинга ведет себя точно также. CPU0 CPU1 CPU2 CPU3 0: 36961339 0 0 0 IO-APIC-edge timer 8: 52 0 0 0 IO-APIC-edge rtc0 9: 1 0 0 0 IO-APIC-fasteoi acpi 16: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6, uhci_hcd:usb7, uhci_hcd:usb8 18: 2108 0 0 2197354 IO-APIC-fasteoi ata_piix 19: 43 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb3, uhci_hcd:usb4, uhci_hcd:usb5 21: 0 0 0 0 IO-APIC-fasteoi ata_piix 64: 0 0 0 0 PCI-MSI-edge aerdrv 65: 0 0 0 0 PCI-MSI-edge aerdrv 66: 0 0 0 0 PCI-MSI-edge aerdrv 67: 0 0 0 0 PCI-MSI-edge aerdrv 68: 0 0 0 0 PCI-MSI-edge pciehp 69: 0 0 0 0 PCI-MSI-edge pciehp 70: 243592 464722482 750209 37565640 PCI-MSI-edge eth1 71: 3 0 0 0 PCI-MSI-edge ioat-msix 72: 679 471475487 514932072 0 PCI-MSI-edge eth0-tx0 73: 126 0 0 983676224 PCI-MSI-edge eth0-rx0 74: 64 8 0 0 PCI-MSI-edge eth0 75: 3 0 0 0 PCI-MSI-edge ioat-msix 76: 3 0 0 0 PCI-MSI-edge ioat-msix 77: 3 0 0 0 PCI-MSI-edge ioat-msix 78: 3 0 0 0 PCI-MSI-edge ioat-msix 79: 3 0 0 0 PCI-MSI-edge ioat-msix 80: 3 0 0 0 PCI-MSI-edge ioat-msix При этом top - 21:53:28 up 21:08, 3 users, load average: 0.41, 0.41, 0.76 Tasks: 2345 total, 2 running, 2343 sleeping, 0 stopped, 0 zombie Cpu0 : 2.8%us, 5.5%sy, 0.0%ni, 89.0%id, 0.0%wa, 0.0%hi, 2.8%si, 0.0%st Cpu1 : 23.1%us, 6.0%sy, 0.0%ni, 60.7%id, 0.0%wa, 0.0%hi, 10.3%si, 0.0%st Cpu2 : 0.9%us, 0.9%sy, 0.0%ni, 35.5%id, 0.0%wa, 0.0%hi, 62.7%si, 0.0%st Cpu3 : 0.9%us, 0.9%sy, 0.0%ni, 97.3%id, 0.0%wa, 0.0%hi, 0.9%si, 0.0%st Mem: 8240856k total, 8051576k used, 189280k free, 136896k buffers Swap: 3145724k total, 0k used, 3145724k free, 5622192k cached Как видно сильно загружается только CPU2, то есть eth0-tx0. Почему rx-0 так не нагружен? По идее они должны быть загружены одинаково, ведь eth0 разбит на виланы eth0.10 и eth0.100 и трафик гуляет в обе стороны абсолютно одинаково - сколько пришло столько и ушло. Проблемы начинаются при ~ 20-25kpps и трафике около 320-340 мбит в одном направлении. Это просто смешные показатели для такой машины. Да, на машине стоит ВПН-сервер и ppp, поднимая интерфейс, применяет шейпер /sbin/tc qdisc add dev $REALDEVICE root tbf rate ${shape}kbit burst ${burst}kb latency 80ms minburst 1540 >/dev/null 2>&1 /sbin/tc qdisc add dev $REALDEVICE handle ffff: ingress /sbin/tc filter add dev $REALDEVICE parent ffff: protocol ip u32 match ip src 0.0.0.0/0 police rate ${shape}kbit burst ${burst}kb drop flowid :1 Всё. Ната нет, iptables 10 правил, да и их очищал - не помогает. Пробовал убирать /sbin/tc qdisc add dev $REALDEVICE handle ffff: ingress , думал что с очередью не справляется - бесполезно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 13 января, 2011 · Жалоба 2Justas: несколько вопросов: 1. Почему у вас tx очередь к ядру не прибита? 2. Включен ли irq balance? 3. Сколько суммарно интерфейсов у Вас? 4. Сколько прерываний выполняет каждая очередь? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 13 января, 2011 · Жалоба 2Justas: несколько вопросов: 1. Почему у вас tx очередь к ядру не прибита? Как это не прибита? Прибита. eth0-tx0 сидит на первом ядре второго процессора. 2. Включен ли irq balance? В текущий момент - да. Но ранее я пробовал выключать и регулировать прерывания вручную путем echo "1" > /proc/irq/70/smp_affinity echo "4" > /proc/irq/72/smp_affinity echo "8" > /proc/irq/73/smp_affinity К положительному результату не приводит. 3. Сколько суммарно интерфейсов у Вас? Физических - два, виртуальных - 2. То есть eth0 разбит на eth0.10 и eth0.100 и весь трафик через них и ходит. eth1 выполняет функцию сбора статистики с mirror-порта коммутатора. 4. Сколько прерываний выполняет каждая очередь? Примерно 18000 прерываний на очередь судя по /proc/interrupts. И в своем предыдущем посте я погорячился, не туда смотрел. Проблемы начинаются при ориентировочно таких показателях: sar -n DEV 1 07:16:47 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/ 07:16:48 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.0 07:16:48 PM eth1 30007.14 0.00 27774.51 0.00 0.00 0.00 0.0 07:16:48 PM eth0 56926.53 53398.98 38923.93 38864.55 0.00 0.00 0.0 07:16:48 PM eth0.10 28160.20 24559.18 25699.67 11626.35 0.00 0.00 0.0 07:16:48 PM eth0.100 28790.82 28842.86 12483.71 27242.55 0.00 0.00 0.0 mpstat -P ALL -A 07:18:40 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 07:18:40 PM all 4.67 0.85 1.89 0.94 0.00 5.63 0.00 0.00 86.02 07:18:40 PM 0 4.54 1.24 1.40 0.51 0.00 0.56 0.00 0.00 91.75 07:18:40 PM 1 9.41 0.65 4.61 0.93 0.00 5.67 0.00 0.00 78.73 07:18:40 PM 2 1.78 1.41 0.71 0.07 0.00 15.60 0.00 0.00 80.43 07:18:40 PM 3 2.74 0.10 0.72 2.25 0.00 0.68 0.00 0.00 93.51 07:18:40 PM CPU intr/s 07:18:40 PM all 39157.37 07:18:40 PM 0 534.81 07:18:40 PM 1 0.00 07:18:40 PM 2 0.00 07:18:40 PM 3 0.00 07:18:40 PM CPU 0/s 8/s 9/s 07:18:40 PM 0 534.81 0.00 0.00 07:18:40 PM 1 0.00 0.00 0.00 07:18:40 PM 2 0.00 0.00 0.00 07:18:40 PM 3 0.00 0.00 0.00 То есть ~30000 pps на eth1 и 55000 pps на eth0. Итого 85 kpps, из них 55 kpps и 350 мбит - это маршрутизация. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 13 января, 2011 · Жалоба Добрался я до oprofile, наконец-то. # opcontrol --reset # opcontrol --vmlinux=/usr/lib/debug/lib/modules/2.6.35.10-76.fc12.i686.PAE/vmlinux # opcontrol --start Using default event: CPU_CLK_UNHALTED:100000:0:1:1 Using 2.6+ OProfile kernel interface. Reading module info. Using log file /var/lib/oprofile/samples/oprofiled.log Daemon started. Profiler running. Подключаюсь к VPN-серверу со своего компьютера. Делаю ping -f www.ru Вижу как резко возрастает top top - 23:30:15 up 1 day, 22:48, 3 users, load average: 1.67, 1.16, 0.76 Tasks: 1694 total, 3 running, 1691 sleeping, 0 stopped, 0 zombie Cpu0 : 0.9%us, 0.9%sy, 0.0%ni, 93.4%id, 3.8%wa, 0.0%hi, 0.9%si, 0.0%st Cpu1 : 12.5%us, 6.7%sy, 0.0%ni, 77.5%id, 0.8%wa, 0.0%hi, 2.5%si, 0.0%st Cpu2 : 0.0%us, 0.9%sy, 0.0%ni, 10.2%id, 0.0%wa, 0.0%hi, 88.9%si, 0.0%st Cpu3 : 2.7%us, 4.5%sy, 0.0%ni, 87.3%id, 3.6%wa, 0.0%hi, 1.8%si, 0.0%st Mem: 8240856k total, 7714504k used, 526352k free, 121516k buffers Swap: 3145724k total, 0k used, 3145724k free, 5556320k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10 root 20 0 0 0 0 S 70.5 0.0 109:44.53 ksoftirqd/2 2248 root 20 0 142m 53m 380 S 30.1 0.7 468:35.97 LBcd 11827 root 20 0 4336 2840 848 R 6.6 0.0 23:55.65 top 17 root 20 0 0 0 0 R 3.8 0.0 61:39.04 events/2 4636 root 20 0 8068 2532 1852 S 2.8 0.0 0:00.52 pppd 29514 root 20 0 4400 824 632 S 2.8 0.0 0:09.11 sadc 9385 root 20 0 1936 460 404 S 1.9 0.0 0:00.08 pptpctrl 1505 root 20 0 3048 568 328 S 0.9 0.0 3:31.87 irqbalance 18999 root 20 0 8068 2580 1904 S 0.9 0.0 0:06.01 pppd 29512 root 20 0 4640 972 552 S 0.9 0.0 0:03.34 sar 1 root 20 0 2092 724 508 S 0.0 0.0 0:01.52 init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root 20 0 0 0 0 S 0.0 0.0 0:29.05 ksoftirqd/0 4 root RT 0 0 0 0 S 0.0 0.0 0:00.39 migration/0 5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0 6 root RT 0 0 0 0 S 0.0 0.0 0:02.82 migration/1 7 root 20 0 0 0 0 S 0.0 0.0 0:32.16 ksoftirqd/1 8 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/1 Смотрю статистику своего интерфейса # sar -n DEV 1 | grep ppp402 11:31:15 PM ppp402 25290.10 25287.13 2074.39 2074.18 0.00 0.00 0.00 11:31:16 PM ppp402 20298.00 20317.00 1664.88 1666.47 0.00 0.00 0.00 11:31:17 PM ppp402 20583.00 20552.00 1688.25 1685.75 0.00 0.00 0.00 11:31:18 PM ppp402 14252.53 14254.55 1168.96 1169.16 0.00 0.00 0.00 11:31:19 PM ppp402 17409.71 17425.24 1427.93 1429.23 0.00 0.00 0.00 11:31:20 PM ppp402 18971.28 18967.02 1556.22 1555.75 0.00 0.00 0.00 11:31:21 PM ppp402 17168.93 17170.87 1408.22 1408.41 0.00 0.00 0.00 11:31:22 PM ppp402 17822.00 17808.00 1461.77 1460.65 0.00 0.00 0.00 То есть тупой флуд на 20 kpps укладывает сервер. Далее # opcontrol --shutdown # opreport -l CPU: Intel Core/i7, speed 1866.45 MHz (estimated) Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000 samples % image name app name symbol name 3002815 16.1279 arc4 arc4 /arc4 2526091 13.5674 LBcd LBcd /usr/LBcd 1343587 7.2163 vmlinux vmlinux poll_idle 1078459 5.7923 e1000e e1000e /e1000e 815201 4.3784 ecb ecb /ecb 366514 1.9685 vmlinux vmlinux sha_transform 354812 1.9057 vmlinux vmlinux nf_ct_tuple_equal 287738 1.5454 vmlinux vmlinux intel_idle 281076 1.5096 vmlinux vmlinux mutex_spin_on_owner 265681 1.4269 vmlinux vmlinux ipt_do_table 215145 1.1555 vmlinux vmlinux sch_direct_xmit 177920 0.9556 ppp_generic ppp_generic /ppp_generic 166282 0.8931 vmlinux vmlinux skb_release_head_state 144344 0.7753 vmlinux vmlinux dev_queue_xmit 140270 0.7534 vmlinux vmlinux kmem_cache_alloc 132683 0.7126 vmlinux vmlinux __nf_conntrack_find 122292 0.6568 vmlinux vmlinux system_call 122009 0.6553 vmlinux vmlinux kmem_cache_free 119600 0.6424 vmlinux vmlinux __kmalloc_track_caller 111203 0.5973 vmlinux vmlinux __netif_receive_skb 110837 0.5953 vmlinux vmlinux bit_spin_lock.clone.2 /arc4 - это arcfour шифрование mppe. Я подключался к серверу с ним. Позже я подключился без него и при генерации такого же количества пакетов загрузка softirqd была примерно в 2-3 раза ниже. Предварительный вывод - шифрование определенно сильно напрягает ядро. Подтвердит ли кто? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 14 января, 2011 (изменено) · Жалоба 2Justas: 1. А как Вы прибиваете очередь, если у вас запущен irq balance да еще и 72: 679 471475487 514932072 0 PCI-MSI-edge eth0-tx0 Второе и третье ядро примерно поровну прерываний? 2. Однозначно выключить и прибить руками, причем желательно к последним ядрам самые нагруженые очереди, потому что эти ядра обычно нагружены меньше всего. 3. Езернет интерфейсы не интересны ( вы про них написали до этого ), я спросил про ppp интерфейсы. 4. Это много, опускайте до 4К на очередь. 5. Покажите сколько переключений контекста у Вас сразу. Процессор 1.8 Ггц, это правда? 6. Откуда у вас набегают iowait? 7. Сколько HZ у вас стоит в ядре? 8. А что еще запущено на машине помимо PPTPd? Шифрование, очевидно, сильно грузит систему и это неоднократно обсуждалось тут. Если у вас сетевой НАС, то с шифрованием вам надо будет ставить в 4 раза больше НАСов, чем без него. Поэтому обычно шифрование на НАСах у всех выключено - и без того проблем достаточно. Изменено 14 января, 2011 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 14 января, 2011 · Жалоба 1. А как Вы прибиваете очередь, если у вас запущен irq balance да еще и 72: 679 471475487 514932072 0 PCI-MSI-edge eth0-tx0 Второе и третье ядро примерно поровну прерываний? 2. Однозначно выключить и прибить руками, причем желательно к последним ядрам самые нагруженые очереди, потому что эти ядра обычно нагружены меньше всего. Нет, это я с smp_affinity игрался и с ядра на ядро перекидывал прерывания. Эту тему я перечитал 2 раза с самого начала, основные требования к настройкам системы понял. 3. Езернет интерфейсы не интересны ( вы про них написали до этого ), я спросил про ppp интерфейсы. А, прошу прощения, туплю. Около 1100. 4. Это много, опускайте до 4К на очередь. Сейчас применяю опции драйвера options e1000e IntMode=2,2 InterruptThrottleRate=3,3. Подойдет InterruptThrottleRate=4000,4000 ? 5. Покажите сколько переключений контекста у Вас сразу. Процессор 1.8 Ггц, это правда? # vmstat -S M procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 5 0 0 5231 167 958 0 0 244 136 43 33 5 8 86 1 0 Чистая правда. Processor Information Socket Designation: CPU1 Type: Central Processor Family: Xeon Manufacturer: Intel(R) Corporation ID: A5 06 01 00 FF FB EB BF Signature: Type 0, Family 6, Model 26, Stepping 5 Version: Intel(R) Xeon(R) CPU E5502 @ 1.87GHz Voltage: 1.2 V External Clock: 133 MHz Max Speed: 4000 MHz Current Speed: 1866 MHz Status: Populated, Enabled L1 Cache Handle: 0x0050 L2 Cache Handle: 0x0051 L3 Cache Handle: 0x0052 Core Count: 2 Core Enabled: 2 Thread Count: 2 6. Откуда у вас набегают iowait? Отличный вопрос. Не знаю. Может, из-за большого количества "пустых", по сути не нужных прерываний? Потому как дисковая подсистема - это софтварный зеркальный raid-1 # iostat avg-cpu: %user %nice %system %iowait %steal %idle 4.43 0.91 8.07 0.94 0.00 85.65 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn sda 13.00 965.87 1095.93 205612762 233301804 sdb 13.39 1010.07 1095.93 215023754 233301804 md0 0.01 0.03 0.00 6196 108 md126 157.46 1972.03 1091.23 419804514 232301032 dm-0 156.89 1972.02 1091.23 419801650 232301032 dm-1 0.00 0.01 0.00 1088 0 Не думаю что он так сильно тормозит. Да и операций чтения-записи мало. 7. Сколько HZ у вас стоит в ядре? CONFIG_HZ_1000=y CONFIG_HZ=1000 Шифрование, очевидно, сильно грузит систему и это неоднократно обсуждалось тут. Если у вас сетевой НАС, то с шифрованием вам надо будет ставить в 4 раза больше НАСов, чем без него. Поэтому обычно шифрование на НАСах у всех выключено - и без того проблем достаточно. Такой вопрос. Меня смущает, что arc4 грузит именно одну очередь на конкретном интерфейсе сетевого адаптера. Очевидно, реализация алгоритма шифрования напрямую связана с сетевой подсистемой и ее прерываниями. Раз нагружается TX, то это исходящий от сервера к абоненту зашифрованный трафик и львиную долю процессорного времени занимает шифрование. Хотя я могу ошибаться. Вопрос: как считаете, если установить карту 1000ET и распределить TX-очередь на 3 ядра, функция шифрования тоже будет распределена на 3 ядра? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 14 января, 2011 (изменено) · Жалоба 3. Многовато. Я так понимаю это НАС в локальной сети? Зачем там шифрование? 4. Да, статикой прибивайте и после прибивки посмотрите статистику драйвера, нет ли потерь из-за отстутсвия места в буфере. Если будет, подымете до 6К. Для вашего трафика и сетевой 4К - должно быть нормально. Сразу же подкрутите ring buffer. 5. Это что-то левое. Сделайте vmstat 1 и покажите в динамике, потому что судя по тому что Вы показали у Вас 43 прерывания непонятно в какую единицу времени. 6. Нет, iowait от этого не набегает. Дисковые операции плохи не только нагрузкой на ЦП, а переключением контекстов, вымываением кеша у процов, дополнительными прерываниями. Нужно выяснить откуда они идут и постараться их убрать. Это от проблемы, конечно, не излечит, но даст еще немного запаса производительности. Кроме того 190 операций - это не мало, тем более для 1.8 Ггц. 8. ? Но вообще oprofile правильно наводит на проблему - это шифрование. На 1.1К туннелей, я думаю что там порядка 120-150К переключений контекста, если не больше в моменты до захлеба. Уберете шифрование, получите порядка 60% доп мощности. То есть еще столько же тунелей сможете посадить и + столько же трафика пропустить. Еще узкое место - медленный процессор. Не помню есть ли в этой теме инфа или есть в другой, но для роутеров нужны быстрая память и быстрый процессор. Можно не супер производительный, но быстрый. И кешей побольше. Разнести нагрузку по процессорам поможет только наличие гибридных RxTx очередей, если карта умеет или увеличение tx очередей, опять таки есть можно, т.к. у Вас еще есть свободные ядра. UPD. Да, если разнести TX по ядрам - шифрование будет идти на нескольких ядрах, то есть другая сетевая проблему решит, но лиш временно, пока всё не захлебнется. Догадка по поводу шифрования при отдаче пакета в виртуальный интерфейс похожа на правду тем более что arc4 модуль ядра. Я думаю процедура там такова: получаем пакет, пропускаем через iptables, шифруем, переключаем контекст, отправляем в user-space. Зная как сделан pptp - я думаю там еще прикрутили десяток другой переключений туда-обратно. Цифра с количеством переключений контекстом - даст окончательный ответ. Т.к. если их уже и так много, то дополнительные сетевые не разгрузят систему линейно. Хватит на лишних 50Мбит и нагрузка начнет расти экспотенциально. Спасут только радикальные меры. Смена процессора на более быстрый опять таки только отсрочит проблему на лишних 100-150 Мбит. Изменено 14 января, 2011 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 14 января, 2011 · Жалоба 3. Многовато. Я так понимаю это НАС в локальной сети? Зачем там шифрование? Да, это НАС в локалке. Исторически сложилось, что шифрование использовалось с 2003 года ввиду повального перехода на WinXP, в которой галка "Использовать шифрование" в vpn-подключениях стояла (и стоит) по умолчанию. С целью упрощения настройки для пользователей 8 лет назад было принято решение включить mppe на сервере. Как-то вот тогда не особо задумывался об нагрузках и радел исключительно об удобстве пользователей :( 4. Да, статикой прибивайте и после прибивки посмотрите статистику драйвера, нет ли потерь из-за отстутсвия места в буфере. Если будет, подымете до 6К. Для вашего трафика и сетевой 4К - должно быть нормально. Сразу же подкрутите ring buffer. Да, уже подкрутил: ethtool -G eth0 rx 2048 tx 2048 . До этого стояло 256 и потери вообще страшные были. Осталось ITR изменить, но это ночью на днях. 5. Это что-то левое. Сделайте vmstat 1 и покажите в динамике, потому что судя по тому что Вы показали у Вас 43 прерывания непонятно в какую единицу времени. Вот момент, когда трафик генерировать начинаю. # vmstat 1 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 5151680 179268 1013272 0 0 236 132 4 36 5 8 86 1 0 1 0 0 5151812 179268 1013268 0 0 0 0 47303 16136 3 7 89 0 0 1 0 0 5151820 179268 1013268 0 0 0 0 46842 15122 4 6 90 0 0 0 0 0 5151820 179272 1013268 0 0 0 160 47314 15379 3 6 84 7 0 0 0 0 5151820 179272 1013268 0 0 0 0 47645 15236 4 7 89 0 0 1 0 0 5151812 179272 1013268 0 0 0 0 46383 15110 3 5 91 0 0 0 0 0 5151464 179272 1013272 0 0 0 0 47978 15591 4 6 90 0 0 0 0 0 5150996 179272 1013272 0 0 0 72 46941 15231 5 8 85 2 0 2 0 0 5151040 179272 1013280 0 0 0 24 45395 14617 3 5 92 0 0 0 0 0 5150980 179272 1013280 0 0 0 0 46568 14437 3 6 91 0 0 1 0 0 5150980 179272 1013280 0 0 0 0 47926 16496 4 6 91 0 0 0 0 0 5151044 179272 1013280 0 0 0 0 46730 15019 3 5 91 0 0 1 0 0 5151044 179272 1013280 0 0 0 0 45979 14742 3 5 91 0 0 0 0 0 5151044 179276 1013280 0 0 0 84 47680 15426 4 6 87 3 0 2 0 0 5151052 179276 1013280 0 0 0 0 47762 15451 4 6 91 0 0 1 0 0 5151052 179276 1013280 0 0 0 0 48092 15607 3 7 90 0 0 0 0 0 5150928 179284 1013272 0 0 0 204 47222 16195 3 7 83 7 0 0 0 0 5151084 179284 1013276 0 0 0 8 46845 15120 4 6 90 0 0 0 0 0 5150704 179284 1013280 0 0 0 20 47187 15143 3 6 91 0 0 0 0 0 5151440 179284 1013284 0 0 0 0 46833 15196 4 6 90 0 0 0 0 0 5151328 179284 1013280 0 0 0 0 47305 15939 6 10 85 0 0 0 0 0 5151240 179284 1013284 0 0 0 0 46895 14674 3 5 91 0 0 0 0 0 5151264 179288 1013280 0 0 0 108 46860 15053 3 6 87 3 0 Сейчас не час-пик, поэтому полностью воссоздать самый загруженный промежуток времени пока проблематично. Но вроде cs немного, а ksoftirqd собственно забирает процессор на себя. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10 root 20 0 0 0 0 R 52.8 0.0 112:21.64 ksoftirqd/2 6. Нет, iowait от этого не набегает. Дисковые операции плохи не только нагрузкой на ЦП, а переключением контекстов, вымываением кеша у процов, дополнительными прерываниями. Нужно выяснить откуда они идут и постараться их убрать. Это от проблемы, конечно, не излечит, но даст еще немного запаса производительности. Кроме того 190 операций - это не мало, тем более для 1.8 Ггц. Учту, спасибо. 8. ? 8. А что еще запущено на машине помимо PPTPd? MySQL, Apache и биллинг :) Не ругайте меня, я знаю :) Мускуль по хорошему вообще на другой машине должен быть. Я сейчас над этим работаю. Но вообще oprofile правильно наводит на проблему - это шифрование. На 1.1К туннелей, я думаю что там порядка 120-150К переключений контекста, если не больше в моменты до захлеба. Уберете шифрование, получите порядка 60% доп мощности. То есть еще столько же тунелей сможете посадить и + столько же трафика пропустить. Еще узкое место - медленный процессор. Не помню есть ли в этой теме инфа или есть в другой, но для роутеров нужны быстрая память и быстрый процессор. Можно не супер производительный, но быстрый. И кешей побольше. Разнести нагрузку по процессорам поможет только наличие гибридных RxTx очередей, если карта умеет или увеличение tx очередей, опять таки есть можно, т.к. у Вас еще есть свободные ядра. UPD. Да, если разнести TX по ядрам - шифрование будет идти на нескольких ядрах, то есть другая сетевая проблему решит, но лиш временно, пока всё не захлебнется. Догадка по поводу шифрования при отдаче пакета в виртуальный интерфейс похожа на правду тем более что arc4 модуль ядра. Я думаю процедура там такова: получаем пакет, пропускаем через iptables, шифруем, переключаем контекст, отправляем в user-space. Зная как сделан pptp - я думаю там еще прикрутили десяток другой переключений туда-обратно. Цифра с количеством переключений контекстом - даст окончательный ответ. Т.к. если их уже и так много, то дополнительные сетевые не разгрузят систему линейно. Хватит на лишних 50Мбит и нагрузка начнет расти экспотенциально. Спасут только радикальные меры. Смена процессора на более быстрый опять таки только отсрочит проблему на лишних 100-150 Мбит. Получается, "старые" Ксеоны 2005 года выпуска на 3.6ГГц с 16КБ L1 и 2МБ L2 кэша для роутинга быстрее, чем более производительный современный Ксеон 2009 года 1.8ГГц с 32КБ L1 и 2МБ L2 кэшем? И спасибо за развернутый ответ, есть над чем подумать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 14 января, 2011 (изменено) · Жалоба 3. Проблема известна, но с решением вы поторопились. Даже не знаю что вам теперь делать, учитывая отсутствие возможности масштабирования у pptp. Roundrobin DNS и второй сервер? 4. Учтите, что увеличение буфера усугубляет ситуацию. Чем меньше буфер, тем быстрее работает. При вашем трафике однако тут не большой вклад будет. Сразу хотел спросить: ложит ли смена буфера интерфейс или происходит налету? 5. Давайте уберем прервания, посмотрим что будет, переключений контекста действительно не много. 8. Дает ответ на 6) тут кто-то высказывался по этой теме на первых страницах, что из-за неидеальности софта приходиться разносить. Вовсе не потому что загружает под самые яйца, так что разносите, иначе проблему можно искать долго и в результате всеравно не найти. Насчет Ксеонов, да, даже несмотря на больший в 2 раза L1 кеш у последнего. Но у вас-то не чистый роутинг. UPD. Кстати, а откуда это? Этот ксеон может 4Ггц но работает на 1.8? External Clock: 133 MHz Max Speed: 4000 MHz Current Speed: 1866 MHz Если у него 2 ядра, а остальные HT, то HT на роутерах вреден и его надо отключать. С другой стороны, у вас опять-таки не чистый роутер. Core Count: 2 Core Enabled: 2 Thread Count: 2 Изменено 14 января, 2011 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 14 января, 2011 · Жалоба ну какбы насчет проигрыша новых ксеонов старым - я бы не согласился, на роутинге и фаерволе новые ксеоны заметно лучше работают Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 14 января, 2011 · Жалоба Тут не про новые и старые вопрос, а про 1.8 новый и 3.6 старый. Так вот старый на 3.6 сделает новый при такой же количестве ядер на чистом роутинге. У вас есть обратный опыт? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 14 января, 2011 · Жалоба Сетевая с e1000 не может нормально раскидывать очереди по ядрам, с одним интерфейсом так и должно быть, одно ядро под планку, на втором чего-то эпизодически, а остальные свободны. Зачем вы такую странную схему придумали, весь трафик через одну сетевку пустить? В этом случае количество трафика через интерфейс еще и удваивается, и через интерфейс бегает (вход + исход) * 2. При ваших '340 мбит в одну сторону' суммарно трафика может получиться и больше гига, тут уже самим сетевкам простым может плохеть)) Перевесьте виланы входящий на eth0, исходящий на eth1, а интерфейс используемый для сбора статистики или повесьте виланом на любой из них, или вообще схему поменяйте. Туда льется тот же трафик что и через сервер проходит? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
