| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3614.1 | Discussion 1494 helped but not completly | MUTTON::LAMB | Peter Lamb - GSG Santa Clara | Thu Nov 08 1990 19:43 | 37 |
| Everytime I use notes I am constantly amazed at what an incredibly powerful
tool it is! After a few minutes of searching this file I discovered this
discussion regarding the Maximum # of local transport applications and I
guess I now have a few questions...
The questions are, given I am now running a newer version of decwindows then
is being discussed in #1494, for example, I checked DECW$STARTSERVER.COM and
it looks like my system is already setting the ENQUEUE_LIMIT to 64 however,
I am still having the problem. Does anyone have any other ideas??
Peter
<<< BULOVA::DOCD$:[NOTES$LIBRARY]DECWINDOWS.NOTE;6 >>>
-< DECWINDOWS >-
================================================================================
Note 1494.9 Trouble starting lots of processes 9 of 9
DECWIN::JMSYNGE "James M Synge, VMS Development" 18 lines 10-DEC-1989 12:10
-< ENQLM limits the number of local connections >-
--------------------------------------------------------------------------------
While LOCAL transport doesn't place a limit on the maximum number of
connections, it does use a resource, locks, which are limited by a
quota. In particular, it uses two per connection.
The ENQLM quota has a default value of 30, and this is not currently
overridden in SYS$MANAGER:DECW$STARTSERVER.COM. Thus, we have an
effective limit of 15 local connections.
If you need to fix this immediately (i.e. before I fix it on the master
pack and it ships), then you should probably add a line that looks like
/ENQUEUE_LIMIT = 64 -
to SYS$MANAGER:DECW$STARTSERVER.COM where the RUN/DETACHED is (at the
end of the file).
James
|
| 3614.2 | Server is running out of memory | STAR::VATNE | Peter Vatne, VMS Development | Fri Nov 09 1990 10:49 | 9 |
| The key here is the line:
8-NOV-1990 17:02:20.3 Cannot allocate clientrec, or bigbuffer
This means the server is running out of virtual memory.
What does SHOW PROC/ACCOUNT show for the peak virtual size?
If it is near 25000, then we'll need to bump up the server's
paging file quota.
|
| 3614.3 | We have a winner?? | PJWL::LAMB | Peter Lamb - FSG Santa Clara | Fri Nov 09 1990 11:45 | 43 |
| Hi,
I think you have it!! This is what my system looks like currently (and the
clock processes are not running now). Is 20953 close enough to 25000??
MUTTON::> show proc/id=202001C0/account
9-NOV-1990 09:46:27.37 User: LAMB Process ID: 202001C0
Node: MUTTON Process name: "DECW$SERVER_0"
Accounting information:
Buffered I/O count: 1830 Peak working set size: 4000
Direct I/O count: 16795 Peak virtual size: 20953
Page faults: 48679 Mounted volumes: 0
Images activated: 0
Elapsed CPU time: 0 00:14:07.50
Connect time: 6 18:47:17.35
_MUTTON::>
Peter
P.S. How do you show a processes WORKING SET QUOTA?? and ENQUEUE QUOTA?
A show proc/id=xx/quota shows the following and given -1 I would expect
the enqueue quota to be 64 but it is showing at 40?? Also I really need
to see the working set quota for another problem I'm having with NCP
and can't figure out how to show it.
_MUTTON::> SHOW PROC/ID=202001C0/QUOTA
9-NOV-1990 09:49:30.01 User: LAMB Process ID: 202001C0
Node: MUTTON Process name: "DECW$SERVER_0"
Process Quotas:
Account name: SYSTEM
CPU limit: Infinite Direct I/O limit: 100
Buffered I/O byte count quota: 42656 Buffered I/O limit: 60
Timer queue entry quota: 7 Open file quota: 44
Paging file quota: 9158 Subprocess quota: 8
Default page fault cluster: 64 AST quota: 96
Enqueue quota: 40 Shared file limit: 0
Max detached processes: 0 Max active jobs: 0
|
| 3614.4 | Looks like the winner to me! | STAR::VATNE | Peter Vatne, VMS Development | Fri Nov 09 1990 14:20 | 27 |
| Yes, I'd say that 20953 is close enough to 25000 to be the culprit.
I don't know why the server is using so much virtual memory on your
system, as I have lots of connections to my server and it only shows
9528 peak virtual size for the server process.
I'd say this warrants entering a QAR.
The workaround is to put the following line in DECW$PRIVATE_SERVER_SETUP.COM:
$ define decw$server_page_file 30000
(or even bigger). You should also check to make sure the SYSGEN
parameter VIRTUALPAGECOUNT is at least that big. And you will
also need a page file that is big enough for all your processes.
Showing quotas is not easy. I think that the labels from SHOW PROC/QUOTA
are very misleading. The quota numbers shown are actually the "quotas"
at the instant. For example, the enqueue quota for the server does
start out at 64, but as each lock is taken out, the quota is decremented
by 1. When it reaches zero, you can't take out any more locks. Of
course, what we'd all like to see is the original quota of the process
compared to the amount in use (e.g. enqueue usage: 14/64).
The way I always check on quotas is to run authorize and look at the
account's quotas. For created processes like the server, you have to
look at the original run command (the DECwindows server is created
from SYS$MANAGER:DECW$STARTSERVER.COM). Also, you may be able to see
the quotas from SDA, but of course that isn't very convenient! Maybe
you should enter a suggestion QAR against VMS...
|
| 3614.5 | What entering a QAR does for you | STAR::VATNE | Peter Vatne, VMS Development | Fri Nov 09 1990 14:57 | 7 |
| I'd like to point out that entering a QAR for any problem that you
see will only affect development of DECwindows V3. It will not
help with finding or fixing bugs in the currently shipping product.
If you have a CLD outstanding, continue to work with your CLD rep.
If they don't know the answer, they will come find me or someone
else in the DECwindows group.
|
| 3614.6 | The saga continues... | MUTTON::LAMB | Peter Lamb - GSG Santa Clara | Fri Nov 09 1990 15:59 | 77 |
| Well, I tried upping the pagefile quota to 30000 as suggested in .4
but unfortunaly now when I restart the server and start up 11 DECW$CLOCKs
and look at show proc/account I am only using 15800 pages and the problem
is still occuring. (I guess the 20000 must have come from something
else I ran once).
I believe a clue to this problem may be that it seems to be application
independent. Ie you would think that if I had a resource problem it
would be occuring for most DECwindows applications. However, this is
not the case. Even after I have 11 clock applications running (and can't
get any more) I can continue to start other applications with out any
problem (for example I am writing this in DECwindows notes and started
this after the 11 clocks).
For what it is worth here is what my current SHOW PROC/ACCOUNT
returns...
_MUTTON::> sho proc/id=20200322/account
9-NOV-1990 14:03:54.39 User: LAMB Process ID: 20200322
Node: MUTTON Process name: "DECW$SERVER_0"
Accounting information:
Buffered I/O count: 1364 Peak working set size: 3830
Direct I/O count: 2160 Peak virtual size: 15811
Page faults: 16322 Mounted volumes: 0
Images activated: 0
Elapsed CPU time: 0 00:01:16.64
Connect time: 0 00:21:40.59
A show sys also show the following....
_MUTTON::> sho sys
VAX/VMS V5.4 on node MUTTON 9-NOV-1990 14:04:37.32 Uptime 17 02:20:02
Pid Process Name State Pri I/O CPU Page flts Ph.Mem
20200081 SWAPPER HIB 16 0 0 00:00:51.00 0 0
20200086 CONFIGURE HIB 10 39 0 00:00:00.25 126 228
20200088 ERRFMT HIB 8 12723 0 00:00:51.17 84 126
20200089 CACHE_SERVER HIB 16 133 0 00:00:00.25 63 100
2020008A CLUSTER_SERVER HIB 8 322 0 00:00:02.88 143 336
2020008B OPCOM HIB 8 5546 0 00:00:31.09 607 180
2020008C AUDIT_SERVER HIB 10 50 0 00:00:00.99 1353 479
2020008D JOB_CONTROL HIB 10 5652 0 00:00:18.85 141 337
2020008E IPCACP HIB 10 40 0 00:00:00.09 77 139
2020008F TP_SERVER HIB 10 98465 0 00:16:06.28 168 253
20200090 SMISERVER HIB 9 56 0 00:00:00.46 276 490
20200095 LATACP HIB 14 7 0 01:21:24.65 522 455
20200099 NMAIL HIB 5 144 0 00:00:00.44 360 84
2020009A DNS$ADVER HIB 4 12173 0 00:00:36.29 192 299
2020009B RDMS_MONITOR LEF 15 17 0 00:00:00.40 14995 51
20200322 DECW$SERVER_0 HIB 6 3554 0 00:01:21.29 16511 1855
202002A3 LAMB LEF 4 189 0 00:00:05.66 5951 508
20200224 DECW$WM_11 LEF 7 35 0 00:00:06.46 1571 2243
20200225 DECW$WM_12 LEF 7 35 0 00:00:02.23 1303 650
202002A6 LAMB_SM1 LEF 4 155 0 00:00:12.99 5314 2048
202002A7 LAMB_SM2 LEF 4 155 0 00:00:05.59 5118 2048
202002A8 LAMB_SM3 LEF 6 146 0 00:00:04.81 4859 2049
2020032B LAMB_SM6 LEF 5 437 0 00:00:33.09 6678 2691
2020032C LAMB_SM7 LEF 6 258 0 00:00:06.27 5473 3332
202002AD LAMB_SM8 LEF 4 411 0 00:00:39.14 12156 4180
202002AE DECW$TE_11 LEF 6 605 0 00:00:40.05 2510 2305
202002AF _TWA17: LEF 4 76 0 00:00:01.92 3293 786
20200330 _TWA18: CUR 4 376 0 00:00:03.96 3888 249
202002B1 LAMB_SM4 LEF 5 141 0 00:00:04.54 4581 2001
20200332 LAMB_SM5 LEF 4 139 0 00:00:04.50 4725 2047
20200333 LAMB_SM9 LEF 4 139 0 00:00:04.59 4625 2030
202002B4 LAMB_SM10 LEF 4 139 0 00:00:04.57 4553 1981
20200335 LAMB_SM11 LEF 5 139 0 00:00:04.52 4583 1980
20200236 NETACP HIB 10 2026 0 00:03:13.56 47368 3000
20200237 EVL HIB 6 1652 0 00:00:11.14 99727 55 N
20200238 REMACP HIB 8 42 0 00:00:00.09 74 56
20200339 LAMB_SM12 LEF 4 139 0 00:00:04.59 4830 1982
2020033A LAMB_SM13 LEF 6 139 0 00:00:04.49 4593 2413
2020033B LAMB_SM14 LEF 4 139 0 00:00:04.52 4687 2048
2020033C LAMB_SM15 LEF 4 139 0 00:00:04.60 4221 2022
20200241 VUE$LAMB_1 LEF 4 284 0 00:00:06.09 3205 399 S
20200242 VUE$LAMB_2 LEF 4 168 0 00:00:02.11 956 449 S
_MUTTON::>
|
| 3614.7 | See also notes 3558 and 1494 | MUTTON::LAMB | Peter Lamb - GSG Santa Clara | Fri Nov 09 1990 16:04 | 12 |
| I just thought I would mention that in my searching I have discovered
that this problem has also been discussed in the topics numbered above.
It turns out that # 3558 is actually the same customer that I am dealing
with and was put in by the TSC when he logged the origional call.
I guess this should teach me to search even more carefully!! (I thought
I was doing well when I found #1494!)
Just an FYI
Peter
|
| 3614.8 | Enqlm Seems to be the culprit but raising it doesn't help | MUTTON::LAMB | Peter Lamb - GSG Santa Clara | Mon Nov 12 1990 13:14 | 33 |
| Hello,
The latest status on this problem is that the TSC can reproduce the problem
with DECW$CLOCK however were all at a loss at to what to do next...
Well, we believe we have established that it is probably ENQLM that the
server is running out of. A quick check of my system shows DECW$SERVER_0
with only 4 remaining below & (each time a clock is started it takes 4 locks).
_MUTTON::> show proc/id=20200322/quota
12-NOV-1990 11:10:30.12 User: LAMB Process ID: 20200322
Node: MUTTON Process name: "DECW$SERVER_0"
Process Quotas:
Account name: SYSTEM
CPU limit: Infinite Direct I/O limit: 100
Buffered I/O byte count quota: 43200 Buffered I/O limit: 60
Timer queue entry quota: 7 Open file quota: 50
Paging file quota: 16762 Subprocess quota: 8
Default page fault cluster: 64 AST quota: 96
>> Enqueue quota: 4 Shared file limit: 0
We then attempted to raise the limit in the server (it starts at 64) up to
128 but then when the 11th clock is reached the total simply sits at 64 and
won't go any lower.
Is there a sysgen parameter related to ENQUELM OR ENQUEQUOTA??
Thanks!!!
Peter
|