Repository: geode Updated Branches: refs/heads/feature/GEODE-1996 [created] 168e7bac1
GEODE-1996 Confusing references to "multicast" for locators ports (wip) Project: http://git-wip-us.apache.org/repos/asf/geode/repo Commit: http://git-wip-us.apache.org/repos/asf/geode/commit/168e7bac Tree: http://git-wip-us.apache.org/repos/asf/geode/tree/168e7bac Diff: http://git-wip-us.apache.org/repos/asf/geode/diff/168e7bac Branch: refs/heads/feature/GEODE-1996 Commit: 168e7bac108c7bf141cc3e0b23a78fb28e9d384d Parents: dc6b600 Author: Dave Barnes <[email protected]> Authored: Tue May 2 17:04:04 2017 -0700 Committer: Dave Barnes <[email protected]> Committed: Tue May 2 17:04:04 2017 -0700 ---------------------------------------------------------------------- ...uted_system_member_configuration.html.md.erb | 8 +++++- ...cation_ephemeral_tcp_port_limits.html.md.erb | 9 ++++--- ...ommunication_have_enough_sockets.html.md.erb | 5 +++- ...tion_setting_socket_buffer_sizes.html.md.erb | 4 +-- ...ion_tcpip_p2p_handshake_timeouts.html.md.erb | 2 +- .../sockets_and_gateways.html.md.erb | 6 ++--- .../monitor_tune/udp_communication.html.md.erb | 26 ++++++++++++++------ .../statistics/statistics_list.html.md.erb | 2 +- 8 files changed, 42 insertions(+), 20 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/geode/blob/168e7bac/geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb b/geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb index a06a8c8..9c3fc7c 100644 --- a/geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb +++ b/geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb @@ -46,6 +46,12 @@ Every Geode process is a member of a distributed system, even if the distributed The multi-site topology uses relationships that you configure between members of multiple distributed systems. Through this configuration, you loosely couple two or more distributed systems for automated data distribution. This is usually done for sites at geographically separate locations. You configure a subset of peers in each distributed system site with gateway senders and/or gateway receivers to manage events that are distributed between the sites. -In the context of a single distributed system, unless otherwise specified, remote members refers to other members of the same distributed system. In client/server and multi-site installations, remote generally refers to members in other distributed systems. For example, all servers are remote to the clients that connect to them. Each client runs standalone, with connections only to the server tier, so all servers and their other clients are remote to the individual client. All gateway receivers are remote to the gateway senders that connect to them from other distributed systems,and to those gateway sendersâ peers. +In the context of a single distributed system, unless otherwise specified, "remote member" refers to +another member of the same distributed system. In client/server and multi-site installations, "remote" +generally refers to members in other distributed systems. For example, all servers are "remote" to the +clients that connect to them. Each client runs standalone, with connections only to the server tier, +so all servers and their other clients are "remote" to the individual client. All gateway receivers +are remote to the gateway senders that connect to them from other distributed systems, and to those +gateway senders' peers. http://git-wip-us.apache.org/repos/asf/geode/blob/168e7bac/geode-docs/managing/monitor_tune/socket_communication_ephemeral_tcp_port_limits.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/socket_communication_ephemeral_tcp_port_limits.html.md.erb b/geode-docs/managing/monitor_tune/socket_communication_ephemeral_tcp_port_limits.html.md.erb index 3df570a..05107a0 100644 --- a/geode-docs/managing/monitor_tune/socket_communication_ephemeral_tcp_port_limits.html.md.erb +++ b/geode-docs/managing/monitor_tune/socket_communication_ephemeral_tcp_port_limits.html.md.erb @@ -19,7 +19,7 @@ See the License for the specific language governing permissions and limitations under the License. --> -By default, Windowsâ ephemeral ports are within the range 1024-4999, inclusive.You can increase the range. +By default, Windowsâ ephemeral ports are within the range 1024-4999, inclusive. You can increase the range. <a id="socket_comm__section_F535D5D99206498DBBD5A6CC3230F25B"></a> If you are repeatedly receiving the following exception: @@ -28,7 +28,7 @@ If you are repeatedly receiving the following exception: java.net.BindException: Address already in use: connect ``` -and if your system is experiencing a high degree of network activity, such as numerous short-lived client connections, this could be related to a limit on the number of ephemeral TCP ports. While this issue could occur with other operating systems, typically, it is only seen with Windows due to a low default limit. +and if your system is experiencing a high degree of network activity, such as numerous short-lived client connections, this could be related to a limit on the number of ephemeral TCP ports. While this issue could occur with other operating systems, typically, it is seen only with Windows due to a low default limit. Perform this procedure to increase the limit: @@ -53,6 +53,9 @@ This affects all versions of the Windows operating system. **Note for UDP on Unix Systems** -Unix systems have a default maximum socket buffer size for receiving UDP multicast and unicast transmissions that is lower than the default settings for mcast-recv-buffer-size and udp-recv-buffer-size. To achieve high-volume multicast messaging, you should increase the maximum Unix buffer size to at least one megabyte. +Unix systems have a default maximum socket buffer size for receiving UDP multicast and unicast +transmissions that is lower than the default settings for `mcast-recv-buffer-size` and +`udp-recv-buffer-size`. To achieve high-volume multicast messaging, you should increase the maximum +Unix buffer size to at least one megabyte. http://git-wip-us.apache.org/repos/asf/geode/blob/168e7bac/geode-docs/managing/monitor_tune/socket_communication_have_enough_sockets.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/socket_communication_have_enough_sockets.html.md.erb b/geode-docs/managing/monitor_tune/socket_communication_have_enough_sockets.html.md.erb index a075e08..b86e3b8 100644 --- a/geode-docs/managing/monitor_tune/socket_communication_have_enough_sockets.html.md.erb +++ b/geode-docs/managing/monitor_tune/socket_communication_have_enough_sockets.html.md.erb @@ -27,7 +27,10 @@ Sockets use file descriptors and the operating systemâs view of your applicati You can configure socket sharing for peer-to-peer and client-to-server connections: -- **Peer-to-peer**. You can configure whether your members share sockets both at the application level and at the thread level. To enable sharing at the application level, set the `gemfire.properties` `conserve-sockets` to true. To achieve maximum throughput, however, we recommend that you set `conserve-sockets` to `false`. +- **Peer-to-peer**. You can configure whether your members share sockets both at the application +level and at the thread level. To enable sharing at the application level, set the +`gemfire.properties` property `conserve-sockets` to true. To achieve maximum throughput, however, we +recommend that you set `conserve-sockets` to `false`. At the thread level, developers can override this setting by using the DistributedSystem API method `setThreadsSocketPolicy`. You might want to enable socket sharing at the application level and then have threads that do a lot of cache work take sole ownership of their sockets. Make sure to program these threads to release their sockets as soon as possible using the `releaseThreadsSockets` method, rather than waiting for a timeout or thread death. http://git-wip-us.apache.org/repos/asf/geode/blob/168e7bac/geode-docs/managing/monitor_tune/socket_communication_setting_socket_buffer_sizes.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/socket_communication_setting_socket_buffer_sizes.html.md.erb b/geode-docs/managing/monitor_tune/socket_communication_setting_socket_buffer_sizes.html.md.erb index 41884a2..665b98b 100644 --- a/geode-docs/managing/monitor_tune/socket_communication_setting_socket_buffer_sizes.html.md.erb +++ b/geode-docs/managing/monitor_tune/socket_communication_setting_socket_buffer_sizes.html.md.erb @@ -19,11 +19,11 @@ See the License for the specific language governing permissions and limitations under the License. --> -When you determine buffer size settings, you try to strike a balance between communication needs and other processing. +When you determine buffer size settings, you must strike a balance between communication needs and other processing. Larger socket buffers allow your members to distribute data and events more quickly, but they also take memory away from other things. If you store very large data objects in your cache, finding the right sizing for your buffers while leaving enough memory for the cached data can become critical to system performance. -Ideally, you should have buffers large enough for the distribution of any single data object so you donât get message fragmentation, which lowers performance. Your buffers should be at least as large as your largest stored objects and their keys plus some overhead for message headers. The overhead varies depending on the who is sending and receiving, but 100 bytes should be sufficient. You can also look at the statistics for the communication between your processes to see how many bytes are being sent and received. +Ideally, you should have buffers large enough for the distribution of any single data object so you donât get message fragmentation, which lowers performance. Your buffers should be at least as large as your largest stored objects and their keys plus some overhead for message headers. The overhead varies depending on who is sending and receiving, but 100 bytes should be sufficient. You can also look at the statistics for the communication between your processes to see how many bytes are being sent and received. If you see performance problems and logging messages indicating blocked writers, increasing your buffer sizes may help. http://git-wip-us.apache.org/repos/asf/geode/blob/168e7bac/geode-docs/managing/monitor_tune/socket_communication_tcpip_p2p_handshake_timeouts.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/socket_communication_tcpip_p2p_handshake_timeouts.html.md.erb b/geode-docs/managing/monitor_tune/socket_communication_tcpip_p2p_handshake_timeouts.html.md.erb index 486c337..5e43531 100644 --- a/geode-docs/managing/monitor_tune/socket_communication_tcpip_p2p_handshake_timeouts.html.md.erb +++ b/geode-docs/managing/monitor_tune/socket_communication_tcpip_p2p_handshake_timeouts.html.md.erb @@ -19,7 +19,7 @@ See the License for the specific language governing permissions and limitations under the License. --> -You can alleviate connection handshake timeouts for TCP/IP connections by increasing the connection handshake timeout interval with the system property p2p.handshakeTimeoutMs. +You can alleviate connection handshake timeouts for TCP/IP connections by increasing the connection handshake timeout interval with the system property `p2p.handshakeTimeoutMs`. The default setting is 59000 milliseconds. http://git-wip-us.apache.org/repos/asf/geode/blob/168e7bac/geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb b/geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb index ca20bf8..1a3c543 100644 --- a/geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb +++ b/geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb @@ -58,7 +58,7 @@ This table lists the settings for gateway relationships and protocols, and tells **TCP/IP Buffer Sizes** -If possible, your TCP/IP buffer size settings should match across your GemFire installation. At a minimum, follow the guidelines listed here. +If possible, your TCP/IP buffer size settings should match across your installation. At a minimum, follow the guidelines listed here. - **Multisite (WAN)**. In a multi-site installation using gateways, if the link between sites is not tuned for optimum throughput, it could cause messages to back up in the cache queues. If a receiving queue overflows because of inadequate buffer sizes, it will become out of sync with the sender and the receiver will be unaware of the condition. @@ -111,11 +111,11 @@ Each gateway sender and gateway receiver uses a socket to distribute events or t </tbody> </table> -Servers are peers in their own distributed system and have the additional socket requirements as noted in the Peer-to-Peer section above. +Servers are peers in their own distributed systems and have the additional socket requirements as noted in the Peer-to-Peer section above. ## <a id="socket_comm__section_66D11C8E84F941B58800EDB52194B087" class="no-quick-link"></a>Member produces SocketTimeoutException -A client, server, gateway sender, or gateway receiver produces a SocketTimeoutException when it stops waiting for a response from the other side of the connection and closes the socket. This exception typically happens on the handshake or when establishing a callback connection. +A client, server, gateway sender, or gateway receiver produces a `SocketTimeoutException` when it stops waiting for a response from the other side of the connection and closes the socket. This exception typically happens on the handshake or when establishing a callback connection. Response: http://git-wip-us.apache.org/repos/asf/geode/blob/168e7bac/geode-docs/managing/monitor_tune/udp_communication.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/udp_communication.html.md.erb b/geode-docs/managing/monitor_tune/udp_communication.html.md.erb index 4a5d3c0..5f2f7a3 100644 --- a/geode-docs/managing/monitor_tune/udp_communication.html.md.erb +++ b/geode-docs/managing/monitor_tune/udp_communication.html.md.erb @@ -27,24 +27,34 @@ Before you begin, you should understand Geode [Basic Configuration and Programmi ## <a id="udp_comm__section_4089ACC33AF34FA888BAE3CA3602A730" class="no-quick-link"></a>UDP Datagram Size -You can change the UDP datagram size with the Geode property udp-fragment-size. This is the maximum packet size for transmission over UDP unicast or multicast sockets. When possible, smaller messages are combined into batches up to the size of this setting. +You can change the UDP datagram size with the Geode property `udp-fragment-size`. This is the maximum packet size for transmission over UDP unicast or multicast sockets. When possible, smaller messages are combined into batches up to the size of this setting. Most operating systems set a maximum transmission size of 64k for UDP datagrams, so this setting should be kept under 60k to allow for communication headers. Setting the fragment size too high can result in extra network traffic if your network is subject to packet loss, as more data must be resent for each retransmission. If many UDP retransmissions appear in DistributionStats, you maybe achieve better throughput by lowering the fragment size. ## <a id="udp_comm__section_B9882A4EBA004599B2207B9CB1D3ADC9" class="no-quick-link"></a>UDP Flow Control -UDP protocols typically have a flow control protocol built into them to keep processes from being overrun by incoming no-ack messages. The Geode UDP flow control protocol is a credit based system in which the sender has a maximum number of bytes it can send before getting its byte credit count replenished, or recharged, by its receivers. While its byte credits are too low, the sender waits. The receivers do their best to anticipate the senderâs recharge requirements and provide recharges before they are needed. If the senders credits run too low, it explicitly requests a recharge from its receivers. +UDP protocols typically have a flow control protocol built into them to keep processes from being +overrun by incoming no-ack messages. The Geode UDP flow control protocol is a credit based system in +which the sender has a maximum number of bytes it can send before getting its byte credit count +replenished, or recharged, by its receivers. While its byte credits are too low, the sender +waits. The receivers do their best to anticipate the senderâs recharge requirements and provide +recharges before they are needed. If the sender's credits run too low, it explicitly requests a +recharge from its receivers. -This flow control protocol, which is used for all multicast and unicast no-ack messaging, is configured using a three-part Geode property mcast-flow-control. This property is composed of: +This flow control protocol, which is used for all multicast and unicast no-ack messaging, is +configured using a three-part Geode property `mcast-flow-control`. This property is composed of: -- byteAllowanceâDetermines how many bytes (also referred to as credits) can be sent before receiving a recharge from the receiving processes. -- rechargeThresholdâSets a lower limit on the ratio of the senderâs remaining credit to its byteAllowance. When the ratio goes below this limit, the receiver automatically sends a recharge. This reduces recharge request messaging from the sender and helps keep the sender from blocking while waiting for recharges. -- rechargeBlockMsâTells the sender how long to wait while needing a recharge before explicitly requesting one. +- `byteAllowance`âDetermines how many bytes (also referred to as credits) can be sent before receiving a recharge from the receiving processes. +- `rechargeThreshold`âSets a lower limit on the ratio of the senderâs remaining credit to its `byteAllowance`. When the ratio goes below this limit, the receiver automatically sends a recharge. This reduces recharge request messaging from the sender and helps keep the sender from blocking while waiting for recharges. +- `rechargeBlockMs`âTells the sender how long to wait while needing a recharge before explicitly requesting one. -In a well-tuned system, where consumers of cache events are keeping up with producers, the byteAllowance can be set high to limit flow-of-control messaging and pauses. JVM bloat or frequent message retransmissions are an indication that cache events from producers are overrunning consumers. +In a well-tuned system, where consumers of cache events are keeping up with producers, the `byteAllowance` can be set high to limit flow-of-control messaging and pauses. JVM bloat or frequent message retransmissions are an indication that cache events from producers are overrunning consumers. ## <a id="udp_comm__section_FB1F54A41D2643A29DB416D309ED4C56" class="no-quick-link"></a>UDP Retransmission Statistics Geode stores retransmission statistics for its senders and receivers. You can use these statistics to help determine whether your flow control and fragment size settings are appropriate for your system. -The retransmission rates are stored in the DistributionStats ucastRetransmits and mcastRetransmits. For multicast, there is also a receiver-side statistic mcastRetransmitRequests that can be used to see which processes aren't keeping up and are requesting retransmissions. There is no comparable way to tell which receivers are having trouble receiving unicast UDP messages. +The retransmission rates are stored in the DistributionStats `ucastRetransmits` and +`mcastRetransmits`. For multicast, there is also a receiver-side statistic `mcastRetransmitRequests` +that can be used to see which processes aren't keeping up and are requesting retransmissions. There +is no comparable way to tell which receivers are having trouble receiving unicast UDP messages. http://git-wip-us.apache.org/repos/asf/geode/blob/168e7bac/geode-docs/reference/statistics/statistics_list.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/reference/statistics/statistics_list.html.md.erb b/geode-docs/reference/statistics/statistics_list.html.md.erb index 7f7b76f..c38b2f7 100644 --- a/geode-docs/reference/statistics/statistics_list.html.md.erb +++ b/geode-docs/reference/statistics/statistics_list.html.md.erb @@ -588,7 +588,7 @@ Statistics regarding operations performed on a disk region for persistence/overf ## <a id="section_ACB4161F10D64BC0B15871D003FF6FDF" class="no-quick-link"></a>Distributed System Messaging (DistributionStats) -Statistics on the Geode distribution layer. These statistcs can be used to tell how much message traffic exists between this member and other distributed system members. +Statistics on the Geode distribution layer. These statistics can be used to tell how much message traffic exists between this member and other distributed system members. The primary statistics are:
