Skip to content


О пользе irqbalance

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

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


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

  1. # service irqbalance start
  2. Starting irqbalance: irqbalance: symbol lookup error: irqbalance: undefined symbol: g_list_free_full
  3.                                                            [FAILED]

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

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

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

  1. # service irqbalance start
  2. Starting irqbalance:                                       [  OK  ]

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

  1. # cat /proc/interrupts | grep -E "CPU|em1" | sed -r "s/ +/  /g" | sed -r "s/CPU//g"
  2.                  0  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23
  3.   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
  4.   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
  5.   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
  6.   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
  7.   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-а пропадает:

  1. top - 16:39:53 up 79 days,  2:41, 18 users,  load average: 40.03, 35.48, 27.67
  2. Tasks: 446 total,   9 running, 437 sleeping,   0 stopped,   0 zombie
  3. 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
  4. Mem:  65920820k total, 40078188k used, 25842632k free,   261184k buffers
  5. Swap:  8290296k total,        0k used,  8290296k free, 11422368k cached
  6.  
  7.   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  8. 16763 catalina  20   0 32.6g  13g  13m S 1452.3 21.0  36642:46 java
  9. 15460 haproxy   20   0  702m 627m 2276 R 60.3  1.0   9:55.44 haproxy
  10. 15464 haproxy   20   0  758m 679m 2276 R 59.4  1.1  10:26.81 haproxy
  11. 15459 haproxy   20   0  729m 653m 2272 R 58.0  1.0   9:53.93 haproxy
  12. 15463 haproxy   20   0  729m 652m 2268 R 58.0  1.0  10:23.88 haproxy
  13. 15462 haproxy   20   0  725m 649m 2308 R 57.4  1.0  10:13.97 haproxy
  14. 15466 haproxy   20   0  771m 693m 2296 R 54.8  1.1  10:33.94 haproxy
  15. 15468 haproxy   20   0  722m 645m 2308 R 51.8  1.0  10:26.30 haproxy
  16. 15461 haproxy   20   0  737m 661m 2308 R 51.5  1.0  10:05.91 haproxy
  17. 26785 avz       20   0 15296 1600  988 R  1.0  0.0   0:00.07 top
  18. 15539 root      20   0 15296 1624  988 S  0.7  0.0   0:13.21 top
  19.    73 root      20   0     0    0    0 S  0.3  0.0   6:55.14 ksoftirqd/17

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

Размещено в категории *nix. Теги: .

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

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

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

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

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

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

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

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

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

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

Размещено в категории *nix, Howto.

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

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

  1. 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
  2. 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:

  1. frontend ssl-fe
  2.   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

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

Размещено в категории *nix.

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

Невесёлые новости пришли к нам из солнечной Австралии. У тамошних Интернет-пользователей внешние каналы временно потеряли в пропускной способности около двух терабит/сек из-за обрыва кабеля 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/

Размещено в категории Разное.

Страница 4 из 50123456789101112...Последняя »