Долгое подключение к хостингу

[venoel]

Здравствуйте.

Есть хостинг, назовем его site1. Периодически, подключение с моего компьютера к хостингу по разным протоколам (http, ftp, ssh) происходит с задержкой приблизительно минуту. Под периодически следует понимать, что с утра например подключение происходит быстро, потом происходит что-то (вероятно кто-то включает свой копьютер) и начинаются задержки с подключением. Проблемное время выглядит так: пытаюсь открыть страницу в браузере(или обратиться к каталогу ftp), задержка в минуту, затем пока пользуюсь - нормально. После какого-то времени простоя пересоединение опять занимает минуту. Вечером - все возвращается в норму.

Проблема наблюдается только на моем ноуте. Ubuntu 16.04, установлена в середине мая. Точно такая же ситуация была и до переустановки на Ubuntu 14.04. Все остальные пользователи сети на такую проблему не жалуются.
На моем компе проблема наблюдается исключительно с site1. Т.е. ко всем остальным ресурсам интернета подключение проходит без задержек.
Соединение с сетью у меня - проводное. В сети есть и беспроводные клиенты.
IP адреса раздаются по DHCP. Принудительно выставлял себе другой IP - проблема не исчезла.


ip addr

(Нажмите, чтобы показать/скрыть)

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 38:ea:a7:dc:df:74 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.128/24 brd 192.168.0.255 scope global dynamic eno1
       valid_lft 56904sec preferred_lft 56904sec
    inet6 fe80::e248:beb2:72e1:d744/64 scope link
       valid_lft forever preferred_lft forever

ifconfig -a

(Нажмите, чтобы показать/скрыть)

eno1      Link encap:Ethernet  HWaddr 38:ea:a7:dc:df:74 
          inet addr:192.168.0.128  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::e248:beb2:72e1:d744/64 Scope:
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Принято пакетов:790774 ошибок передачь:0 пропущено:0 перерасход:0 кадри:0
          TX packets:509563 errors:0 dropped:1 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          Принято байт:655139790 (655,1 MB) Передано байт:66990254 (66,9 MB)

lo        Link encap:Локальная петля (Loopback) 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Хост
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          Принято пакетов:169865 ошибок передачь:0 пропущено:0 перерасход:0 кадри:0
          TX packets:169865 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          Принято байт:48123798 (48,1 MB) Передано байт:48123798 (48,1 MB)

route

(Нажмите, чтобы показать/скрыть)

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    100    0        0 eno1
link-local      *               255.255.0.0     U     1000   0        0 eno1
192.168.0.0     *               255.255.255.0   U     100    0        0 eno1

cat /etc/resolv.conf

(Нажмите, чтобы показать/скрыть)

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1

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


Попытка найти комьютер с таким же ip (вдруг какая-то коллизия) - ни к чему не привела.

В chrome проблему видно вот так. Т.е. минуту чего-то ждем, потом бах, все нужное загружается. Но повторюсь, проблема касается и других протоколов.



Пинг не отличается между нормальным и проблемным временем.
ping  site1

(Нажмите, чтобы показать/скрыть)

PING site1 (5X.2XX.2XX.7X) 56(84) bytes of data.
64 bytes from site1 (5X.2XX.2XX.7X): icmp_seq=1 ttl=54 time=45.8 ms
64 bytes from site1 (5X.2XX.2XX.7X): icmp_seq=2 ttl=54 time=87.2 ms
64 bytes from site1 (5X.2XX.2XX.7X): icmp_seq=3 ttl=54 time=45.8 ms
64 bytes from site1 (5X.2XX.2XX.7X): icmp_seq=4 ttl=54 time=45.7 ms
64 bytes from site1 (5X.2XX.2XX.7X): icmp_seq=5 ttl=54 time=45.9 ms

Пользователь добавил сообщение 07 Июня 2016, 15:42:42:Надо добавить, что в локальной сети Ubuntu у меня одного.

[fisher74]

Предположу что проблема с dns
Попрбуйте снять диагностику во время проявления проблемы и в период нормальной работы

Код: [Выделить]

time nslookup site1
time nslookup site1 8.8.8.8сами поанализируйте и нам покажите

[venoel]

Измерил. Вроде как ничего показательного и подозрительного нет.

Нормальная ситуация	Тормозная ситуация
time nslookup site1 Server:      127.0.1.1 Address:   127.0.1.1#53 Non-authoritative answer: Name:   site1 Address: ***.***.***.*** real   0m0.228s user   0m0.044s sys   0m0.008s	time nslookup site1 Server:      127.0.1.1 Address:   127.0.1.1#53 Non-authoritative answer: Name:   site1 Address: ***.***.***.*** real   0m0.137s user   0m0.028s sys   0m0.004s
time nslookup site1 8.8.8.8 Server:      8.8.8.8 Address:   8.8.8.8#53 Non-authoritative answer: Name:   site1 Address: ***.***.***.*** real   0m0.085s user   0m0.040s sys   0m0.000s	time nslookup site1 8.8.8.8 Server:      8.8.8.8 Address:   8.8.8.8#53 Non-authoritative answer: Name:   site1 Address: ***.***.***.*** real   0m0.072s user   0m0.028s sys   0m0.000s

[fisher74]

а во время проявления проблемы?

[AnrDaemon]

Боюсь, если проблема в DNS, отловить именно "во время" не получится. Ибо запрос уже прошёл, и следующий запрос попадёт в кэшированную запись.
У меня тут .io линки вчера по пол-дня ресолвились.

[fisher74]

Мда, согласен...
Пожалуй этот эксперимент нужно проводить каждый раз перед первой попыткой получить доступ к этому ресурсу.

[victor00000]

Долгое подключение к хостингу

это dhclient долго?

[fisher74]

Читай, в первом сообщении всё чётко расписано.

[victor00000]

что подключение кабеля или автоматич.
клиент

[AnrDaemon]

victor00000, не позорься.
В первом посте всё описано, прочти его, прежде чем постить в топик.

[venoel]

а во время проявления проблемы?

ну вот колонка "тормозная ситуация" это как раз во время проявления проблемы.

[AnrDaemon]

Не "во время", а "после".
Читайте внимательнее.

[venoel]

Мда, согласен...
Пожалуй этот эксперимент нужно проводить каждый раз перед первой попыткой получить доступ к этому ресурсу.

попробую.

Пользователь добавил сообщение 09 Июня 2016, 09:42:25:

Не "во время", а "после".
Читайте внимательнее.

ну я понял.
Мне надо сначала этот замер сделать, а потом пытаться через клиентов(браузер и т.д.) к хостингу обратиться.

[fisher74]

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

Да, правильно поняли: сначала измерение, потом попытка соединения. Скорее всего соединение уже будет быстрым, но вот цифры в диагностике, скорее всего, будут другие.

[venoel]

Прошло 3/4 дня, а "плохая ситуация" не наступает,