[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference gyro::internet_toolss

Title:Internet Tools
Notice:Report ALL NETSCAPE Problems directly to [email protected].rnet? Read note 448.L for beginner information.
Moderator:teco.mro.dec.com::tecotoo.mro.dec.com::mayer
Created:Fri Jun 25 1993
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4714
Total number of notes:40609

4463.0. "Fasttrack errors "403 forbidden" that are sporadic" by CHGV04::JANES (Lester Janes DTN 474-5373) Mon Feb 10 1997 12:52

    I have been having a strange, intermitent problem with my Fasttrack
    server. Everything will be going along fine and suddenly users will
    no longer be access web pages and will get the following message:
    
    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)
    
    I am running Fasttrack on a DEC 3000 as a new installation on Digital
    UNIX 4.0B. 128 mem and there are no other applications running on the
    system.
    
    Any suggestions are appreciated.
    
    If you would like to visit my site and try and recreate the problem, it
    is at "snobox.chi.dec.com"
    
    Thanks,
    Les
T.RTitleUserPersonal
Name
DateLines
4463.1did it mention mmap? need higher vm-mapentries?LGP30::FLEISCHERwithout vision the people perish (DTN 381-0426 ZKO1-1)Mon Feb 10 1997 13:3973
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::"[email protected]" "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::"[email protected]" "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.2Will disabling cache solve problem?CHGV04::JANESLester Janes DTN 474-5373Mon Feb 10 1997 15:0312
    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.3LGP30::FLEISCHERwithout vision the people perish (DTN 381-0426 ZKO1-1)Mon Feb 10 1997 17:037
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.4Netscape Response - Known problem on DigitalUnix and AIXGYRO::CAETANOGreg Caetano ZKO2-2M17 381-1338Tue Feb 11 1997 15:0989
=========
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.5CHGV04::JANESLester Janes DTN 474-5373Wed Feb 12 1997 10:487
    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.6Increasing VM-MAPENTRIES appears to have helpedCHGV04::JANESLester Janes DTN 474-5373Tue Mar 25 1997 17:2011
    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