With that configuration, the relay would notify 5 clients every 6 seconds about the site update. There are several reasons you could still have more than five clients writing simultaneously -
- After being notified, the client could have its own delays due to other processing occurring at the same time. As the clients may not all delay the same amount of time, this could cause overlaps when the clients actually gather the site.
- The clients may take longer to write the site contents to disk, so that as new clients begin earlier clients are still working on it.
- The clients may be reporting to different relays. Each relay handles its own set of client notifications, so if the clients are reporting to different relays their notification schedules can overlap.
You have a few different options you can investigate. Reference the settings list at https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Configuration%20Settings
-
Ensure that the clients contending for SAN resource are reporting to the same relay. You can use manual relay selection or the client setting _BESClient_Register_Affiliation_SeekList and Relay setting _BESRelay_Register_Affiliation_AdvertisementList to “tune” the Auto-Selection process.
-
Increase the BatchDelay setting and reduce the BatchCount setting to further stagger the UDP notifications to clients.
-
Disable the client-side UDP notification entirely using _BESClient_Comm_ListenEnable, or disable the Relays’ sending of UDP notifications via Enterprise Server_ClientRegister_DisableChildUDPMessages. If you do this, you should also configure the clients to use Command Polling, using the _BESClient_Comm_CommandPollEnable and _BESClient_Comm_CommandPollIntervalSeconds client settings.
The settings that work for you will depend heavily on your SAN performance and how heavily you’ve allocated VMs to it… Unfortunately I don’t think that any of the bandwidth throttling options apply to site gathers, I think they only apply to downloads triggered by actions (but I’d welcome IBM correcting me on this). It’s counter-intuitive, but you might force the Relay’s network configuration to run at a lower speed (say, forcing 100-MB network card speed on a 1 GB Ethernet link) to make the network speed the bottleneck rather than the SAN.
I’ve not seen this issue (yet) with the Windows sites, but my Windows VMs aren’t as heavily provisioned as are our Linux VMs. But I do think part of the problem is specific to how IBM is publishing the Patches for RHEL sites - the site content is a small set of very large files, and each time one of the site files is updated the client has to download the entire file.
