Skip to content

О пользе irqbalance

Однажды приключилась неприятная фигня. Симптомы:

  • Потери ICMP-пакетов
  • Пинг 130 мс при норме 30мс
  • top выглядит крайне скверно (особое внимание на 70% у ksoftirqd/0): 
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
16763 catalina  20   0 33.3g  13g  13m S 938.0 21.2  36335:28 java
    4 root      20   0     0    0    0 R 70.3  0.0 188:10.66 ksoftirqd/0
10362 haproxy   20   0 1411m 1.3g 1784 R 66.3  2.1   3:24.43 haproxy
10361 haproxy   20   0 1255m 1.1g 1800 R 61.4  1.8   3:14.30 haproxy
10360 haproxy   20   0 1163m 1.1g 1780 R 56.8  1.7   3:04.97 haproxy
10359 haproxy   20   0 1032m 951m 1796 S 48.6  1.5   2:51.85 haproxy
10358 haproxy   20   0  995m 916m 1800 S 43.7  1.4   2:44.77 haproxy
10357 haproxy   20   0  915m 836m 1776 R 33.5  1.3   2:33.69 haproxy
10356 haproxy   20   0  841m 764m 1776 D 32.5  1.2   2:27.62 haproxy
10355 haproxy   20   0  800m 724m 1800 R 29.5  1.1   2:20.10 haproxy
  • Все прерывания от сетевой карты обслуживаются только одним ядром (из 24-ех): 
    # cat /proc/interrupts | grep -E "CPU|em1" | sed -r "s/ +/  /g" | sed -r "s/CPU//g"
                 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17 18 19 20 21 22 23
  125:   146771849  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  IR-PCI-MSI-edge  em1-0
  126:  2740374640  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  IR-PCI-MSI-edge  em1-1
  127:  2693791925  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  IR-PCI-MSI-edge  em1-2
  128:  2693712466  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  IR-PCI-MSI-edge  em1-3
  129:  2695319407  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  IR-PCI-MSI-edge  em1-4

Вспомнилась картинка:

Как правильно копать яму

Team work.


И, конечно же, возникла идея поправить это безобразие. Но ждал облом:

# service irqbalance start
Starting irqbalance: irqbalance: symbol lookup error: irqbalance: undefined symbol: g_list_free_full
                                                           [FAILED]

Небольшое гугление подсказало, что, возможно, имеем дело с устаревшей версией пакета glib2. Пробуем обновить:

# yum update glib2
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package glib2.x86_64 0:2.26.1-7.el6_5 will be updated
---> Package glib2.x86_64 0:2.28.8-4.el6 will be an update
--> Finished Dependency Resolution
 
# tail -n 1 /var/log/yum.log
Nov 20 16:19:34 Updated: glib2-2.28.8-4.el6.x86_64

После этого случилось чудо и irqbalance таки запустился:

# service irqbalance start
Starting irqbalance:                                       [  OK  ]

И получаем вот такую красоту (прерывания стали распределяться и по другим ядрам тоже):

# cat /proc/interrupts | grep -E "CPU|em1" | sed -r "s/ +/  /g" | sed -r "s/CPU//g"
                 0  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23
  125:   146771849  0  0  0  0  0  0  0  2964882  0  0  0  39242  0  75507  0  0  0  0  0  0  0  0  0  IR-PCI-MSI-edge  em1-0
  126:  2740374640  0  7566544  0  0  0  0  0  0  0  0  0  10004  0  0  0  162137  0  0  0  0  0  0  0 IR-PCI-MSI-edge  em1-1
  127:  2693791925  0  0  0  0  0  0  0  0  0  0  0  8771  0  7319795  0  0  0  157178  0  0  0  0  0  IR-PCI-MSI-edge  em1-2
  128:  2693712466  0  0  0  0  0  0  0  0  0  0  0  7369768  0  0  0  0  0  0  0  158210  0  0  0     IR-PCI-MSI-edge  em1-3
  129:  2695319407  0  0  0  0  0  0  0  0  0  0  0  77028  0  0  0  0  0  7301320  0  0  0  158271  0 IR-PCI-MSI-edge  em1-4

