| T.R | Title | User | Personal Name | Date | Lines |
|---|
| 4463.1 | did it mention mmap? need higher vm-mapentries? | LGP30::FLEISCHER | without vision the people perish (DTN 381-0426 ZKO1-1) | Mon Feb 10 1997 13:39 | 73 |
| re Note 4463.0 by CHGV04::JANES:
> 403 - Forbidden. Acess is explicitly denied.
>
> The problem ocurrs at inconsistent times and is cured by stopping and
> restarting the server.
>
> In the log file, an associated error message at the time 403 ocurrs
> is: "......(Not enough space)
That looks suspiciously like an error I once encountered:
<<< TURRIS::DISK$NOTES_PACK2:[NOTES$LIBRARY]DIGITAL_UNIX.NOTE;1 >>>
-< DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) >-
================================================================================
Note 7009.0 File cache create error mmap(ing) 2 replies
NETRIX::"euan@hhl.dec.com" "Euan McMaster" 21 lines 11-SEP-1996 13:03
--------------------------------------------------------------------------------
A customer of mine, due to go live next Monday on an pair of 2100s running ASE
and netscape server on UNIX 3.2C just started getting the error shown below,
intermittently, when a client browser tries to access a JAVA page of > 2MB
As far as I know, the browser fails to get the page:
The error messages appear in the netscape server error log.
FAILURE: FILE CACHE CREATE ERROR MMAP []ING FILE location [NOT ENOUGH SPACE]
(May not be exact, problem was emailed to me by customer)
Does this sound like a netscape server bug or a UNIX resource problem ?
I believe the customer is running netscape server on both nodes and routing
client requests in a "round-robin" manner at their DNS server. Could this have
any bearing on the problem ??
ANY help greatly appreciated ASAP
Thanks.
[Posted by WWW Notes gateway]
================================================================================
Note 7009.1 File cache create error mmap(ing) 1 of 2
PERFOM::PSMITH "Paula Smith - CSG Performance Group" 13 lines 11-SEP-1996 14:40
--------------------------------------------------------------------------------
Looks like Netscape improved the error message - the beta versions
didn't mention mmap. I believe if you tune vm-mapentries in the
sysconfigtab the error should go away:
Example:
vm:
vm-mapentries = 20000
================================================================================
Note 7009.2 File cache create error mmap(ing) 2 of 2
NETRIX::"euan@hhl.dec.com" "Euan McMaster" 12 lines 30-SEP-1996 12:26
-< Also vm_maxvas >-
--------------------------------------------------------------------------------
The customer got a similar, but extended response from Netscape, which is what
we implemented, apparently with success.
They suggested the following entries are required:
vm:
vm-maxvas = 0x40000000000
vm-mapentries = 20000
Regards, Euan
[Posted by WWW Notes gateway]
|
| 4463.2 | Will disabling cache solve problem? | CHGV04::JANES | Lester Janes DTN 474-5373 | Mon Feb 10 1997 15:03 | 12 |
| Thanks for the quick reply. In your customer's example it appears to
only occur on one web page, a Java page. All of the web pages on my
server are effected, i.e. 403 Forbidden.
In Netscape Tech Support, they discuss disabling server cache.
"Init fn=cache-init disable=true"
Could this be a possible solution, and what are the consequences of
disabling server cache?
Thanks again,
Les
|
| 4463.3 | | LGP30::FLEISCHER | without vision the people perish (DTN 381-0426 ZKO1-1) | Mon Feb 10 1997 17:03 | 7 |
| re Note 4463.2 by CHGV04::JANES:
If you haven't tried setting vm-mapentries, you should do so
-- it is a known problem at least with the Enterprise version
of Netscape's server.
Bob
|
| 4463.4 | Netscape Response - Known problem on DigitalUnix and AIX | GYRO::CAETANO | Greg Caetano ZKO2-2M17 381-1338 | Tue Feb 11 1997 15:09 | 89 |
| =========
Solution:
=========
>
> Yup. These are related to server side caching. We have not had a
> whole lot of success with disabling server-side cache on Digital:
>
> Init fn="cache-init" disable
>
> does not seem to work on digital or AIX. The server does not complain
> about the syntax, yet it has been known to rewrite the directive to:
>
> Init fn="cache-init" 2=disable
>
> on later save / apply when it is modifying obj.conf. It's as if the
> admin server expects all the parameters to be name / value pairs. We
> have also tried:
>
> Init fn="cache-init" disable=true
>
> without success. What appears to be happening is that the server is
> allocating more RAM for cache than the OS will allow. I have had
> success by tuning enterprise and minimizing the amount of caching done
> by the server like so:
>
> Init fn="cache-init" cache-size="32" mmap-max="1024"
>
> The less the server caches, the less likely it is to run into low
> memory in the Unified Buffer Cache in digital's virtual memory
> scheme. A setting like the one above is generally successful at
> eliminating this problem.
>
> There are basically three tunable parameters in digital unix that may
> help alleviate the problem without having to modify the cache
> settings. I've had varying degrees of success with this:
>
> vm:ubc-maxpercent - This is the percentage of blocks in the UBC that
> the file system is allowed to occupy. It defaults to 100 - so if the
> file system does occupy 100% of the UBC there is no room for the VM to
> cache. Digital says 50 is a safe value and you can adjust accordingly
> from there based on performance.
>
> vm:vm-mapentries - This is a key one in relation to this problem. It
> is the number of memory-mapped files available per process. It
> defaults to 200. Our cache defaults to 512. If our server attempts
> to cache more than what this is set to you will see these errors. I
> typically adjust this to 20000 :)
>
> vm: vm-vpagemax - Sets the maximum number of pages allowed in a
> process's address space. According to digital, this should always be
> set to a value equal to vm-maxvas/8192.
>
> Two other digital parameters that are key to tuning for our server,
> but not really related to this problem are:
>
> proc:max-proc-per-user - Key in a heavily multihomed environment. How
> many processes is the web server allowed to run? Defaults to 64
>
> proc:max-threads-per-user - Very important to FT/ENT!! Must be higher
> than the MaxThreads setting on the Netscape server. If multi-homing
> or multi-process configuration, this must be greater than summ of all
> maxthreads. Defaults to 256.
>
> As to this particular customer, She opened a call with us yesterday on
> this issue. I did not speak to her and the tech who did is not here
> so I cannot confirm or deny her tale of us pointing her to digital.
> However I read the case documentation and the tech who spoke with her
> gave her the syntax to disable cache and mentioned some of these
> tunable parameters. The tech she spoke with is extremely good and
> I find itr hard to believe that he "had a snotty attitude about the
> problem." Support is our business and we do not tolerate poor
> customer service. I will follow up with him tomorrow, however, and
> make sure that we contact her again to see that her problem is
> completely resolved and that she is happy.
>
> Hope this Helps,
>
> Dan
>
> P.S. if anyone has any insight as to why completely disabling server
> side cache on digital unix seems impossible, I'd love to hear it. Our
> experience has been that it is a problem on AIX as well...
>
--
Kelly D. Lucas | "Any opinions expressed are
Netscape Communications | my own and not Netscape's"
OEM/Strategic Accounts |
Technical Support Engineer | http://help.netscape.com/
|
| 4463.5 | | CHGV04::JANES | Lester Janes DTN 474-5373 | Wed Feb 12 1997 10:48 | 7 |
| Greg,
Thanks for the detailed message. I only know as much about UNIX as
I have to, so the detailed explanation helps. I will try the
suggestions and post the results back here.
Thanks,
Les
|
| 4463.6 | Increasing VM-MAPENTRIES appears to have helped | CHGV04::JANES | Lester Janes DTN 474-5373 | Tue Mar 25 1997 17:20 | 11 |
| This is just an update on my problems/resolution with "403 Forbidden".
As a refresher...my server would sporatically forbid access to any of
my web pages. I applied one of the recommended solutions in this note;
to raise the UNIX paramater "vm-mapentries" from 200 to 2000. That was
a week ago, and it appears to have solved the problem. If the problem
creeps up again, you'll be the first to hear.
Outside of Digital, there is nothing that comes close to the help and
professionalism of our Notes conferences. Thanks for your suggestions.
Lester
|