Не могу разобраться в чем проблема. Система стоит на довольно таки бодрой машинке, занимается мониторингом сети (nagios, cacti), работает sntp сервером для свичей d-link, а также запущен http файл сервер, вот на нем и ощущаются проблемы. Пока сервер был подключен через домашний soho роутер, проблем не было, кроме как зависания роутера. В конце концов, решились некоторые проблемы и сервер был подключен напрямую, через DGS-3100 в сетевую карту.
Суть проблемы - нет скорости, при копировании с сервера скорость доходит до 40-50 мб/с, при загрузке на сервер скорость вообще не поднимается выше 30 кб/с.
Что делал - после исследования форума пришел к выводу, что виноват драйвер
product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller - стоял коробочный driver=r8169, заменил на driver=r8168 результата ноль.
При чем когда гонял дома в локалке (специально забирал домой для разбора), скорость скачивания/загрузки примерно 540/140 мб/с соответственно. Поставил на место а проблема не ушла. При чем при закачке на сервер - сеть буквально придавливает (при скорости закачки, напомню 30 кб/с) с тормоза заметны - увеличивается пинг до свичей в сети, примерно раз в 100, в общем по telnet отклик тормозит при управлении свичами.
Отключил даже fail2ban - изменений нет.
ukass@websrw:~$ sudo iptables-save
# Generated by iptables-save v1.4.12 on Sun Jan 19 17:11:34 2014
*filter
:INPUT ACCEPT [353012:71479177]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [173285:2783738389]
COMMIT
# Completed on Sun Jan 19 17:11:34 2014Ping до свича до и во время копирования на сервер (копирую по ssh)
bukass@websrw:~$ ping 172.16.10.10
PING 172.16.10.10 (172.16.10.10) 56(84) bytes of data.
64 bytes from 172.16.10.10: icmp_req=1 ttl=29 time=1.68 ms
64 bytes from 172.16.10.10: icmp_req=2 ttl=29 time=1.71 ms
64 bytes from 172.16.10.10: icmp_req=3 ttl=29 time=1.72 ms
64 bytes from 172.16.10.10: icmp_req=4 ttl=29 time=1.73 ms
64 bytes from 172.16.10.10: icmp_req=5 ttl=29 time=1.70 ms
64 bytes from 172.16.10.10: icmp_req=6 ttl=29 time=1.83 ms
64 bytes from 172.16.10.10: icmp_req=7 ttl=29 time=1.76 ms
64 bytes from 172.16.10.10: icmp_req=8 ttl=29 time=1.72 ms
64 bytes from 172.16.10.10: icmp_req=9 ttl=29 time=1.75 ms
64 bytes from 172.16.10.10: icmp_req=10 ttl=29 time=1.73 ms
64 bytes from 172.16.10.10: icmp_req=11 ttl=29 time=1.73 ms
64 bytes from 172.16.10.10: icmp_req=12 ttl=29 time=1.83 ms
64 bytes from 172.16.10.10: icmp_req=13 ttl=29 time=1.67 ms
^C
--- 172.16.10.10 ping statistics ---
13 packets transmitted, 13 received, 0% packet loss, time 12018ms
rtt min/avg/max/mdev = 1.678/1.741/1.839/0.064 ms
bukass@websrw:~$ ping 172.16.10.10
PING 172.16.10.10 (172.16.10.10) 56(84) bytes of data.
64 bytes from 172.16.10.10: icmp_req=1 ttl=29 time=105 ms
64 bytes from 172.16.10.10: icmp_req=2 ttl=29 time=62.7 ms
64 bytes from 172.16.10.10: icmp_req=3 ttl=29 time=67.2 ms
64 bytes from 172.16.10.10: icmp_req=4 ttl=29 time=73.7 ms
64 bytes from 172.16.10.10: icmp_req=5 ttl=29 time=80.4 ms
64 bytes from 172.16.10.10: icmp_req=6 ttl=29 time=85.2 ms
64 bytes from 172.16.10.10: icmp_req=7 ttl=29 time=92.7 ms
64 bytes from 172.16.10.10: icmp_req=8 ttl=29 time=98.7 ms
64 bytes from 172.16.10.10: icmp_req=9 ttl=29 time=55.7 ms
64 bytes from 172.16.10.10: icmp_req=10 ttl=29 time=77.2 ms
64 bytes from 172.16.10.10: icmp_req=11 ttl=29 time=82.2 ms
64 bytes from 172.16.10.10: icmp_req=12 ttl=29 time=90.2 ms
64 bytes from 172.16.10.10: icmp_req=13 ttl=29 time=95.2 ms
64 bytes from 172.16.10.10: icmp_req=14 ttl=29 time=52.7 ms
64 bytes from 172.16.10.10: icmp_req=15 ttl=29 time=60.2 ms
64 bytes from 172.16.10.10: icmp_req=16 ttl=29 time=65.2 ms
64 bytes from 172.16.10.10: icmp_req=17 ttl=29 time=70.2 ms
64 bytes from 172.16.10.10: icmp_req=18 ttl=29 time=75.2 ms
^C
--- 172.16.10.10 ping statistics ---
18 packets transmitted, 18 received, 0% packet loss, time 17024ms
Пользователь решил продолжить мысль 19 Января 2014, 16:18:20:
bukass@websrw:~$ ip r
default via 10.0.2.1 dev eth1 metric 100
10.0.2.0/24 dev eth1 proto kernel scope link src 10.0.2.20
bukass@websrw:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 90:2b:34:63:4b:ec brd ff:ff:ff:ff:ff:ff
inet 10.0.2.20/24 brd 10.0.2.255 scope global eth1
inet6 fe80::922b:34ff:fe63:4bec/64 scope link
valid_lft forever preferred_lft forever
bukass@websrw:~$ ifconfig -a
eth1 Link encap:Ethernet HWaddr 90:2b:34:63:4b:ec
inet addr:10.0.2.20 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::922b:34ff:fe63:4bec/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:959934 errors:0 dropped:0 overruns:0 frame:0
TX packets:8923287 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:185626458 (185.6 MB) TX bytes:6057590330 (6.0 GB)
Interrupt:41 Base address:0x8000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:8408 errors:0 dropped:0 overruns:0 frame:0
TX packets:8408 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1026867 (1.0 MB) TX bytes:1026867 (1.0 MB)
Пользователь решил продолжить мысль 19 Января 2014, 17:30:00:
Заливаю файл по ftp, обманул 30 килобайт/сек скорость
IPTraf
┌ Packet Distribution by Size ────────────────────────────────────────────────────────────────────────────┐
│ │
│ Packet size brackets for interface eth1 │
│ │
│ │
│ Packet Size (bytes) Count Packet Size (bytes) Count │
│ 1 to 75: 6200 751 to 825: 0 │
│ 76 to 150: 174 826 to 900: 0 │
│ 151 to 225: 2889 901 to 975: 0 │
│ 226 to 300: 28 976 to 1050: 1 │
│ 301 to 375: 5 1051 to 1125: 0 │
│ 376 to 450: 15 1126 to 1200: 0 │
│ 451 to 525: 15 1201 to 1275: 15 │
│ 526 to 600: 29 1276 to 1350: 1 │
│ 601 to 675: 28 1351 to 1425: 0 │
│ 676 to 750: 30 1426 to 1500+: 5686 │
│ │
│ │
│ Interface MTU is 1500 bytes, not counting the data-link header │
│ Maximum packet size is the MTU plus the data-link header length │
│ Packet size computations include data-link headers, if any
IPTraf
┌ Statistics for eth1 ────────────────────────────────────────────────────────────────────────────────────┐
│ │
│ Total Total Incoming Incoming Outgoing Outgoing │
│ Packets Bytes Packets Bytes Packets Bytes │
│ Total: 43780 29233464 25970 25552593 17810 3680871 │
│ IP: 43780 28620496 25970 25188965 17810 3431531 │
│ TCP: 43558 28602054 25859 25179637 17699 3422417 │
│ UDP: 139 10980 72 6052 67 4928 │
│ ICMP: 83 7462 39 3276 44 4186 │
│ Other IP: 0 0 0 0 0 0 │
│ Non-IP: 0 0 0 0 0 0 │
│ │
│ │
│ Total rates: 287,4 kbits/sec Broadcast packets: 0 │
│ 55,2 packets/sec Broadcast bytes: 0 │
│ │
│ Incoming rates: 253,5 kbits/sec │
│ 32,8 packets/sec │
│ IP checksum errors: 0 │
│ Outgoing rates: 33,9 kbits/sec │
│ 22,4 packets/sec Забыл сказать - скорость соединения с интернет не ограничена. Есть мысли?
Пользователь решил продолжить мысль 19 Января 2014, 18:51:01:
Удалил все политики с интерфейса (шлюза), все дефолтные шейперы то же, проверил, нет результата, вернул все обратно.
Попробовал провести такой тест - ??
bukass@websrw:~$ wget http://mirror.yandex.ru/ubuntu-releases/12.04.3/ubuntu-12.04.3-desktop-amd64.iso -O /dev/null
--2014-01-19 21:46:47-- http://mirror.yandex.ru/ubuntu-releases/12.04.3/ubuntu-12.04.3-desktop-amd64.iso
Resolving mirror.yandex.ru (mirror.yandex.ru)... 213.180.204.183, 2a02:6b8:0:201::1
Connecting to mirror.yandex.ru (mirror.yandex.ru)|213.180.204.183|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 742391808 (708M) [application/octet-stream]
Saving to: `/dev/null'
8% [====> ] 63 104 086 12,6M/s eta 2m 40s ^C
Пользователь решил продолжить мысль 19 Января 2014, 19:39:44:
Победил
bukreev@bukreev-comp:~/Загрузки$ scp 1G bukass@176.62.86.31:/home/bukass/
bukass@176.62.86.31's password:
1G 100% 1024MB 11.1MB/s 01:32
bukreev@bukreev-comp:~/Загрузки$ scp bukass@176.62.86.31:/home/bukass/1G 1GB1
bukass@176.62.86.31's password:
1G 100% 1024MB 14.8MB/s 01:09 По ftp и http так же все ровно.
Помогло
root@websrw:~# killall -u bukass #Убил все процессы запущенные юзером bukass
Подвисла ssh сессия (Даже, скорее всего, не сессия, а сессии, коих запускаю не меряно без корректного выхода, закрыв крышку ноута).
Вопрос, есть возможность ограничить время жизни сессии?
Тема: Проблема со скоростью соединения ubuntu server 12.04 (Прочитано 629 раз)
