| --- |
| 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. |
| |
| |