SWARM Дуже низька продуктивність для вхідної мережі із великою кількістю паралельних запитів · Випуск # 35082
Коментарі
Копіювати посилання Цитувати відповідь
відео прокоментував 4 жовтня 2017 р
Опис
Виконання великої кількості паралельних з'єднань проти звичайних Docker і Docker Swarms призводить до 2 абсолютно різних результатів, причому Swarm є найповільнішим на 50x фактор!
Тест можна відтворити (принаймні на моїх віртуальних машинах) легко за допомогою Siege та офіційного образу Nginx, але я насправді відчуваю проблему у виробництві з нашою власною мікросервісною службою HTTP на основі Java. Я не бачу жодного очевидного повідомлення про помилку в журналах Docker або журналах ядра.
Кроки для відтворення випуску:
Запустіть контейнер nginx:
Облога контейнера, і результати хороші, понад 13 тис. Транс/с, а процесор у stresstest01 на 100% використовується процесом nginx.
Тепер давайте спробуємо з Docker Swarm (1 рой вузлів, 1 стек контейнерів)
Після першого запуску результати вже набагато гірші, ніж у звичайного Docker, але після другого - це
просто катастрофа:( Більш того, центральний процесор хоста використовується лише незначно, і лише процесом nginx. Ніяких процесів, пов’язаних з докером (dockerd, cointanerd тощо), здається, не містить CPU.
Опишіть отримані результати:
Хороші виступи з простим Докером.
Дуже погані виступи з включеним Docker Swarm.
Опишіть результати, яких ви очікували:
Подібні вистави для двох ароматів Docker на одній машині
Додаткова інформація, яку ви вважаєте важливою (наприклад, проблема трапляється лише зрідка):
Вихід версії докера:
Виведення інформації про докер:
Додаткові відомості про середовище (AWS, VirtualBox, фізичний тощо):
Це віртуальна машина KVM (під oVirt), але те саме відбувається при використанні фізичної машини.
Текст успішно оновлено, але виявлені такі помилки:
відео прокоментував 4 жовтня 2017 р
Ця проблема є загальним блокатором для мене та для розгортання Swarm у виробництві. Це графік того, як змінювався час відгуку після перемикання компонента в нашій архітектурі з Swarm на звичайний докер на тих самих точних хостах
Думаю, я почну переїжджати в Кубернетес
(зелена лінія - операції/сек, ліва вісь Y)
(коментар скопійовано з №35009, оскільки спочатку я думав, що це та сама проблема)
мавенуго прокоментував 4 жовтня 2017 р
@vide вхід в ройовий режим обробляється IPVS, а з’єднання надсилаються до серверних завдань через мережу входу накладання. Але оскільки це єдиний вузол, зменшення продуктивності не може відбутися через заголовки VXLAN, що використовуються в накладній мережі. Єдиною можливою причиною може бути IPVS, і це може вимагати налаштування продуктивності для вашого випадку.
Ми можемо підтвердити теорію, якщо ви можете змінити файл стека за допомогою додаткового режиму параметрів: хост у розділі портів. Це обійде IPVS і використовуватиме власне відображення портів, як це робить запуск докера. Чи можете ви, будь ласка, підтвердити ?
відео прокоментував 4 жовтня 2017 р
@mavenugo Так, IPVS теж був моїм підозрюваним номер 1, не думав про режим: хост-фокус.
Знову порівняльний аналіз із запропонованими вами налаштуваннями:
Що можна порівняти з результатами звичайного докера.
Отже, яку настройку я можу зробити на IPVS у цьому випадку? Можливо, оновлення ядра? Очевидно, що мені потрібно балансування навантаження IPVS у виробництві:)
мавенуго прокоментував 5 жовтня 2017 р
@vide дякую за підтвердження. Нам слід витратити трохи більше часу на аналіз проблеми, перш ніж розглядати IPVS як джерело проблеми з продуктивністю (хоча я про це згадав у своєму попередньому коментарі:)). Я спробую облоги і зв’яжусь з тобою.
відео прокоментував 6 жовтня 2017 р
@mavenugo Я спробував ще раз на тому самому вікні CentOS з останнім ядром 4.13 (4.13.4-1.el7.elrepo.x86_64), і результати однакові.
Крім того, я спробував встановити Ubuntu 17.04 на своєму ноутбуці, і результати тут теж погані.
відео прокоментував 10 жовтня 2017 р
@mavenugo не могли б ви відтворити його на своєму комп'ютері?
xinfengliu прокоментував 30 жовтня 2017 р
Я можу точно відтворити проблему. Тестування встановлює нове підключення до кожного запиту.
Неактивні зв’язки незабаром накопичувались у ipvs.
Якщо ви не можете дочекатися InActConn до нуля і знову запустити тестування, ви отримаєте навіть поганий результат, як описано вище.
На стороні клієнта повно "SYN_SENT".
Якщо ви хочете обійти цю проблему, встановіть connection = keep-alive у своєму файлі .siegerc (використовуйте siege.config, щоб створити шаблон .siegerc).
мавенуго прокоментовано 2 листопада 2017 р. •
@vide @xinfengliu Я міг відтворити його та звузити до стану Conntracker, що спричинило проблему. Ми бачимо набагато кращу продуктивність, завдяки чому IPVS не використовує conntracker (через --sysctl net.ipv4.vs.conntrack = 0 лише для облогового контейнера).
До речі, прошу також зауважити, що я безпосередньо використовую сервіс VIP. Використання імені служби призводить до впливу на продуктивність, оскільки Siege виконує пошук DNS для кожного запиту, що затримує процес. Використання служби VIP безпосередньо видаляє пошук DNS, і продуктивність набагато краща.
відео прокоментовано 3 листопада 2017 р. •
@mavenugo Добре, так, як мені встановити conntrack віртуального сервера на 0 у режимі Swarm? Відповідно до https://docs.docker.com/compose/compose-file/#not-supported-for-docker-stack-deploy налаштування sysctl не підтримується при розгортанні стека докерів:(
Про це є відкрите питання: moby/libentitlement # 35
відео прокоментовано 3 листопада 2017 р. •
Здається, і ця проблема пов’язана: # 31746
мавенуго прокоментував 3 листопада 2017 р
@vide idk про підтримку розгортання стека докерів. Але чи можете ви, будь ласка, підтвердити, чи запропоноване обхідне рішення працює у випадку розгортання без стека ?
BSWANG прокоментовано 4 листопада 2017 р. •
--sysctl net.ipv4.vs.conntrack = 0 не можна використовувати при вхідній сітці маршрутизації на ingress_sbox. Як ipvs буде робити SNAT після переадресації.
У службі kubenetes-проксі-сервера kubenetes. встановить ці параметри ядра:
https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/ipvs/proxier.go#L88-L91
та net.netfilter.nf_conntrack_buckets, net.netfilter.nf_conntrack_max .
az-z прокоментував 15 грудня 2017 р
я на RHEL7.4 і докер 1.12. Тестування кластера з 2 вузлами за допомогою nginx: останній розгорнуто в режимі затирання. Я можу відтворити результати @vide. Але мій тест трохи відрізняється.
Замість того, щоб запускати облогу як контейнер, я запускаю її ззовні кластера, щоб перевірити завантаження пари контейнерів nginx. Я відчуваю 10-кратна деградація у часі відгуку та пропускній здатності.
проти кластера:
проти самостійного nginx:
це повноцінне блокування для будь-якого подальшого впровадження докерського рою для нас. Яке пропоноване виправлення та терміни щодо цього? спасибі.
EmarMikey прокоментував 9 січня 2018 р. •
Ми зіткнулися з цією ж проблемою із сітчастим балансуванням LVS, у нас дуже низька продуктивність.
На даний момент я працював із конфігурацією режиму хосту, але сподіваюся, це лише тимчасове рішення.
Будь-який план, щоб це виправити?
тест у режимі хоста з ab (лише 1 контейнер):
перевірка в режимі входу з ab:
netstat на клієнті:
Вивід ipvsadm у вхідному просторі імен: