No memory for streams (NSTRPAGES)
N. Yaakov Ziskind
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
N. Yaakov Ziskind
jbo...@sco.com
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:
to see if you can pinpoint what is causing the streams leak.
John
David Font
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" <aw...@ziskind.us> wrote in message
news:2008040113...@egps.egps.com...
Steve M. Fabac, Jr.
> 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
David Font
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" <co...@systime.co.nz> wrote in message
news:fthcna$hni$1...@services.telesweet...
Brian K. White
----- Original Message -----
From: "David Font" <co...@systime.co.nz>
Newsgroups: comp.unix.sco.misc
To: <dis...@jpr.com>
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 br...@aljex.com http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!