Далее пинг падает до со 130 до 30 мс, ICMP-потери прекращаются, nagios перестаёт вопить про периодически недоступные сервисы, ksoftirqd из top-а пропадает:

top - 16:39:53 up 79 days,  2:41, 18 users,  load average: 40.03, 35.48, 27.67
Tasks: 446 total,   9 running, 437 sleeping,   0 stopped,   0 zombie
Cpu(s): 54.0%us, 16.9%sy,  0.0%ni, 19.8%id,  0.0%wa,  0.0%hi,  9.4%si,  0.0%st
Mem:  65920820k total, 40078188k used, 25842632k free,   261184k buffers
Swap:  8290296k total,        0k used,  8290296k free, 11422368k cached
 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
16763 catalina  20   0 32.6g  13g  13m S 1452.3 21.0  36642:46 java
15460 haproxy   20   0  702m 627m 2276 R 60.3  1.0   9:55.44 haproxy
15464 haproxy   20   0  758m 679m 2276 R 59.4  1.1  10:26.81 haproxy
15459 haproxy   20   0  729m 653m 2272 R 58.0  1.0   9:53.93 haproxy
15463 haproxy   20   0  729m 652m 2268 R 58.0  1.0  10:23.88 haproxy
15462 haproxy   20   0  725m 649m 2308 R 57.4  1.0  10:13.97 haproxy
15466 haproxy   20   0  771m 693m 2296 R 54.8  1.1  10:33.94 haproxy
15468 haproxy   20   0  722m 645m 2308 R 51.8  1.0  10:26.30 haproxy
15461 haproxy   20   0  737m 661m 2308 R 51.5  1.0  10:05.91 haproxy
26785 avz       20   0 15296 1600  988 R  1.0  0.0   0:00.07 top
15539 root      20   0 15296 1624  988 S  0.7  0.0   0:13.21 top
   73 root      20   0     0    0    0 S  0.3  0.0   6:55.14 ksoftirqd/17

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

Posted in *nix.

Tagged with .

rev="post-1623" No comments

By Admin – 01.03.2016

r8169: после выхода из спящего режима не работает сеть

На ноутбуке Dell Vostro 5470 с Fedora 21 на борту наблюдалась очень неприятная проблема – после выхода из спящего режима переставала работать сеть через медный интерфейс. После перезагрузки опять работала. Но а поскольку это все же ноут, то очень хотелось проблему побороть, так как заряд батареи нужно экономить и без спящего режима ну никак не обойтись.

Сетевая карта там вот такая:

# lspci -vvv | sed -r '/Ethernet/,/module/ !d' | grep -E "Ethernet|module"
07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 10)
        Kernel modules: r8169

В процессе танцев с бубном в том числе запускался и tcpdump дла анализа проблемы. Ну и между делом случайно заметил, что если ноут уходит в спячку с запущенным tcpdump-ом, то после пробуждения вышеописанная проблема не возникает. Это навело на мысль, что, возможно, promiscuous режим работы сетевого интерфейса как-то помогает ему проснуться в добром здравии и в адекватном рабочем состоянии. Гипотеза подтвердилась после нескольких тестов.

Поскольку в Fedora 21 всем рулит systemd, то далее пришлось погуглить ответ на вопрос "Как выполнить мой скрипт при пробуждении". Ответ нашелся довольно быстро – вот так:

Создаем файл /usr/lib/systemd/system-sleep/local.sh, делаем ему chmod +x

#!/bin/bash
 
if [ "$1" = "post" ]; then
  /sbin/ifconfig enp7s0 promisc
  logger "Custom wakeup script fired ($0)"
fi
exit 0

