Date: Fri, 8 Mar 1996 13:04:58 -0500 From: "Garrett A. Wollman" <wollman@lcs.mit.edu> To: Jaye Mathisen <mrcpu@cdsnet.net> Cc: questions@FreeBSD.ORG Subject: Re: Can someone tell me what this kernel message means? Message-ID: <9603081804.AA13437@halloran-eldar.lcs.mit.edu> In-Reply-To: <Pine.BSF.3.91.960307152259.28959F-100000@schizo.cdsnet.net> References: <9603071836.AA06351@halloran-eldar.lcs.mit.edu> <Pine.BSF.3.91.960307152259.28959F-100000@schizo.cdsnet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Thu, 7 Mar 1996 15:24:55 -0800 (PST), Jaye Mathisen <mrcpu@cdsnet.net> said: > Hmmm. Well, I appreciate having the MIB variables, but what are the > tradeoffs memory wise? How do these variables play in a very dynamic IP > shop vs. a single machine? What kind of settings should be on a popular > nameserver/webserver vs a single user box? Every entry in the routing table, which includes all of the per-host cache, takes up between 128 and 256 bytes of memory. The information stored there is of four different types: - VJ TCP parameters: round-trip time, slow-start threshold - Transaction TCP parameters: CC.sent and CC.rcvd - Default buffer sizes - Path MTU All of these parameters can be re-learned, at some cost in performance. The VJ parameters only come into play when the network is congested enough to result in retransmissions. The Path MTU, of course, depends on what sort of network connections are present along the path. The Tranaction TCP parameters, if deleted, simply cause the next connection with the host to fall back on standard TCP. The default buffer sizes are filled in from the parent route and optionally modified by the interface. Routes which represent ARP entries are managed by the ARP code and do not come into play here. Routes which do not represent ARP entries or other network interfaces (most commonly, the default route) are managed by this code. What happens is this: When the last reference to a cache-entry route is dropped, it enters the table-management mechanism. (If the route is referenced again before it gets deleted, it is no longer managed by this code.) At that time, the route is set up to expire some time in the future. Every so often, the code makes a sweep through the entire routing table and counts all such unreferenced routes. If any have timed out, it deletes them. If there are still more routes left in the cache than net.inet.ip.maxcache, then the maximum expiration time (net.inet.ip.rtexpire) is reduced by 25% or to net.inet.ip.rtminexpire, whichever is greater. Another sweep through the table is done to ensure that all expiration times are no greater than this new value, and the infamous message is logged indicating that this has happened. [The following discussion is for servers.] The question then turns to picking appropriate values for these parameters. You have to consider the question of how much time will pass between the drop of the last reference to a host, and the next reference to be created. If this time is very large (e.g., more than an hour), then keeping this information in the cache is not useful, since it be deleted before it is next used. You could increase the default timeout, but this is not very useful, since after an hour or more the old information is unlikely to be of relevance. It is more useful to decrease rtexpire to some small value, and set rtminexpire to the same value to prevent further decreases; I would suggest something on the order of 120 (two minutes). If the time is more reasonable, then the cache is probably doing what it was intended to do. In this case, you want to leave rtexpire and rtminexpire alone, and consider how much memory you are willing to use for the cache. As I said, figure on 256 bytes per entry, so 1024 hosts in the cache would mean 256K of non-pageable kernel memory. Set net.inet.ip.rtmaxcache to a larger value, and let the adaptation mechanism find the right expiration time for you. [This discussion is for non-servers.] For routers and workstations, the default values of these parameters should suffice. While it is certainly possible to trigger the adaptation mechanism, this does not happen very often is should be of little concern. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9603081804.AA13437>