We have a situation where the Linux NIS client generates a great amount of spurious traffic that itself negatively impacts both the client and its server.
Based on observed behavior by snooping at the NIS server, and confirmed by source code perusal, NIS clients act in the following manner: 1. Every 20 seconds, a Linux NIS client will send a request to its current NIS server it knows about to confirm that the NIS server will handle requests for the specific domain. (note, it is *not* checking simply to see if it will handle requests, but it actually wants to make sure it is handling them for this particular domain, rather than some other domains it may or may not be handling) If the NIS server does not respond within 3 seconds, or if 15 minutes has passed, the linux client will proceed to step 2. 2. Every 15 minutes, or if step #1 takes more than 3 seconds, a Linux NIS client will check all servers in the list to see if they respond to NIS requests, see if they will handle the NIS domain, and compare their responses to see which is fastest and change to use the one that is responding the fastest at that point in time. So how does all of this play out? Based on observing traffic patterns to our NIS servers, I have seen this type of thing happen: 1. Linux NIS host "A" starts sending some requests to Server 1. 2. Another process on host "A" does "ypcat passwd" (which itself takes about 3 seconds to cat to screen). 3. Normally ypcat is quite fast, but this time, it is slow. When all is said and done, host "A" decided along the way to rebind to another server, because the current one was "temporarily" slow. Now, consider 330 linux hosts on the network and 3 servers. In this scenario, many very busy hosts to the same server, or any condition that makes one server very temporarily slow, would cause on average one third of all hosts to rebind to other servers. Since this rebinding activity itself induces load, you can have scenarios where bindings bounce around for awhile before stabiliation occurs. This has been observed to actually happen. Thus, we have a minimum of 1000 requests per minute to all servers, plus any additional rebind traffic due to slow servers (I estimate 200-300 additional requests during busy times), 1300 requests generated on the 15 minute boundry, and then normal NIS traffic required by the system and applications, which in general appears to be a smaller proportion of the overall traffic. In short, linux ypbind generates a great deal of load to the NIS servers for no reason other than to be certain the server is there and responsive, and this generated load, in turn, resulting in slowing down the servers and interfering with real NIS requests for information. Has anyone else observed this behavior and if so what did you do to reduce the NIS client traffic or the load on the NIS servers? Is anyone using the no-ping option to ypbind and if so how is that working out for your network? Thanks for your response to this inquiry. -- Tom Wike Email: [EMAIL PROTECTED] ITS Design Systems Support Voice: 214-480-2272 Texas Instruments Incorporated Cell: 214-212-4497 12500 TI Boulevard, MS 8714 Pager: 972-648-2012 Dallas, TX 75243-0592 Fax: 214-480-7676 -------------------------------------------------------------------- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
