No memory for streams (NSTRPAGES) - SCO

This is a discussion on No memory for streams (NSTRPAGES) - SCO ; so, today, genius administrator 'somehow' unplugs the firewall (on a separate box), plus, 'perhaps,' some switches. immediately, all the telnet sessions to the SCO 506a box just halt. one by one, they drop dead. console displays "No memory for streams ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: No memory for streams (NSTRPAGES)

  1. No memory for streams (NSTRPAGES)

    so, today, genius administrator 'somehow' unplugs the
    firewall (on a separate box), plus, 'perhaps,' some
    switches.

    immediately, all the telnet sessions to the SCO 506a box
    just halt. one by one, they drop dead.

    console displays "No memory for streams (NSTRPAGES)"
    over and over. otherwise unresponsive. i mentally debate
    powering down the system, then i get a brainstorm, and unplug
    the server's network jack. immediately, console comes back to
    life. plug it back in, ppl can telnet again. woot.

    netstat -m has two funny rows:
    config alloc free total max fail

    class 1, 64 bytes 576 41 535 -701344641 562 0
    (i assume that a counter overflowed) and
    class 6, 2048 bytes 1886 597 1289 1213818877 1886 10734386

    (spacing slightly adjusted).

    1) anyone care to toss a conjecture what the heck happened?

    2) do I need to do anything now for this box?

    I can't recall ever seeing this message before on this box.

    thanks!

    --
    _________________________________________
    Nachman Yaakov Ziskind, FSPA, LLM awacs@ziskind.us
    Attorney and Counselor-at-Law http://ziskind.us
    Economic Group Pension Services http://egps.com
    Actuaries and Employee Benefit Consultants

  2. Re: No memory for streams (NSTRPAGES)

    anyone?

    N. Yaakov Ziskind wrote (on Tue, Apr 01, 2008 at 01:20:46PM -0400):
    > so, today, genius administrator 'somehow' unplugs the
    > firewall (on a separate box), plus, 'perhaps,' some
    > switches.
    >
    > immediately, all the telnet sessions to the SCO 506a box
    > just halt. one by one, they drop dead.
    >
    > console displays "No memory for streams (NSTRPAGES)"
    > over and over. otherwise unresponsive. i mentally debate
    > powering down the system, then i get a brainstorm, and unplug
    > the server's network jack. immediately, console comes back to
    > life. plug it back in, ppl can telnet again. woot.
    >
    > netstat -m has two funny rows:
    > config alloc free total max fail
    >
    > class 1, 64 bytes 576 41 535 -701344641 562 0
    > (i assume that a counter overflowed) and
    > class 6, 2048 bytes 1886 597 1289 1213818877 1886 10734386
    >
    > (spacing slightly adjusted).
    >
    > 1) anyone care to toss a conjecture what the heck happened?
    >
    > 2) do I need to do anything now for this box?
    >
    > I can't recall ever seeing this message before on this box.
    >
    > thanks!


    --
    _________________________________________
    Nachman Yaakov Ziskind, FSPA, LLM awacs@ziskind.us
    Attorney and Counselor-at-Law http://ziskind.us
    Economic Group Pension Services http://egps.com
    Actuaries and Employee Benefit Consultants

  3. Re: No memory for streams (NSTRPAGES)

    On 1 Apr, 18:20, "N. Yaakov Ziskind" wrote:
    > so, today, genius administrator 'somehow' unplugs the
    > firewall (on a separate box), plus, 'perhaps,' some
    > switches.
    >
    > immediately, all the telnet sessions to the SCO 506a box
    > just halt. one by one, they drop dead.
    >
    > console displays "No memory for streams (NSTRPAGES)"
    > over and over. otherwise unresponsive. i mentally debate
    > powering down the system, then i get a brainstorm, and unplug
    > the server's network jack. immediately, console comes back to
    > life. plug it back in, ppl can telnet again. woot.
    >
    > netstat -m has two funny rows:
    > config alloc free total max fail
    >
    > class 1, 64 bytes 576 41 535 -701344641 562 0
    > (i assume that a counter overflowed) and
    > class 6, 2048 bytes 1886 597 1289 1213818877 1886 10734386
    >
    > (spacing slightly adjusted).
    >
    > 1) anyone care to toss a conjecture what the heck happened?
    >
    > 2) do I need to do anything now for this box?
    >
    > I can't recall ever seeing this message before on this box.
    >
    > thanks!
    >
    > --
    > _________________________________________
    > Nachman Yaakov Ziskind, FSPA, LLM aw...@ziskind.us
    > Attorney and Counselor-at-Law http://ziskind.us
    > Economic Group Pension Services http://egps.com
    > Actuaries and Employee Benefit Consultants


    I would guess that something that is either connecting to or
    connecting from the OpenServer 5.0.6 box is not happy and
    consuming streams.

    As a start I would suggest reading through:

    http://www.sco.com/ta/116684

    to see if you can pinpoint what is causing the streams leak.

    John

  4. Re: No memory for streams (NSTRPAGES)

    I am having a similar problem with a OSR5.0.7 system (MP3) with a Intel
    PR/100B /PRO/100+ Adaptor. The NIC driver (ver 5.0.7a) automatically
    detected the card at OS install time.

    I am checking out/suspecting a recent wireless install by a third party may
    be responsible with either the Access Point or the Wireless LAN card
    upsetting the OS.

    In my case the 4096 bytes stream head eventually overflows once the stream
    memory in use exceeds the total configured stream memory (in this case at
    20096KB). I have the NSTRPAGES set at 5024.

    Just prior to overflowing, the netstat's are as follows:

    streams allocation:
    config alloc free total max
    fail
    stream 17408 105 17303 11619 118
    0
    queues 566 217 349 23412 243
    0
    mblks 9658 9458 200 4023467 9593
    1
    buffer headers 10042 9882 160 185569 9928
    0
    class 1, 64 bytes 192 21 171 1297039 165
    0
    class 2, 128 bytes 64 0 64 683141 55
    0
    class 3, 256 bytes 176 9 167 427512 164
    0
    class 4, 512 bytes 8 6 2 3874 8
    0
    class 5, 1024 bytes 18 0 18 5842 17
    0
    class 6, 2048 bytes 9263 9262 1 649524 9263
    0
    class 7, 4096 bytes 60 60 0 60 60
    0
    class 8, 8192 bytes 0 0 0 21 1
    0
    class 9, 16384 bytes 1 0 1 14144 5
    0
    class 10, 32768 bytes 0 0 0 0 0
    0
    class 11, 65536 bytes 0 0 0 0 0
    0
    class 12, 131072 bytes 0 0 0 0 0
    0
    class 13, 262144 bytes 0 0 0 0 0
    0
    class 14, 524288 bytes 0 0 0 0 0
    0
    total configured streams memory: 20096.00KB
    streams memory in use: 19167.23KB
    maximum streams memory used: 19336.23KB

    inet mblk cache: 256 = 0, 2048 = 628, 4096 = 60

    networking allocation:
    type alloc max fail
    socket 76 89 0
    rawcb 0 1 0
    inpcb 76 89 0
    tcpcb 53 64 0
    ifnet 6 6 0
    route 41 45 0
    ifaddr 2 2 0
    ipfrag 0 0 0
    sockaddr 152 178 0
    iovec 0 0 0
    moptions 0 2 0
    ipmaddr 2 2 0
    arpinfo 27 31 0
    mbcl 0 0 0
    ppp 0 0 0
    usock 10 11 0

    At overflow time, this occurs:

    streams allocation:
    config alloc free total max
    fail
    stream 17408 105 17303 12141 118
    0
    queues 566 217 349 24466 243
    0
    mblks 10511 10146 365 4262489 10365
    1
    buffer headers 10554 10440 114 202373 10444
    0
    class 1, 64 bytes 192 22 170 1372497 165
    0
    class 2, 128 bytes 30 0 30 718487 55
    0
    class 3, 256 bytes 93 9 84 446076 164
    0
    class 4, 512 bytes 10 6 4 4250 8
    0
    class 5, 1024 bytes 4 0 4 6502 17
    0
    class 6, 2048 bytes 9950 9948 2 679765 9950
    0
    class 7, 4096 bytes 60 60 0 60 60
    1943205
    class 8, 8192 bytes 0 0 0 21 1
    0
    class 9, 16384 bytes 0 0 0 14148 5
    4
    class 10, 32768 bytes 0 0 0 0 0
    0
    class 11, 65536 bytes 0 0 0 0 0
    0
    class 12, 131072 bytes 0 0 0 0 0
    0
    class 13, 262144 bytes 0 0 0 0 0
    0
    class 14, 524288 bytes 0 0 0 0 0
    0
    total configured streams memory: 20096.00KB
    streams memory in use: 20564.14KB
    maximum streams memory used: 20736.38KB



    Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
    net0 1500 10.1.1 sys088 645736 1447 430105 0 0
    lo0 8232 loopback localhost 7702 0 7702 0 0
    atl0* 8232 none none No Statistics Available



    No STREAMS Buffers 0 Number of frames dropped on reception
    because no STREAMS buffers were
    available

    The "messages" file and the console continually repeat the message:

    WARNING: allocb failed - NSTRPAGES exceeded

    A reboot is required at this point as TCP/IP connected service degrade

    I am reluctant to increase (yet) the NSTRPAGES parameter as I suspect it
    will only extend the life of the OS before the overflow occurs again.

    I am considering installing MP5 in the hope there is an updated Intel PRO
    driver that may have a correction to this problem. In the meantime I am
    shutting down the wireless network one item at a time to see if a component
    on the wireless is causing the buffer overflow.

    Has anyone else come across 'shonky' wireless networks as a cause of this
    problem. Why is it the SCO OS is only affected - no other devices appear to
    be affected? Does MP5 have a fix for this?

    Dave


    "N. Yaakov Ziskind" wrote in message
    news:20080401132046.A10207@egps.egps.com...
    > so, today, genius administrator 'somehow' unplugs the
    > firewall (on a separate box), plus, 'perhaps,' some
    > switches.
    >
    > immediately, all the telnet sessions to the SCO 506a box
    > just halt. one by one, they drop dead.
    >
    > console displays "No memory for streams (NSTRPAGES)"
    > over and over. otherwise unresponsive. i mentally debate
    > powering down the system, then i get a brainstorm, and unplug
    > the server's network jack. immediately, console comes back to
    > life. plug it back in, ppl can telnet again. woot.
    >
    > netstat -m has two funny rows:
    > config alloc free total max fail
    >
    > class 1, 64 bytes 576 41 535 -701344641 562 0
    > (i assume that a counter overflowed) and
    > class 6, 2048 bytes 1886 597 1289 1213818877 1886 10734386
    >
    > (spacing slightly adjusted).
    >
    > 1) anyone care to toss a conjecture what the heck happened?
    >
    > 2) do I need to do anything now for this box?
    >
    > I can't recall ever seeing this message before on this box.
    >
    > thanks!
    >
    > --
    > _________________________________________
    > Nachman Yaakov Ziskind, FSPA, LLM awacs@ziskind.us
    > Attorney and Counselor-at-Law http://ziskind.us
    > Economic Group Pension Services http://egps.com
    > Actuaries and Employee Benefit Consultants









  5. Re: No memory for streams (NSTRPAGES)

    David Font wrote:
    > I am having a similar problem with a OSR5.0.7 system (MP3) with a Intel
    > PR/100B /PRO/100+ Adaptor. The NIC driver (ver 5.0.7a) automatically
    > detected the card at OS install time.
    >
    > I am checking out/suspecting a recent wireless install by a third party may
    > be responsible with either the Access Point or the Wireless LAN card
    > upsetting the OS.
    >
    > In my case the 4096 bytes stream head eventually overflows once the stream
    > memory in use exceeds the total configured stream memory (in this case at
    > 20096KB). I have the NSTRPAGES set at 5024.
    >


    More on NSTRPAGES failures:

    I too have a client where they have begun getting stream memory leaking
    on an SCO 5.0.5 system. The system has been running without problems
    since I moved it to new hardware in Sept 2003. Beginning March 3, 2008,
    they begin getting allocb and NSTRPAGES failures:

    # grep NSTRPAGES /usr/adm/syslog | head
    Mar 3 10:05:43 real NOTICE: NSTRPAGES exceeded
    Mar 3 10:07:00 real NOTICE: NSTRPAGES exceeded
    Mar 3 10:09:51 real WARNING: allocb failed - NSTRPAGES exceeded
    Mar 3 10:43:27 real WARNING: allocb failed - NSTRPAGES exceeded
    Mar 3 10:57:27 real WARNING: allocb failed - NSTRPAGES exceeded
    Mar 3 11:03:24 real WARNING: allocb failed - NSTRPAGES exceeded
    Mar 3 11:12:46 real WARNING: allocb failed - NSTRPAGES exceeded
    Mar 3 11:16:12 real NOTICE: NSTRPAGES exceeded
    Mar 3 11:21:57 real WARNING: allocb failed - NSTRPAGES exceeded
    Mar 3 11:46:10 real WARNING: allocb failed - NSTRPAGES exceeded

    # last -w /etc/wtmp9 | grep -v ftp | awk '{ print $5, " " , $6, " " $7 } ' |>
    11 Sat Mar 8
    205 Fri Mar 7
    85 Thu Mar 6
    111 Wed Mar 5
    87 Tue Mar 4
    124 Mon Mar 3
    20 Sun Mar 2

    They have a second 5.0.5 server serving as a backup server that
    is not used unless the on-line server should go down. It too
    began getting NSTRPAGES in March 2008 even though no one was logged
    into the backup server:

    # rcmd failover grep NSTRPAGES /usr/adm/syslog | head
    Mar 5 23:44:49 failover NOTICE: NSTRPAGES exceeded
    Mar 6 03:00:16 failover NOTICE: NSTRPAGES exceeded
    Mar 6 03:03:16 failover NOTICE: NSTRPAGES exceeded
    Mar 6 03:03:31 failover NOTICE: NSTRPAGES exceeded
    Mar 6 03:03:54 failover NOTICE: NSTRPAGES exceeded
    Mar 6 05:22:24 failover NOTICE: NSTRPAGES exceeded
    Mar 6 14:39:27 failover WARNING: allocb failed - NSTRPAGES exceeded
    Mar 7 02:12:01 failover WARNING: allocb failed - NSTRPAGES exceeded
    Mar 7 13:35:23 failover WARNING: allocb failed - NSTRPAGES exceeded
    Mar 11 23:45:01 failover WARNING: allocb failed - NSTRPAGES exceeded

    # last -w /etc/wtmp5 | grep -v ftp | awk '{ print $5, " " , $6, " " $7 } ' |>
    6 Fri Mar 7
    1 Thu Mar 6
    3 Wed Mar 5
    1 Tue Mar 4
    1 Mon Mar 3

    Both servers are running identical hardware: SuperMicro PT3DL3
    system boards with 1.4GHz PIII processors and DPT 3754U2 RAID
    controllers. The PT3DL3 has on-board Intel Pro 10/100 NIC:

    eeE0 0xc800-0xc81f 10 - type=EE PRO/100+ 00:30:48:25:24:ce

    Patches Installed Prior to March 2008:

    || 3Com EtherLink PCI (ver 5.0.6b) * |
    || Intel(R) PRO/100B / PRO/100+ PCI Adapter (ver 5.0.5f)
    || OSS471E: Pentium family microcode supplement (ver oss471e) | |
    || OSS497C: Core OS Supplement (ver oss497c) | |
    || RS505A: Release Supplement for SCO OpenServer Release 5.0.5 (ver rs * |
    || RS505A: Software Manager Supplement (ver rs505a) * |
    || Year 2000 Supplement for RS505A (ver oss600a)

    Since working on this problem I have installed these additional patches using
    patchck (OSS663A installed manually after patchck installed OSS646C and LPD went
    crazy filling /usr/adm/syslog with messages about unknown printer):

    || OSS640A: BIND Update (ver 1.0.0) * |
    || OSS642a - Cron supplement (ver 1.0.0) * |
    || OSS646C - Execution Environment Supplement (ver 1.2.0a) * |
    || OSS663A - LPD Supplement for OSS646 (ver 1.0.0) * |


    I have tuned NSTRPAGES from the default of 500 on March 3 to the present
    value of 5000 on March 25 to delay the onset of allocb failures and
    NSTRPAGES exceeded to avoid having to reboot the system daily:

    # grep NSTRPAGES stune
    NSTRPAGES 5000

    I have set a script in root's crontab that runs every 5 minutes and logs
    streams memory in use to /usr/adm/nstr.log and extracted the following
    from the log:

    Mar 25 23:55:00 CDT 2008 streams memory in use: 1443.95 reboot @ 21:37:16
    1-Day total Delta: 71.14

    Mar 26 23:55:00 CDT 2008 streams memory in use: 1450.17 reboot @ 22:27:42
    1-Day total Delta: 379.88

    Mar 27 23:55:00 CDT 2008 streams memory in use: 1445.48 reboot @ 22:47:07
    1-Day total Delta: 66.31

    Mar 28 23:55:00 CDT 2008 streams memory in use: 4533.59
    1-Day total Delta: 3099.16

    Mar 29 23:55:00 CDT 2008 streams memory in use: 2013.02 reboot @ 08:39:07
    1-Day total Delta: 572.80

    Mar 30 23:55:00 CDT 2008 streams memory in use: 4869.45
    1-Day total Delta: 2843.82

    Mar 31 23:55:00 CDT 2008 streams memory in use: 2027.55 reboot @ 14:14:13
    1-Day total Delta: 601.52

    Apr 01 23:55:00 CDT 2008 streams memory in use: 5061.66
    1-Day total Delta: 3033.27

    Apr 02 23:55:00 CDT 2008 streams memory in use: 2181.63 reboot @ 11:49:16
    1-Day total Delta: 790.76

    Apr 03 23:55:00 CDT 2008 streams memory in use: 5895.07 Thu
    1-Day total Delta: 3713.44

    Apr 04 23:55:00 CDT 2008 streams memory in use: 6900.07 Fri
    1-Day total Delta: 1005.00

    Apr 05 23:55:00 CDT 2008 streams memory in use: 7244.71 Sat
    1-Day total Delta: 344.64

    Apr 06 23:55:00 CDT 2008 streams memory in use: 7425.77 Sun
    1-Day total Delta: 181.06

    Apr 07 23:55:00 CDT 2008 streams memory in use: 8831.78 Mon
    1-Day total Delta: 1406.01

    Apr 08 23:55:01 CDT 2008 streams memory in use: 9936.34 Tue
    1-Day total Delta: 1104.56

    Apr 09 23:55:01 CDT 2008 streams memory in use: 11022.41 Wed
    1-Day total Delta: 1082.02

    Apr 10 23:55:00 CDT 2008 streams memory in use: 13063.88 Thu
    1-Day total Delta: 2112.29

    Apr 11 23:55:00 CDT 2008 streams memory in use: 14749.66 Fri
    1-Day total Delta: 1768.71

    Apr 12 23:55:00 CDT 2008 streams memory in use: 15181.69 Sat
    1-Day total Delta: 432.31

    Apr 13 23:55:00 CDT 2008 streams memory in use: 15583.30 Sun
    1-Day total Delta: 401.89

    Apr 14 23:55:00 CDT 2008 streams memory in use: 16522.23 Mon
    1-Day total Delta: 939.20

    Apr 15 23:55:00 CDT 2008 streams memory in use: 17334.53 Tue
    1-Day total Delta: 812.58

    Apr 16 23:55:00 CDT 2008 streams memory in use: 18487.81 Wed
    1-Day total Delta: 1153.83

    Apr 17 00:00:00 CDT 2008 streams memory in use: 18490.11 Thu
    Apr 17 16:10:00 CDT 2008 streams memory in use: 19391.11
    Delta to reboot: 901.00

    Apr 17 16:14:34 CDT 2008 reboot initated
    Apr 17 16:20:00 CDT 2008 streams memory in use: 1380.50 Thu
    Apr 17 23:55:00 CDT 2008 streams memory in use: 1381.04 reboot @ 16:14:34
    1-Day total Delta: 0.54

    Apr 18 23:55:00 CDT 2008 streams memory in use: 4871.41 Fri
    1-Day total Delta: 3490.37

    Note that after a reboot the streams memory in use takes
    a large jump at 03:05 when the data mirror from the primary
    to the backup server kicks off:

    Fri Apr 18 02:55:00 CDT 2008 streams memory in use: 1380.46KB
    Fri Apr 18 03:00:00 CDT 2008 streams memory in use: 1380.46KB
    Fri Apr 18 03:05:01 CDT 2008 streams memory in use: 3938.28KB
    Fri Apr 18 03:10:00 CDT 2008 streams memory in use: 3905.27KB
    Fri Apr 18 03:15:01 CDT 2008 streams memory in use: 3905.14KB

    Mirror started: Fri Apr 18 03:00:06 CDT 2008
    6485359 blocks
    Mirror complete: Fri Apr 18 03:09:21 CDT 2008

    From the above, it looks like the week end (Sat & Sun) have
    lower daily delta on streams memory creep. There are people
    who were logged in and working on 4/6:

    # last | grep -v ftp | awk '{ print $5, " " , $6, " " $7 } ' | uniq -c
    2 Sat Apr 19
    108 Fri Apr 18
    125 Thu Apr 17
    103 Wed Apr 16
    83 Tue Apr 15
    88 Mon Apr 14
    20 Sun Apr 13
    16 Sat Apr 12
    123 Fri Apr 11
    123 Thu Apr 10
    104 Wed Apr 9
    121 Tue Apr 8
    142 Mon Apr 7
    10 Sun Apr 6
    28 Sat Apr 5
    101 Fri Apr 4
    147 Thu Apr 3
    151 Wed Apr 2
    102 Tue Apr 1
    151 Mon Mar 31
    29 Sun Mar 30

    Checking just the ftp sessions (the client has a Windows FTP program that
    is used to access the /tmp directory on the primary server and automatically
    read report files written to /tmp into Excel spread sheet report):

    # last | grep ftp | awk '{ print $5, " " , $6, " " $7 } ' | uniq -c
    83 Fri Apr 18
    74 Thu Apr 17
    79 Wed Apr 16
    97 Tue Apr 15
    90 Mon Apr 14
    4 Sun Apr 13
    2 Sat Apr 12
    81 Fri Apr 11
    103 Thu Apr 10
    86 Wed Apr 9
    75 Tue Apr 8
    98 Mon Apr 7
    8 Sun Apr 6
    4 Sat Apr 5
    71 Fri Apr 4
    78 Thu Apr 3
    70 Wed Apr 2
    113 Tue Apr 1
    119 Mon Mar 31
    13 Sun Mar 30

    There is a spike in FTP use on 4/10 that appears to correlate
    to the increase in 1-Day Delta for 4/10 of 2112.

    I am starting to suspect that the introduction of Windows Vista
    at the client's office using the Windows FTP client is contributing
    to the "stream memory in use" creep.

    Trying to use a Windows based packet sniffer on a hub connected
    between the primary server and 100M switch port has not been
    helpful as the nightly mirror at 3:00 swamps the packet sniffer
    and drives it into a lock up.

    Has anyone tried using a UNIX based packet sniffer like ethereal
    or tcpdump to identify the source of stream memory leaks?
    --
    Steve Fabac
    S.M. Fabac & Associates
    816/765-1670

  6. Re: No memory for streams (NSTRPAGES)

    Since I removed the Wireless Access Point from the LAN and converted the
    wireless connected laptops to wired connection, the problem has stopped. The
    streams stays steady at 5200KB

    The Wireless Access Point installed was a Belken (cheapo), the laptops
    connected to the WAP were Vista and XP. The WAP had been in place for a few
    months and there hadnt been any problems until recently.

    The XP laptop was converted to wired connection first, leaving the WAP and
    the Vista laptop. The streams was steadily rising in the scenario resulting
    in eventual streams overflow making it neccessary to reboot the OSR5 server

    The WAP had been running OK for some time, however I am now wondering
    whether the Vista PC is the culprit. I also have to consider the possibility
    the WAP has suddenly gone faulty. At some point I will look into
    reintroducing the WAP with the XP laptop only and monitor the streams
    performance on OSR507 server.

    Dave



    "David Font" wrote in message
    news:fthcna$hni$1@services.telesweet...
    >I am having a similar problem with a OSR5.0.7 system (MP3) with a Intel
    > PR/100B /PRO/100+ Adaptor. The NIC driver (ver 5.0.7a) automatically
    > detected the card at OS install time.
    >
    > I am checking out/suspecting a recent wireless install by a third party
    > may
    > be responsible with either the Access Point or the Wireless LAN card
    > upsetting the OS.
    >
    > In my case the 4096 bytes stream head eventually overflows once the stream
    > memory in use exceeds the total configured stream memory (in this case at
    > 20096KB). I have the NSTRPAGES set at 5024.
    >
    > Just prior to overflowing, the netstat's are as follows:
    >
    > streams allocation:
    > config alloc free total max
    > fail
    > stream 17408 105 17303 11619 118
    > 0
    > queues 566 217 349 23412 243
    > 0
    > mblks 9658 9458 200 4023467 9593
    > 1
    > buffer headers 10042 9882 160 185569 9928
    > 0
    > class 1, 64 bytes 192 21 171 1297039 165
    > 0
    > class 2, 128 bytes 64 0 64 683141 55
    > 0
    > class 3, 256 bytes 176 9 167 427512 164
    > 0
    > class 4, 512 bytes 8 6 2 3874 8
    > 0
    > class 5, 1024 bytes 18 0 18 5842 17
    > 0
    > class 6, 2048 bytes 9263 9262 1 649524 9263
    > 0
    > class 7, 4096 bytes 60 60 0 60 60
    > 0
    > class 8, 8192 bytes 0 0 0 21 1
    > 0
    > class 9, 16384 bytes 1 0 1 14144 5
    > 0
    > class 10, 32768 bytes 0 0 0 0 0
    > 0
    > class 11, 65536 bytes 0 0 0 0 0
    > 0
    > class 12, 131072 bytes 0 0 0 0 0
    > 0
    > class 13, 262144 bytes 0 0 0 0 0
    > 0
    > class 14, 524288 bytes 0 0 0 0 0
    > 0
    > total configured streams memory: 20096.00KB
    > streams memory in use: 19167.23KB
    > maximum streams memory used: 19336.23KB
    >
    > inet mblk cache: 256 = 0, 2048 = 628, 4096 = 60
    >
    > networking allocation:
    > type alloc max fail
    > socket 76 89 0
    > rawcb 0 1 0
    > inpcb 76 89 0
    > tcpcb 53 64 0
    > ifnet 6 6 0
    > route 41 45 0
    > ifaddr 2 2 0
    > ipfrag 0 0 0
    > sockaddr 152 178 0
    > iovec 0 0 0
    > moptions 0 2 0
    > ipmaddr 2 2 0
    > arpinfo 27 31 0
    > mbcl 0 0 0
    > ppp 0 0 0
    > usock 10 11 0
    >
    > At overflow time, this occurs:
    >
    > streams allocation:
    > config alloc free total max
    > fail
    > stream 17408 105 17303 12141 118
    > 0
    > queues 566 217 349 24466 243
    > 0
    > mblks 10511 10146 365 4262489 10365
    > 1
    > buffer headers 10554 10440 114 202373 10444
    > 0
    > class 1, 64 bytes 192 22 170 1372497 165
    > 0
    > class 2, 128 bytes 30 0 30 718487 55
    > 0
    > class 3, 256 bytes 93 9 84 446076 164
    > 0
    > class 4, 512 bytes 10 6 4 4250 8
    > 0
    > class 5, 1024 bytes 4 0 4 6502 17
    > 0
    > class 6, 2048 bytes 9950 9948 2 679765 9950
    > 0
    > class 7, 4096 bytes 60 60 0 60 60
    > 1943205
    > class 8, 8192 bytes 0 0 0 21 1
    > 0
    > class 9, 16384 bytes 0 0 0 14148 5
    > 4
    > class 10, 32768 bytes 0 0 0 0 0
    > 0
    > class 11, 65536 bytes 0 0 0 0 0
    > 0
    > class 12, 131072 bytes 0 0 0 0 0
    > 0
    > class 13, 262144 bytes 0 0 0 0 0
    > 0
    > class 14, 524288 bytes 0 0 0 0 0
    > 0
    > total configured streams memory: 20096.00KB
    > streams memory in use: 20564.14KB
    > maximum streams memory used: 20736.38KB
    >
    >
    >
    > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs
    > Coll
    > net0 1500 10.1.1 sys088 645736 1447 430105 0 0
    > lo0 8232 loopback localhost 7702 0 7702 0 0
    > atl0* 8232 none none No Statistics Available
    >
    >
    >
    > No STREAMS Buffers 0 Number of frames dropped on reception
    > because no STREAMS buffers were
    > available
    >
    > The "messages" file and the console continually repeat the message:
    >
    > WARNING: allocb failed - NSTRPAGES exceeded
    >
    > A reboot is required at this point as TCP/IP connected service degrade
    >
    > I am reluctant to increase (yet) the NSTRPAGES parameter as I suspect it
    > will only extend the life of the OS before the overflow occurs again.
    >
    > I am considering installing MP5 in the hope there is an updated Intel PRO
    > driver that may have a correction to this problem. In the meantime I am
    > shutting down the wireless network one item at a time to see if a
    > component
    > on the wireless is causing the buffer overflow.
    >
    > Has anyone else come across 'shonky' wireless networks as a cause of this
    > problem. Why is it the SCO OS is only affected - no other devices appear
    > to
    > be affected? Does MP5 have a fix for this?
    >
    > Dave
    >
    >
    > "N. Yaakov Ziskind" wrote in message
    > news:20080401132046.A10207@egps.egps.com...
    >> so, today, genius administrator 'somehow' unplugs the
    >> firewall (on a separate box), plus, 'perhaps,' some
    >> switches.
    >>
    >> immediately, all the telnet sessions to the SCO 506a box
    >> just halt. one by one, they drop dead.
    >>
    >> console displays "No memory for streams (NSTRPAGES)"
    >> over and over. otherwise unresponsive. i mentally debate
    >> powering down the system, then i get a brainstorm, and unplug
    >> the server's network jack. immediately, console comes back to
    >> life. plug it back in, ppl can telnet again. woot.
    >>
    >> netstat -m has two funny rows:
    >> config alloc free total max fail
    >>
    >> class 1, 64 bytes 576 41 535 -701344641 562 0
    >> (i assume that a counter overflowed) and
    >> class 6, 2048 bytes 1886 597 1289 1213818877 1886 10734386
    >>
    >> (spacing slightly adjusted).
    >>
    >> 1) anyone care to toss a conjecture what the heck happened?
    >>
    >> 2) do I need to do anything now for this box?
    >>
    >> I can't recall ever seeing this message before on this box.
    >>
    >> thanks!
    >>
    >> --
    >> _________________________________________
    >> Nachman Yaakov Ziskind, FSPA, LLM awacs@ziskind.us
    >> Attorney and Counselor-at-Law http://ziskind.us
    >> Economic Group Pension Services http://egps.com
    >> Actuaries and Employee Benefit Consultants

    >
    >
    >
    >
    >
    >
    >




  7. Re: No memory for streams (NSTRPAGES)


    ----- Original Message -----
    From: "David Font"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Sunday, April 20, 2008 5:39 PM
    Subject: Re: No memory for streams (NSTRPAGES)


    > Since I removed the Wireless Access Point from the LAN and converted the
    > wireless connected laptops to wired connection, the problem has stopped. The
    > streams stays steady at 5200KB
    >
    > The Wireless Access Point installed was a Belken (cheapo), the laptops
    > connected to the WAP were Vista and XP. The WAP had been in place for a few
    > months and there hadnt been any problems until recently.
    >
    > The XP laptop was converted to wired connection first, leaving the WAP and
    > the Vista laptop. The streams was steadily rising in the scenario resulting
    > in eventual streams overflow making it neccessary to reboot the OSR5 server


    Thanks for reporting the results here.
    Thats definitely good stuff to know about and to be able to google up some other day.

    --
    Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


+ Reply to Thread