OpenVZ Forum


Home » International » Russian » сетевые странности
сетевые странности [message #31517] Wed, 02 July 2008 20:47 Go to next message
umask is currently offline  umask
Messages: 23
Registered: December 2007
Junior Member
доброе время суток!

Имеем.
1. ОС Centos 5 (up2date) на хост ноде:
cat /etc/redhat-release
CentOS release 5.2 (Final)

2. uname -a (на хост ноде)
Linux host01.test.ru 2.6.18-53.1.19.el5.028stab053.14 #1 SMP Thu May 8 20:43:27 MSD 2008 i686 i686 i386 GNU/Linux

3. VPS 1100

ONBOOT="yes"

# UBC parameters (in form of barrier:limit)
KMEMSIZE="2147483647:2147483647"
LOCKEDPAGES="2147483647:2147483647"
PRIVVMPAGES="2147483647:2147483647"
SHMPAGES="2147483647:2147483647"
NUMPROC="2147483647:2147483647"
PHYSPAGES="2147483647:2147483647"
VMGUARPAGES="2147483647:2147483647"
OOMGUARPAGES="2147483647:2147483647"
NUMTCPSOCK="2147483647:2147483647"
NUMFLOCK="2147483647:2147483647"
NUMPTY="2147483647:2147483647"
NUMSIGINFO="2147483647:2147483647"
TCPSNDBUF="2147483647:2147483647"
TCPRCVBUF="2147483647:2147483647"
OTHERSOCKBUF="2147483647:2147483647"
DGRAMRCVBUF="2147483647:2147483647"
NUMOTHERSOCK="2147483647:2147483647"
DCACHESIZE="2147483647:2147483647"
NUMFILE="2147483647:2147483647"
AVNUMPROC="180:180"
NUMIPTENT="2147483647:2147483647"

# Disk quota parameters (in form of softlimit:hardlimit)
DISKSPACE="100000000:120000000"
DISKINODES="10000000:15000000"
QUOTATIME="0"

# CPU fair sheduler parameter
CPUUNITS="500000"


IP_ADDRESS="192.168.1.10"
HOSTNAME="a.host01.test.ru"
VE_ROOT="/vz/root/$VEID"
VE_PRIVATE="/vz/private/$VEID"
OSTEMPLATE="centos-5-i386-minimal"
ORIGIN_SAMPLE="vps.basic"
NAMESERVER="192.168.1.1"
SEARCHDOMAIN="testru"
CPULIMIT="1000"

т.е. все лимиты откручены.

4. хост нода либо p4/1gb ram, либо dual xeon/4gb ram - результат один.

5. на хост ноде cat /etc/sysctl.conf
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled. See sysctl(Cool and
# sysctl.conf(5) for more details.

# Controls IP packet forwarding
net.ipv4.ip_forward = 0

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename
# Useful for debugging multi-threaded applications
kernel.core_uses_pid = 1

# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 0

# Controls the maximum size of a message, in bytes
kernel.msgmnb = 65536

# Controls the default maxmimum size of a mesage queue
kernel.msgmax = 65536

# Controls the maximum shared segment size, in bytes
kernel.shmmax = 4294967295

# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 268435456

# On Hardware Node we generally need
# packet forwarding enabled and proxy arp disabled
net.ipv4.ip_forward = 1
net.ipv4.conf.default.proxy_arp = 0
# Enables source route verification
net.ipv4.conf.all.rp_filter = 1
# Enables the magic-sysrq key
kernel.sysrq = 1
# TCP Explict Congestion Notification
#net.ipv4.tcp_ecn = 0
# we do not want all our interfaces to send redirects
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0

# Local port range
net.ipv4.ip_local_port_range = 8192 65535

# Netfilter connection tracking table size
net.ipv4.ip_conntrack_max = 258068

# For servers that receive many connections at the same time,
# the TIME-WAIT sockets for new connections can be reused.
# This is useful in Web servers etc. See also net.ipv4.tcp_tw_recycle.
net.ipv4.tcp_tw_reuse = 1

# Enable fast recycling of TIME-WAIT sockets status
net.ipv4.tcp_tw_recycle = 1

# Tune VM subsystem to use swap only as last resort
vm.swappiness = 1

# Limit of socket listen() backlog, known in userspace as SOMAXCONN.
# Defaults to 128. See also tcp_max_syn_backlog for additional tuning
# for TCP sockets.
net.core.somaxconn = 2048

# The maximum number of queued connection requests which have still not
# received an acknowledgement from the connecting client. If this
# number is exceeded, the kernel will begin dropping requests.
# The default value of 256 is increased to 1024 when the memory present
# in the system is adequate or greater (>= 128Mb), and reduced to 128
# for those systems with very low memory (<= 32Mb). It is recommended
# that if this needs to be increased above 1024, TCP_SYNQ_HSIZE in
# include/net/tcp.h be modified to keep
# TCP_SYNQ_HSIZE*16<=tcp_max_syn_backlog, and the kernel be recompiled.
net.ipv4.tcp_max_syn_backlog = 1024

# Maximum number of packets in the global input queue.
# for 1 GBit links recommended value near 3000
net.core.netdev_max_backlog = 2500

# prevent time wait bucket table overflow
net.ipv4.tcp_max_tw_buckets_ub = 129034
net.ipv4.tcp_max_tw_kmem_fraction = 384

# This sets the max OS receive buffer size for all types of connections.
net.core.rmem_max = 16777216

# This sets the max OS send buffer size for all types of connections.
net.core.wmem_max = 16777216

# This sets the default OS receive buffer size for all types of connections.
net.core.rmem_default = 65535

# This sets the default OS send buffer size for all types of connections.
net.core.wmem_default = 65535

# TCP Autotuning setting. "The tcp_mem variable defines how the TCP stack
# should behave when it comes to memory usage. ... The first value specified
# in the tcp_mem variable tells the kernel the low threshold. Below this
# point, the TCP stack do not bother at all about putting any pressure on the
# memory usage by different TCP sockets. ... The second value tells the
# kernel at which point to start pressuring memory usage down. ... The final
# value tells the kernel how many memory pages it may use maximally.
# If this value is reached, TCP streams and packets start getting dropped
# until we reach a lower memory usage again. This value includes all
# TCP sockets currently in use."
net.ipv4.tcp_mem = 16777216 16777216 16777216


# TCP Autotuning setting. "The first value tells the kernel the minimum
# receive buffer for each TCP connection, and this buffer is always allocated
# to a TCP socket, even under high pressure on the system. ... The second
# value specified tells the kernel the default receive buffer allocated for
# each TCP socket. This value overrides the /proc/sys/net/core/rmem_default
# value used by other protocols. ... The third and last value specified in
# this variable specifies the maximum receive buffer that can be allocated
# for a TCP socket."
net.ipv4.tcp_rmem = 4096 131072 16777216

# TCP Autotuning setting. "This variable takes 3 different values which holds
# information on how much TCP sendbuffer memory space each TCP socket has to
# use. Every TCP socket has this much buffer space to use before the buffer
# is filled up. Each of the three values are used under different conditions.
# ... The first value in this variable tells the minimum TCP send buffer
# space available for a single TCP socket. ... The second value in the variable
# tells us the default buffer space allowed for a single TCP socket to use.
# ... The third value tells the kernel the maximum TCP send buffer space."
net.ipv4.tcp_wmem = 4096 131072 16777216

# This will enusre that immediatly subsequent connections use these values.
net.ipv4.route.flush=1

# RFC 2018 TCP Selective Acknowledgements
net.ipv4.tcp_sack = 0

# RFC 1323 TCP timestamps
net.ipv4.tcp_timestamps = 0

net.ipv4.tcp_sack = 1
net.ipv4.tcp_fack = 1


# Enable TCP behaviour conformant with RFC 1337. When disabled,
# if a RST is received in TIME_WAIT state, we close the socket
# immediately without waiting for the end of the TIME_WAIT period.
net.ipv4.tcp_rfc1337 = 1

6. iptables и на хост ноде, и на VPS отключен (chkconfig iptables off).

7. на VPS стоит nginx 0.6.31.
cat /etc/nginx/nginx.conf
user  nginx nginx;
worker_processes  4;

worker_rlimit_nofile    16384;

error_log  /var/log/nginx/error.log debug;


events {
	worker_connections  16384;
	use epoll;
}

http {
	include       /etc/nginx/mime.types;
	default_type  text/plain;

	log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
			  '"$status" $body_bytes_sent "$http_referer" '
			  '"$http_user_agent" "$http_x_forwarded_for" '
			  '$request_time "$upstream_addr" [$upstream_response_time]';


	log_format compat '$remote_addr - $remote_user [$time_local] "$request" '
			  '"$status" $body_bytes_sent "$http_referer" '
			  '"$http_user_agent" "$http_x_forwarded_for"';

	sendfile       on;
	tcp_nopush     on;
	tcp_nodelay    on;

	client_header_timeout  60;
	client_body_timeout    60;
	send_timeout           30;
	keepalive_timeout  0;

	reset_timedout_connection  on;

        server {
                listen 80 default backlog=16384 rcvbuf=4096 sndbuf=4096 deferred;
                server_name .test.ru;

                error_log  /var/log/nginx/test.ru_error.log debug;
                access_log /var/log/nginx/test.ru_access_main.log main;
    		
	        location /nginx_status {
        	        stub_status on;
	                access_log   off;
	        }

                fastcgi_intercept_errors on;
                proxy_intercept_errors on;

                error_page   500 502 503 504  /50x_empty.html;
                error_page   400 401 402 403 404 405  /50x_empty.html;
                location = /50x_empty.html {
                        root   /home/nginx/htdocs;
                }

                location ~ \.(wml|php)$ {
                        proxy_read_timeout    3;
                        proxy_connect_timeout 3;
                        proxy_pass   http://127.0.0.1:8080;
                        proxy_set_header   X-Real-IP        $remote_addr;
                        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
                        proxy_set_header   Host             $host;
                }
        }
}



вместо nginx использовались так же tomcat и apache httpd-2.2.8/2.2.9.

8. sysctl на VPS по умолчанию.

9. вот такой скрипт на php (так же проверялось на java) - dummy.php
<?
$max = 0;
for($i=0;$i<1000;$i++){
$t = microtime(true);
file_get_contents("http://192.168.1.10/nginx_status");
$t = microtime(true)-$t;
if ($t>$max) $max = $t;
}
echo $max;
?>

10. Отдельное замечения - DNS нигде не используется (проверялось tcpdump многократно).

11. dummy.php запускаем так:
while : ; do php dummy.php ; done | grep -e "[1-9]\.[0-9]"
чтобы видеть когда были ответы длинее секунды.

п.11 выдаёт следующую печальную картину:
3.0010089874268
3.0013828277588
3.001168012619
3.0015661716461
3.0009059906006
3.0006580352783
3.0018539428711
3.0014488697052
3.0009009838104
3.0018038749695


Теперь берём и запускаем nginx/tomcat/httpd на хост ноде и !ВНИМАНИЕ! - проблема не наблюдается!

На всякий случай:
cat /proc/user_beancounters 
Version: 2.5
       uid  resource           held    maxheld    barrier      limit    failcnt
     1100:  kmemsize        4334631    9382841 2147483647 2147483647          0
            lockedpages           0          0 2147483647 2147483647          0
            privvmpages      245588     246632 2147483647 2147483647          0
            shmpages              1          1 2147483647 2147483647          0
            dummy                 0          0          0          0          0
            numproc             118        122 2147483647 2147483647          0
            physpages         34130      34505 2147483647 2147483647          0
            vmguarpages           0          0 2147483647 2147483647          0
            oomguarpages      34130      34505 2147483647 2147483647          0
            numtcpsock           14         16 2147483647 2147483647          0
            numflock              1          2 2147483647 2147483647          0
            numpty                0          1 2147483647 2147483647          0
            numsiginfo            0          2 2147483647 2147483647          0
            tcpsndbuf        125216     125216 2147483647 2147483647          0
            tcprcvbuf        229376     229376 2147483647 2147483647          0
            othersockbuf      11180      13416 2147483647 2147483647          0
            dgramrcvbuf           0          0 2147483647 2147483647          0
            numothersock         11         13 2147483647 2147483647          0
            dcachesize            0          0 2147483647 2147483647          0
            numfile            2082       2158 2147483647 2147483647          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            10         10 2147483647 2147483647          0
        0:  kmemsize        3298695   16916897 2147483647 2147483647          0
            lockedpages        1083       1083 2147483647 2147483647          0
            privvmpages       12459      14060 2147483647 2147483647          0
            shmpages            656        672 2147483647 2147483647          0
            dummy                 0          0 2147483647 2147483647          0
            numproc              73         85 2147483647 2147483647          0
            physpages          4553       4994 2147483647 2147483647          0
            vmguarpages           0          0 2147483647 2147483647          0
            oomguarpages       4553       4994 2147483647 2147483647          0
            numtcpsock            3          3 2147483647 2147483647          0
            numflock              4          5 2147483647 2147483647          0
            numpty                1          1 2147483647 2147483647          0
            numsiginfo            0          2 2147483647 2147483647          0
            tcpsndbuf         35724      35724 2147483647 2147483647          0
            tcprcvbuf         49152      32768 2147483647 2147483647          0
            othersockbuf     154284     161420 2147483647 2147483647          0
            dgramrcvbuf           0       8380 2147483647 2147483647          0
            numothersock        122        126 2147483647 2147483647          0
            dcachesize            0          0 2147483647 2147483647          0
            numfile            1531       1771 2147483647 2147483647          0
            dummy                 0          0 2147483647 2147483647          0
            dummy                 0          0 2147483647 2147483647          0
            dummy                 0          0 2147483647 2147483647          0
            numiptent            10         10 2147483647 2147483647          0




параметры sysctl я как только не пробовал крутить... не однократно устраивал двум испытуемым серверам перезагрузки, /var/log/messages и dmesg пусты - ничего, чтобы говорило о проблеме.

Угробил почти сутки на поиск причины.

Подскажите, куда копать...
Re: сетевые странности [message #31528 is a reply to message #31517] Thu, 03 July 2008 06:52 Go to previous messageGo to next message
umask is currently offline  umask
Messages: 23
Registered: December 2007
Junior Member
забыл уточнить.

всё это подключено к 1Gbit свитчу.
На сетевых интерфейсах ошибок нет:

хост нода:
eth0      Link encap:Ethernet  HWaddr 00:15:17:1E:DF:6D  
          inet addr:192.168.1.1 Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::215:17ff:fe1e:df6d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:316696 errors:0 dropped:0 overruns:0 frame:0
          TX packets:256175 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:23930105 (22.8 MiB)  TX bytes:157922369 (150.6 MiB)
          Base address:0x2000 Memory:48180000-481a0000 

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:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:254038 errors:0 dropped:0 overruns:0 frame:0
          TX packets:254075 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:152950314 (145.8 MiB)  TX bytes:15203174 (14.4 MiB)


сервер с которого генерится нагрузка\запросы:
eth0      Link encap:Ethernet  HWaddr 00:04:23:B3:01:F6  
          inet addr:192.168.1.20  Bcast:192.168.1.255   Mask:255.255.255.0
          inet6 addr: fe80::204:23ff:feb3:1f6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:195583406 errors:0 dropped:0 overruns:0 frame:0
          TX packets:195452910 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1762512072 (1.6 GiB)  TX bytes:2912992402 (2.7 GiB)
          Base address:0xdc00 Memory:fcfc0000-fcfe0000 

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:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:704 (704.0 b)  TX bytes:704 (704.0 b)
Re: сетевые странности [message #31549 is a reply to message #31528] Thu, 03 July 2008 13:37 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Здравствуйте,

пока что дельный совет дать не могу, но хотелось бы высказать несколько замечаний:

1. Правильно ли я понимаю, что с HN время отклика никогда не превышает секунду (можно ли приветси вывод теста как с VE, так и с HN?).
2. Хотелось бы выделить ту подсистему, в которой подозревается проблема (может тормозить сеть, а может процесс nginx внутри VE).
Поэтому хотелось бы иметь какие-нибудь два простенькие тестики на сеть и CPU.
3. В дополнение ко второму пункту
насколько я понял
CPULIMIT="1000" - хорошо, это абсолютный параметр
CPUUNITS="500000" - этот менее наглядный, так как он относительноый, поэтому покажите пожалуйста вывод vzcpucheck с HN, чтобы узнать Power of the HN, и если потребуется, можно поиграться с этим параметром.
И еще, много ли VE "ранятся" на HN?
Спаcибо.
Re: сетевые странности [message #31550 is a reply to message #31549] Thu, 03 July 2008 13:59 Go to previous messageGo to next message
umask is currently offline  umask
Messages: 23
Registered: December 2007
Junior Member
1. с HN всегда время ответа нормальное, меньше 0.1s.

2. Думаю, что виновата та часть сетевой подсистемы, которую правит openvz patch. Сеть не тормозит. Nginx не тормозит, cpu usage вообще не превышает 10%. Пробовали помимо nginx также tomcat и httpd на отдачу статики.

> Поэтому хотелось бы иметь какие-нибудь два простенькие тестики на сеть и CPU.

запускаем httperf на nginx, утсновленный на HW:

./httperf --server 192.168.1.1 --port 80 --uri=/index.html --num-conns 1000000 --rate 15000 --timeout 0.1
httperf --timeout=0.1 --client=0/1 --server=192.168.1.1 --port=80 --uri=/index.html --rate=15000 --send-buffer=4096 --recv-buffer=16384 --num-conns=1000000 --num-calls=1
Maximum connect burst length: 30

Total: connections 1000000 requests 1000000 replies 1000000 test-duration 66.760 s

Connection rate: 14979.0 conn/s (0.1 ms/conn, <=269 concurrent connections)
Connection time [ms]: min 0.5 avg 3.1 max 17.8 median 2.5 stddev 1.9
Connection time [ms]: connect 0.4
Connection length [replies/conn]: 1.000

Request rate: 14979.0 req/s (0.1 ms/req)
Request size [B]: 75.0

Reply rate [replies/s]: min 14972.3 avg 14979.1 max 14987.6 stddev 4.9 (13 samples)
Reply time [ms]: response 2.7 transfer 0.0
Reply size [B]: header 209.0 content 4.0 footer 0.0 (total 213.0)
Reply status: 1xx=0 2xx=1000000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 14.09 system 51.83 (user 21.1% system 77.6% total 98.7%)
Net I/O: 4212.8 KB/s (34.5*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0


3. про CPUUNITS="500000" сказано в man vzctl
       --cpuunits num
           CPU weight for a VE. Argument is positive non-zero number, which passed to and used in kernel fair scheduler.
           The  larger  the  number  is, the more CPU time this VE get. Maximum value is 500000, minimal is 8. Number is
           relative to weights of all the other running VEs. If cpuunits not specified default value 1000 ia used.

           You can set CPU weight for VE0 (hardware node itself) as well (use vzctl  set  0  --cpuunits  num).  Usually,
           OpenVZ initscript (/etc/init.d/vz) takes care of setting this.


поэтому и пол миллиона. Больше просто нельзя поставить даже.
Изначально проблема была даже тогда, когда значение CPULIMIT и CPUUNITS был дефолтными.

На HN запущена ровно одна VPS.
Нагрузки ни на HN, ни на VPS нет никакой, кроме указаной.
Re: сетевые странности [message #31552 is a reply to message #31550] Thu, 03 July 2008 14:16 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
И еще один вопрос
Если запускать ваш php скрипт с HN результат тот же?
Re: сетевые странности [message #31561 is a reply to message #31552] Thu, 03 July 2008 14:49 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
И, совсем не обязательно, но не хотите ли попробовать то же самое проделать с veth?
Re: сетевые странности [message #31564 is a reply to message #31561] Thu, 03 July 2008 15:03 Go to previous messageGo to next message
umask is currently offline  umask
Messages: 23
Registered: December 2007
Junior Member
> И, совсем не обязательно, но не хотите ли попробовать то же самое проделать с veth?

а это может что-то значительно поменять?
Я ни разу с veth не работал, только с venet (которые по умолчанию).

Там сильно разные принципы?
ping (RTT) будет значительно меньше, чем с venet?

> Если запускать ваш php скрипт с HN результат тот же?

сейчас тестирую. Оставлю нагрузку на пару часиков, чтоб наверняка. Но по первым 10 минутам видно, что на запросах извне проблема есть, а при запросах с HN всё ок.

Кстати, про httperf. Если нагрузка идёт на хост-ноду, то всё ок. Если подобную (как выше) нагрузку подать на VPS, то сразу появляется куча таймаутов.
dmesg и /var/log/messages всюду чисты.
Re: сетевые странности [message #31566 is a reply to message #31564] Thu, 03 July 2008 15:26 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Quote:


а это может что-то значительно поменять?



я больше из интереса спросил, хотелось бы, конечно, чтобы все поменялось в лучшую сторону Smile.


Quote:


Там сильно разные принципы?



Если Вы имеете в виду настройку, то не ососбо.
На этой страничке, вроде, все хорошо описано http://wiki.openvz.org/Veth
Короче говоря, вам нужно создать девайс, добавить на него IP внутри VE, проставить некоторые sysctl параметры, и прописать роуты до VE (с venet'ом vzctl делает это автоматически).

Quote:


Но по первым 10 минутам видно, что на запросах извне проблема есть, а при запросах с HN всё ок.


А с HN нет каких либо лимитов на traffic bandwidth?
Re: сетевые странности [message #31574 is a reply to message #31517] Thu, 03 July 2008 18:39 Go to previous messageGo to next message
umask is currently offline  umask
Messages: 23
Registered: December 2007
Junior Member
> Но по первым 10 минутам видно, что на запросах извне проблема есть, а при запросах с HN всё ок.

прошло 2 часа. Ситуация не изменилась.

С HN всё ок, моментальные ответы. С двух других хостов (linux centos 5.2, freebsd6) 3-х секундные ответы по прежнему случаются.

> А с HN нет каких либо лимитов на traffic bandwidth?

нет. Даже iptables отключен везде (и на HN, и в VPS).
ровно 1gbps между серверами через свитч d-link.
Проверял скорость передачи файлов - 124-125 МБ\сек.

Re: сетевые странности [message #31620 is a reply to message #31574] Fri, 04 July 2008 08:22 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Здравствуйте,

Не могли бы вы показать следующую информацию:

1. netstat -s (с HN, изнутри VE и со сторонней ноды)
2. ethtool -S eth0 (со сторонней ноды и с HN)
3. запустите ваш php тестик и в это время запустите tcpdump на стронней машине (на интерфейс eth0), на HN (на eth0 и на venet0) и внутри VE (на venet0) и покажите, пожалуйста, вывод.

P.S. Все-таки, если возможно, не могли бы вы попробовать veth.
Re: сетевые странности [message #31660 is a reply to message #31620] Fri, 04 July 2008 20:34 Go to previous messageGo to next message
umask is currently offline  umask
Messages: 23
Registered: December 2007
Junior Member
Все адреса были вымышлены. Сейчас раскрою.

(1) 217.23.140.131 - IP HN, с которой шёл тест.
(2) 217.23.140.138 - IP HW, на которой запущена VPS с nginx
(3) 212.158.166.207 - IP VPS, где работает nginx.

*1*
netstat -s c (1)
Ip:
    3613925 total packets received
    4 with invalid headers
    134 forwarded
    0 incoming packets discarded
    3613787 incoming packets delivered
    3613790 requests sent out
Icmp:
    2 ICMP messages received
    0 input ICMP message failed.
    ICMP input histogram:
        echo requests: 2
    9 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 3
        time exceeded: 4
        echo replies: 2
Tcp:
    602193 active connections openings
    6 passive connection openings
    1 failed connection attempts
    1 connection resets received
    2 connections established
    3613655 segments received
    3613536 segments send out
    28 segments retransmited
    0 bad segments received.
    10 resets sent
Udp:
    82 packets received
    3 packets to unknown port received.
    0 packet receive errors
    83 packets sent
TcpExt:
    1 resets received for embryonic SYN_RECV sockets
    3 TCP sockets finished time wait in fast timer
    7 delayed acks sent
    81 packets directly queued to recvmsg prequeue.
    24 packets directly received from prequeue
    602278 packets header predicted
    1204446 acknowledgments not containing data received
    602423 predicted acknowledgments
    1 times recovered from packet loss due to SACK data
    10 congestion windows recovered after partial ack
    1 TCP data loss events
    1 fast retransmits
    27 other TCP timeouts
    1 DSACKs sent for old packets
    2 DSACKs received
    1 connections reset due to unexpected data
    1 connections reset due to early user close


netstat -s c (2)
Ip:
    7227192 total packets received
    7226305 forwarded
    0 incoming packets discarded
    854 incoming packets delivered
    7226920 requests sent out
Icmp:
    9 ICMP messages received
    0 input ICMP message failed.
    ICMP input histogram:
        echo requests: 9
    9 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        echo replies: 9
Tcp:
    9 active connections openings
    9 passive connection openings
    0 failed connection attempts
    0 connection resets received
    3 connections established
    798 segments received
    548 segments send out
    9 segments retransmited
    0 bad segments received.
    0 resets sent
Udp:
    77 packets received
    0 packets to unknown port received.
    0 packet receive errors
    79 packets sent
TcpExt:
    10 TCP sockets finished time wait in fast timer
    601948 TCP sockets finished time wait in slow timer
    12 delayed acks sent
    65 packets directly queued to recvmsg prequeue.
    17 packets directly received from prequeue
    179 packets header predicted
    59 acknowledgments not containing data received
    347 predicted acknowledgments
    4 congestion windows recovered after partial ack
    0 TCP data loss events
    8 other TCP timeouts
    2 DSACKs sent for old packets
    5 DSACKs received


netstat -s c (3)
Ip:
    3613147 total packets received
    0 forwarded
    0 incoming packets discarded
    3613147 incoming packets delivered
    3613158 requests sent out
Icmp:
    4 ICMP messages received
    0 input ICMP message failed.
    ICMP input histogram:
        timeout in transit: 4
    4 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 4
Tcp:
    9 active connections openings
    602198 passive connection openings
    4 failed connection attempts
    0 connection resets received
    0 connections established
    3613169 segments received
    3613184 segments send out
    0 segments retransmited
    0 bad segments received.
    0 resets sent
Udp:
    0 packets received
    4 packets to unknown port received.
    0 packet receive errors
    0 packets sent
TcpExt:
    1 delayed acks sent
    602191 packets header predicted
    602191 acknowledgments not containing data received
    0 TCP data loss events


*2*
ethtool -S eth0 с (1)
NIC statistics:
     rx_packets: 3615960
     tx_packets: 3613901
     rx_bytes: 411792822
     tx_bytes: 289840057
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     multicast: 2
     collisions: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 0
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 20
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_long_byte_count: 411792822
     rx_csum_offload_good: 3613986
     rx_csum_offload_errors: 0
     rx_header_split: 0
     alloc_rx_buff_failed: 0


ethtool -S eth0 с (2)
NIC statistics:
     rx_packets: 3616218
     tx_packets: 3613918
     rx_bytes: 290005297
     tx_bytes: 411677781
     rx_broadcast: 2006
     tx_broadcast: 7
     rx_multicast: 2
     tx_multicast: 6
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     multicast: 2
     collisions: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 0
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     tx_restart_queue: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 1
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_long_byte_count: 290005297
     rx_csum_offload_good: 3614184
     rx_csum_offload_errors: 0
     rx_header_split: 0
     alloc_rx_buff_failed: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus: 0


*3*
while : ; do php dummy.php ; echo ; done | grep -e "[1-9]\.[0-9]"
3.0010950565338
3.0016250610352
3.0018901824951
3.00084400177
3.0018458366394
3.0011219978333
3.0014960765839
3.001119852066


т.е. всего 8 раз наблюдались задержки. Это примерно 10-15 минут теста.

http://people.mobiledirect.ru/people/umask/public/ovz_proble ms/

HN_where_test_running.out[.gz] - (1)
problem_HN_eth0.out[.gz] - (2) на eth0
problem_HN_venet0.out[.gz] - (2) на venet0
problem_VPS_venet0.out[.gz] - (3) на venet0

tcpdump запускался так: tcpdump -n -i <interface> > /tmp/file.out 2>&1.

показания netstat и ethtool снимались по окончанию теста.

[Updated on: Fri, 04 July 2008 20:36]

Report message to a moderator

Re: сетевые странности [message #31667 is a reply to message #31660] Sat, 05 July 2008 05:07 Go to previous messageGo to next message
umask is currently offline  umask
Messages: 23
Registered: December 2007
Junior Member
поднял как тут написано http://wiki.openvz.org/Veth на VPS veth.
venet0 на HN и в VPS опустил.

Проблема осталась Sad.
Re: сетевые странности [message #31732 is a reply to message #31517] Tue, 08 July 2008 08:47 Go to previous messageGo to next message
umask is currently offline  umask
Messages: 23
Registered: December 2007
Junior Member
есть ещё какие-либо идеи?
Re: сетевые странности [message #31738 is a reply to message #31732] Tue, 08 July 2008 10:24 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Здравствуйте,

к сожалению, пока никаких.
Я поспрашивал еще у нескольких человек, пока нет ответа. Sad

Скажите, а эти выбросы происходят с какой-либо определенной периодичностью? Можно ли померить временные промежутки между выбросами?
Re: сетевые странности [message #31739 is a reply to message #31738] Tue, 08 July 2008 11:00 Go to previous messageGo to next message
umask is currently offline  umask
Messages: 23
Registered: December 2007
Junior Member
выбросы случаются в случайном порядке со случайными промежутками.

Может быть 3 выброса за 3 секунды. Может быть 5 за 5 секунд (или больше, чем 5 выбросов - скрипт так работает).

Может за 30 секунды не быть ни одного выброса. Иногда их нет 1-2 минуты.
Re: сетевые странности [message #47193 is a reply to message #31517] Fri, 20 July 2012 08:03 Go to previous message
hiddenman is currently offline  hiddenman
Messages: 1
Registered: July 2012
Junior Member
Коллеги, приветствую.

Спасибо за тестирование. Похоже, у нас точно такая же проблема, по крайней мере симптомы похожи.

Сейчас запускаем тестирование сравнения времени ответа в VHN и CT, проверим.

Previous Topic: Память на HN
Next Topic: Нужно ли для каждого vlan свой bridge
Goto Forum:
  


Current Time: Sat Nov 09 14:12:42 GMT 2024

Total time taken to generate the page: 0.04308 seconds