geode-docs/managing/monitor_tune/multicast_communication_runtime_considerations.html.md.erb - geode - Git at Google

 ---
 title:  Run-time Considerations for Multicast
 ---

 <!--
 Licensed to the Apache Software Foundation (ASF) under one or more
 contributor license agreements.  See the NOTICE file distributed with
 this work for additional information regarding copyright ownership.
 The ASF licenses this file to You under the Apache License, Version 2.0
 (the "License"); you may not use this file except in compliance with
 the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.
 -->

 When you use multicast for messaging and data distribution, you need to understand how the health monitoring setting works and how to control memory use.

 **Multicast Health Monitor**

 The <%=vars.product_name%> management and monitoring system is supplemented by a `maxRetransmissionRatio` health
 monitoring setting for cluster members. This ratio is the number of retransmission
 requests received divided by the number of multicast datagrams written. If the ratio is at 1.0, the
 member is retransmitting as many packets as it originally sent. Retransmissions are point-to-point,
 and many processes may request retransmission, so this number can get quite high if problems
 occur. The default value for `maxRetransmissionRatio` is 0.2.

 For example, consider a cluster with one producer and two consumers of cache events using
 multicast to transmit cache updates. The new member is added, which is running on a machine without
 multicast enabled. As a result, there is a retransmission request for every cache update, and the
 `maxRetransmissionRatio` changes to 1.0.

 **Controlling Memory Use on <%=vars.product_name%> Hosts with Multicast**

 Running out of memory can impede a member’s performance and eventually lead to severe errors.

 When data is distributed over multicast, <%=vars.product_name%> incurs a fixed overhead of memory reserved for transmission buffers. A specified amount of memory is reserved for each distributed region. These producer-side buffers are used only when a receiver is not getting enough CPU to read from its own receiving buffer as quickly as the producer is sending. In this case, the receiver complains of lost data. The producer then retrieves the data, if it still exists in its buffer, and resends to the receiver.

 Tuning the transmission buffers requires a careful balance. Larger buffers mean that more data remains available for retransmission, providing more protection in case of a problem. On the other hand, a larger amount of reserved memory means that less memory is available for caching.

 You can adjust the transmission buffer size by resetting the `mcast-send-buffer-size` parameter in the `gemfire.properties` file:

 ``` pre
 mcast-send-buffer-size=45000
 ```

 **Note:**
 The maximum buffer size is constrained only by the limits of your system. If you are not seeing problems that could be related to lack of memory then do not change the default, since it provides greater protection in case of network problems.
	---
	title: Run-time Considerations for Multicast
	---

	<!--
	Licensed to the Apache Software Foundation (ASF) under one or more
	contributor license agreements. See the NOTICE file distributed with
	this work for additional information regarding copyright ownership.
	The ASF licenses this file to You under the Apache License, Version 2.0
	(the "License"); you may not use this file except in compliance with
	the License. You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing, software
	distributed under the License is distributed on an "AS IS" BASIS,
	WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	See the License for the specific language governing permissions and
	limitations under the License.
	-->

	When you use multicast for messaging and data distribution, you need to understand how the health monitoring setting works and how to control memory use.

	Multicast Health Monitor

	The <%=vars.product_name%> management and monitoring system is supplemented by a `maxRetransmissionRatio` health
	monitoring setting for cluster members. This ratio is the number of retransmission
	requests received divided by the number of multicast datagrams written. If the ratio is at 1.0, the
	member is retransmitting as many packets as it originally sent. Retransmissions are point-to-point,
	and many processes may request retransmission, so this number can get quite high if problems
	occur. The default value for `maxRetransmissionRatio` is 0.2.

	For example, consider a cluster with one producer and two consumers of cache events using
	multicast to transmit cache updates. The new member is added, which is running on a machine without
	multicast enabled. As a result, there is a retransmission request for every cache update, and the
	`maxRetransmissionRatio` changes to 1.0.

	Controlling Memory Use on <%=vars.product_name%> Hosts with Multicast

	Running out of memory can impede a member’s performance and eventually lead to severe errors.

	When data is distributed over multicast, <%=vars.product_name%> incurs a fixed overhead of memory reserved for transmission buffers. A specified amount of memory is reserved for each distributed region. These producer-side buffers are used only when a receiver is not getting enough CPU to read from its own receiving buffer as quickly as the producer is sending. In this case, the receiver complains of lost data. The producer then retrieves the data, if it still exists in its buffer, and resends to the receiver.

	Tuning the transmission buffers requires a careful balance. Larger buffers mean that more data remains available for retransmission, providing more protection in case of a problem. On the other hand, a larger amount of reserved memory means that less memory is available for caching.

	You can adjust the transmission buffer size by resetting the `mcast-send-buffer-size` parameter in the `gemfire.properties` file:

	``` pre
	mcast-send-buffer-size=45000
	```

	Note:
	The maximum buffer size is constrained only by the limits of your system. If you are not seeing problems that could be related to lack of memory then do not change the default, since it provides greater protection in case of network problems.