LINUX.ORG.RU

История изменений

Исправление vel, (текущая версия) :

А если tcpdump запустить и подождать ответ с задержкой ?

Так на что глядеть-то там?

Понять на какой стади возникает пауза и нет ли в этот момент попытки что-то отрезолвить.

Я пока не совсем понял про задержки. Они возникают при определенных запросах или в какой-то случайный момент[ы] времени ?

Проблема со шлюзом может дать задержку при первых запросах после старта контейнера, да и если на мосте fd не 0, то при старте тоже будут задержки, но потом все должно работать без задержек.

На хосте стоит nginx, который проксирует заданный виртхост на внутренний адрес контейнера

Вопрос - с хоста на контейнер соединение устанавливается сразу, а ответ задерживается или с хоста долго не могут сконнектиться с контейнером? proxy_connect_timeout как раз 60 c.

Если коннект в контейнер приходит с адреса из непосредственно подключенной сети, то отсутствие dgw на работу не будет влиять.

Если таймауты выкрутить на минимум, то будет видно в какой момент наступает пауза.

У меня почему-то сложилось предвзятое отношение к ядрам 3.7-3.9. Там очень много меняли и ломали. Я практически уверен, что если заменить это 3.8 на 3.4.последнее или 3.12.14, то хуже точно не станет. В новых ядрах активно чинили cgroups и разные namespaces.

Исходная версия vel, :

А если tcpdump запустить и подождать ответ с задержкой ?

Так на что глядеть-то там?

Понять на какой стади возникает пауза и нет ли в этот момент попытки что-то отрезолвить.

Я пока не совсем понял про задержки. Они возникают при определенных запросах или в какой-то случайный момент[ы] времени ?

Проблема со шлюзом может дать задержку при первых запросах после старта контейнера, да и если на мосте fd не 0, то при старте тоже будут задержки, но потом все должно работать без задержек.

На хосте стоит nginx, который проксирует заданный виртхост на внутренний адрес контейнера

Вопрос - с хоста на контейнер соединение устанавливается сразу, а ответ задерживается или с хоста долго не могут сконнектиться с контейнером? proxy_connect_timeout как раз 60 c.

Если коннект в контейнер приходит с адреса из непосредственно подключенной сети, то отсутствие dgw на работу не будет влиять.

Если таймауты выкрутить на минимум, то будет видно в какой момент наступает пауза.