Здесь enp7s0 – имя моего сетевого интерфейса. logger добавлен для диагностики, чтобы было понятно выполнялся скрипт при выходе из спящего режима или нет.

И шо вы думаете? Таки помогло! Теперь сетка нормально работает независимо от количества засыпаний ноута. Красота!

Posted in *nix, Howto.

rev="post-1620" 1 comment

By Admin – 21.02.2016

Конфиг haproxy для оценки A от SSLLabs.com

1. В секцию global конфига haproxy.cfg добавляем

ssl-default-bind-ciphers   ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
ssl-default-server-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

2. В конфигурации фронтенда отключаем SSL v3:

frontend ssl-fe
  bind 10.10.10.10:443 ssl no-sslv3 crt /path/to/certs-with-key.pem

Если SSL-сертификат был выпущен доверенным центром сертификации и при создании приватного ключа НЕ был выбран Signature Algorithm SHA1, то ssllabs.com должен показать нечто примерно такое:

ssllabs A-grade haproxy config

Выключаем слабые алгоритмы шифрования

А вот полезная ссылочка – конструктор конфигов для пополярных веб-серверов, где можно подобрать алгоритмы шифрования с учетом требуемого уровня совместимости с устаревшими версиями программного обеспечения на клиентах.

Posted in *nix.

Tagged with , , .

rev="post-1616" No comments

By Admin – 10.02.2016

Перебит подводный интернет-кабель у берегов Австралии

Невесёлые новости пришли к нам из солнечной Австралии. У тамошних Интернет-пользователей внешние каналы временно потеряли в пропускной способности около двух терабит/сек из-за обрыва кабеля PPC-1 на глубине около 3-х километров на участке между островом Гуам и Сиднеем.

остров Гуам в юго-западной части Тихого океана

Примерное расположение острова Гуам относительно Австралии

There is a submarine fiber cut (PPC-1) which started on the 7th of February. NFOrce is not directly affected however IP transit and peerings are definately going to experience capacity issues towards Australia.

Please allow IP transit providers and peering partners to reroute traffic over Japan and Southern Cross.

Сообщение от The Register:

Submarine cable cut lops Terabits off Australia's data bridge | The PPC-1 cable us out of service until March ... if a ship to fix it can be found |

Another of the submarine cables connecting Australia to the world, for data, has broken.

PPC-1, which stretches from Sydney to Guam and has 1.92 terabits per second capacity, is out of service until at least March 7.

TPG's announcement says the fault is around 4,590 km from the cable's Guam landing, which means it's around 3,000 metres below the surface.

The fault notice says engineers first logged a report that "alarms indicated that a submarine line card had lost its payload", and the company is trying to establish when a repair ship can be dispatched to the location.

In the meantime, traffic is using alternate routes including the Australia-Japan Cable and Southern Cross.

Last year, the SeaMeWe-3 cable which runs from Perth to Asia via Indonesia suffered multiple outages.

The situation is complicated by the Basslink cable outage. As Vulture South reported last week, a repairing the electrical cable connecting Tasmania to the mainland is going to necessitate a visit by cable repair ship the Ile de Re, because Basslink's communication fibre is going to be cut during the operation.

The Ile de Re would be the default repair ship for PPC-1, so there's likely to be a lot of messages flying around working out whether it can fit a trip to Guam into its schedule, or if another ship has to be called in.

The cut also represents a challenge to PPC-1's owner, TPG, as the telco and ISP has recently offered vastly increased download allowances for its customers. That's the kind of thing an integrated carrier that owns a submarine cable can do. TPG's investors will be hoping its also invested in lots of local caching and contracts for backup bandwidth, as if it hasn't the cost of landing data promised to users will soon stack up.

Источник: http://www.theregister.co.uk/2016/02/07/cable_cut_lops_terabits_off_australias_net_connectivity/

Posted in Misc.

rev="post-1612" No comments

By Admin – 08.02.2016