Yesterday I was trying to "pkg image-update" for about 3 hours and it
never completed downloading packages.  It was making progress, just
slowly.  I needed to shut down, then restarted the process this
morning.  It spent about 40 minutes creating a plan before continuing
with the download.

In the process of looking into why it was so slow, I noticed a TCP
state that I've not seen before:

# netstat -f inet -P tcp | grep 72.5.123.21
192.168.1.101.58792  72.5.123.21.80       49640      0 49640      0 LAST_ACK
192.168.1.101.53478  72.5.123.21.80       49640      0 49640      0 LAST_ACK
192.168.1.101.53874  72.5.123.21.80       49640      0 49640      0 LAST_ACK
...

# netstat -f inet -P tcp | grep 72.5.123.21 | nawk '{print $NF}' |
sort | uniq -c
  78 LAST_ACK

Are there pkg server or firewall issues that are preventing the
connections from being closed in a timely manner?  I can't help but
think that this is causing significant problems on the server side if
connections take too long to fully close.

A bit earlier, I had about 15 connections in a CLOSE_WAIT state as well.

Snooping the network traffic I can see that HTTP connections are timing out.

# snoop -i /tmp/pkts | grep Timeout
 58   0.00059  72.5.123.21 -> 192.168.1.101 HTTP HTTP/1.1 408 Request Timeout
251   0.00066  72.5.123.21 -> 192.168.1.101 HTTP HTTP/1.1 408 Request Timeout
262   0.00074  72.5.123.21 -> 192.168.1.101 HTTP HTTP/1.1 408 Request Timeout
309   0.00063  72.5.123.21 -> 192.168.1.101 HTTP HTTP/1.1 408 Request Timeout
320   0.00056  72.5.123.21 -> 192.168.1.101 HTTP HTTP/1.1 408 Request Timeout

# snoop -i /tmp/pkts -p 251 -v | grep port
IP:         .... ..0. = not ECN capable transport
TCP:  Source port = 80
TCP:  Destination port = 64359

# TZ=GMT snoop -i /tmp/pkts -t a port 64359
  1 12:01:4.14818 192.168.1.101 -> 72.5.123.21  HTTP C port=64359
  2 12:01:4.21296  72.5.123.21 -> 192.168.1.101 HTTP R port=64359
  3 12:01:4.21302 192.168.1.101 -> 72.5.123.21  HTTP C port=64359
  4 12:01:4.21311 192.168.1.101 -> 72.5.123.21  HTTP POST
/dev/filelist/0 HTTP/1.1
  5 12:01:4.28061  72.5.123.21 -> 192.168.1.101 HTTP R port=64359
  6 12:01:4.28067 192.168.1.101 -> 72.5.123.21  HTTP
File-Name-0=01b4925bc26e9d9ac6a74a4e8dcc05034c2f80f6
  7 12:01:4.34435  72.5.123.21 -> 192.168.1.101 HTTP R port=64359
  8 12:01:4.34501  72.5.123.21 -> 192.168.1.101 HTTP HTTP/1.1 408
Request Timeout
  9 12:01:4.34506 192.168.1.101 -> 72.5.123.21  HTTP C port=64359
 10 12:01:4.34532  72.5.123.21 -> 192.168.1.101 HTTP R port=64359
 11 12:01:4.34535 192.168.1.101 -> 72.5.123.21  HTTP C port=64359
 12 12:01:36.63898 192.168.1.101 -> 72.5.123.21  HTTP C port=64359
 13 12:01:41.27358 192.168.1.101 -> 72.5.123.21  HTTP C port=64359

Notice that it only takes about 60 ms for the Request Timeout (pkt 6
to 8) but takes another 37 seconds to close the connection.

-- 
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to