Re: Problem with Streams someone please help.

From: Bela Lubkin (belal_at_sco.com)
Date: 01/21/05 

Date: 21 Jan 2005 13:57:38 -0500

Alex wrote:

> I am having a problem with streams that keep increasing and increasing
> until we start getting WARNING: allocb failed - NSTRPAGES exceeded and
> eventually the server is locking up. This server worked fine until they
> moved recently to a new physical location (moved the entire operation
> to a new building). There is also 2 backup servers that seem to have
> the streams running away as well so I suspect there is a problem with
> some device or something on the new network. So I'm hoping there is a
> way to track what is spawning streams so we can locate the source of
> the problem. I apologize in advance if I dont provide enough
> information, if that happens please let me know what else you need and
> I will add it to the thread as quickly as possible. Here is some
> information about the system.
>
> SCO_SV doyle1 3.2 5.0.7 i386
> OSS656A: brand(ADM) update (ver 1.0.0a)
> SCO OpenServer Release 5.0.7 Maintenance Pack 1 (ver 1.0.0Bs)
>
> netstat -m
> streams allocation:
> config alloc free total max fail
...
> class 5, 1024 bytes 36 0 36 165797 35 0
> class 6, 2048 bytes 7650 7642 8 44530277 7649 0
> class 7, 4096 bytes 1010 1000 10 1016489 1010 0
> class 8, 8192 bytes 8 0 8 381996 8 0
...

You have a lot of 4K and especially 2K buffers allocated. Those are
likely sizes for an ethernet driver to use for packets being received
over the net.

Run a shell script that continuously records `netstat -m` output:

  while :; do
    date
    netstat -m
    sleep 1 # to reduce the burden somewhat
  done > netstat-m.log

Meanwhile, put a packet sniffer on the LAN, tell it to capture
everything being sent to doyle1's IP address. Try to make sure the
sniffer and doyle1 agree closely about the time (within a second or
better). Then run the sniff for long enough to observe the 2K buffers
rising significantly, according to the `netstat -m` log.

You should be able to identify specific times when buffers were
consumed. Look at the corresponding times in the sniffer log: is there
a particular kind of incoming packet that seems to be causing this?

>Bela<

Relevant Pages

  • Re: Communication problem in UDP
    ... Ok for the possibility to the sniffer to lost packet. ... I cannot change the communication btw client and server, ... TAG to the packet transmited by the server. ...
    (comp.dcom.sys.cisco)
  • Re: MiniportSendPackets
    ... I'm modifying the passthru sample so stuff with ... I create the same buffers as in orginal ... then copy data into my packet. ... After I send a bigger packet, server ...
    (microsoft.public.development.device.drivers)
  • Packet cap diff... for classic dhcp over winxp s/w bridge prob.
    ... the server simultaneously. ... DHCP Discover - Transaction ID 0xe5448fbb ... Time delta from previous packet: ... Time since reference or first frame: ...
    (comp.os.linux.networking)
  • Interesting TCP behaviour with large sends/small buffers
    ... The server, upon connection, sends a configurable number of bytes to ... I set the client's receive buffer size to 1MBps, ... packet before sending the next packet. ... ACK, according to the delayed ACK algorithm - 50KB bytes means 34 MSS- ...
    (microsoft.public.win32.programmer.networks)
  • Re: How to terminate a socket in CLOSE_WAIT state
    ... FTP Server fixed for certain FTP clients who use both passive ... This was causing a PASSIVE opened socket to be left ... but instead expect the "half close" from the receiver. ... this sends a TCP/IP FIN packet to the ...
    (microsoft.public.win32.programmer.kernel)