Иногда внутри докера запросы выполняются по несколько секунд, почему так происходит?

Question

[SexyHair]

Запущен контейнер(image- python:3.8). Внутри него по непонятным причинам запросы могут выполняться по несколько секунд (пробовал curl/requests). На самом компьютере, где запущен докер, все нормально. Выполнил несколько тысяч запросов, чтобы исключить случайность. Если выполнять запросы через requests.Session(), то таких задержек практически нет. На скрине, левый терминал - докер контейнер, правый - системный. Сначала выполняется 25 запросов к гуглу через requests.Session, потом 25 запросов через requests. Видно что в контейнере через requests некоторые запросы выполняются по 3 секунды, в системе же даже через requests запросы выполняются адекватно быстро, без задержек в 3 секунды. Почему так происходит?

Comments

[Badbuka]

Снимите tcpdump, думаю дело в mtu, но это не точно. Покажите настройки сети докера и хоста и дамп

[SexyHair]

Badbuka, Вот tcpdump, вот настройки сети докера. А настройки хоста какие именно нужны?

[Badbuka]

В Docker-контейнере значение MTU должно быть 1400.
Установить его можно одним из способов:
Способ 1.
На Docker-хосте в файле /etc/docker/daemon.json указать "mtu": 1400:

{

"mtu": 1400

}

Далее необходимо перезапустить Docker командой:

sudo service docker restart

Способ 2:

У контейнера в docker-compose.yml прописать:

networks:
frontend:
driver: "bridge"
driver_opts:
com.docker.network.driver.mtu: 1400

P.s. у вас судя по дампу мсс 1430, а у докера по умолчанию mtu 1500 из за этого происходит ретрансмиссия и фрагментация и соответственно response time 3 сек.

[SexyHair]

Badbuka, Извиняюсь, а как понять что я сделал все правильно?) Вроде прописал в docker-compose то, что вы написали, и указал у приложения networks: -frontend. Но не получилось что-то)

[Badbuka]

Попробуйте уменьшить до 1380, сделали все правильно, в настройках стоит mtu 1400

[Badbuka]

И еще если можно покажите вывод
ping -s 1352 yandex.ru из контейнера

[SexyHair]

Badbuka, попробовал на 1380, 1360. Пока не получается. Буду по 20 уменьшать и тестить

[SexyHair]

Badbuka, Это уже с mtu 1360

[shurshur]

MTU тут ни при чём, докеру хватает такого же MTU, как на выходном интерфейсе хоста, а там скорее всего обычные 1500. Более того, при нехватке MTU были бы не редкие задержки, а частые фрагментации пакетов в любых коннектах вне зависимости от использования/неиспользования session.

Скорее проблема в DNS. Если попробовать тестовые запросы делать по IP - проблема уйдёт?

В докере DNS работает так: есть собственный ресолвер, который ресолвит контейнеры по именам, а весь остальной трафик пересылает в штатные DNS, указанные в /etc/resolv.conf, либо в явно указанные в конфигурации контейнера. Если, например, с каким-то из вышестоящих DNS бывают проблемы, когда на него попадаешь, то таймауты вполне объяснимы.

[SexyHair]

shurshur, Да, видимо вы правы. Если указывать голый IP, то задержек нет, как решить такую проблему, не подскажите?

[shurshur]

SexyHair, я бы проверил что все указанные в resolv.conf (или в resolved) DNS-сервера нормально работают.

Система использует /etc/resolv.conf. Если там указан 127.0.0.53 - это systemd-resolved, нужно смотреть реальные DNS в выводе команды systemd-resolve --status. Ещё можно переопределить DNS в конфигурации докера, в том числе через параметры docker run или в файле для docker-compose, но это вряд ли.

Можно попробовать оставлять один-единственный DNS в /etc/resolv.conf и проверять скриптом на хосте, так выявить, действительно ли конкретный DNS тормозит (а может и вообще не работает?).

[SexyHair]

shurshur, В системе в /etc/resolv.conf только один днс и указан, как проверить что он корректно работает? Вот resolv.conf докера и системы, а вот systemd-resolve --status

[shurshur]

127.0.0.11 - это docker resolver, DNS в контейнере, я уже говорил, что он большинство запросов проксирует в следующий DNS
127.0.0.53 - это systemd resolved

В выводе systemd-resolve написано, что реальный DNS - 192.168.1.1. Если это дома, то скорее всего DNS в роутере, такой тоже может работать как-нибудь странно.

Предлагаю для сравнения создать контейнер с DNS например от гугла (docker run --dns 8.8.8.8) и проверить, будет ли разница. В общем, попытаться как-то локализовать источник.

[SexyHair]

shurshur, Да, вы оказались правы. при --dns=8.8.8.8 все здорово работает. Получается нужно просто сменить адрес DNS? Через docker-compose это возможно сделать?
app:
dns:
- 8.8.8.8
Игнорируется

[shurshur]

SexyHair, он не игнорируется, просто используется вместо системного как вышестоящий ресолвер.

Тут нюанс в том, что докер позволяет переопределить DNS только в дефолтной сетке (bridge docker0). В остальных эта опция означает DNS-сервер, в который docker resolver пересылает запросы, причём этот resolver нельзя убрать. docker-compose на проекст создаёт собственную отдельную сеть.

[SexyHair]

shurshur, Я написал в docker-compose network_mode: "bridge". Вроде работает, такое решение приемлемо?

[shurshur]

SexyHair, он при этом должен создать отдельную сеть с именем типа ИМЯПРОЕКТА_default (см. в docker network ls). Но если не переопределить DNS, будет использоваться тот же, что и у всей системы, но через собственный resolver в качестве прослойки.

[SexyHair]

shurshur, Спасибо вам большое, золотой человек. К сожалению, как я понял, я не могу отметить комментарий "решением". Можете оставить "Ответ на вопрос", я отмечу решением)

[SexyHair]

shurshur, Так и не получилось соединить базу данных с приложением через network :D Но это уже отдельный вопрос, спасибо еще раз)

Answer 1

[shurshur]

Судя по симптомам, в докере тормозит DNS. При использовании Session IP проверяется один раз и потому проблем нет, а без сессий IP запрашивается при каждом запросе.