http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/management/mm_overview.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/management/mm_overview.html.md.erb b/geode-docs/managing/management/mm_overview.html.md.erb index 21967cb..af4220e 100644 --- a/geode-docs/managing/management/mm_overview.html.md.erb +++ b/geode-docs/managing/management/mm_overview.html.md.erb @@ -1,6 +1,4 @@ ---- -title: Overview of Geode Management and Monitoring Tools ---- +<% set_title("Overview of", product_name, "Management and Monitoring Tools") %> <!-- Licensed to the Apache Software Foundation (ASF) under one or more @@ -19,33 +17,33 @@ See the License for the specific language governing permissions and limitations under the License. --> -Geode provides a variety of management tools you can use to manage a Geode distributed system. +<%=vars.product_name%> provides a variety of management tools you can use to manage a <%=vars.product_name%> distributed system. -The Geode management and monitoring tools allow you to configure all members and processes of a distributed system, monitor operations in the system, and start and stop the members. Internally, Geode uses Java MBeans, specifically MXBeans, to expose management controls and monitoring features. You can monitor and control Geode by writing Java programs that use these MXBeans, or you can use one of several tools provided with Geode to monitor and manage your distributed system. The primary tool for these tasks is the gfsh command-line tool, as described in this section. +The <%=vars.product_name%> management and monitoring tools allow you to configure all members and processes of a distributed system, monitor operations in the system, and start and stop the members. Internally, <%=vars.product_name%> uses Java MBeans, specifically MXBeans, to expose management controls and monitoring features. You can monitor and control <%=vars.product_name%> by writing Java programs that use these MXBeans, or you can use one of several tools provided with <%=vars.product_name%> to monitor and manage your distributed system. The primary tool for these tasks is the gfsh command-line tool, as described in this section. -Geode provides the following tools to manage a Geode installation: +<%=vars.product_name%> provides the following tools to manage a <%=vars.product_name%> installation: ## gfsh Command-line tool -The gfsh command line tool provides a set of commands you use to configure, manage, and monitor a Geode distributed system. gfsh is the recommended tool for managing your distributed system. +The gfsh command line tool provides a set of commands you use to configure, manage, and monitor a <%=vars.product_name%> distributed system. gfsh is the recommended tool for managing your distributed system. Use gfsh to: -- Start and stop Geode processes, such as locators and cache servers +- Start and stop <%=vars.product_name%> processes, such as locators and cache servers - Deploy applications - Create and destroy regions - Execute functions - Manage disk stores - Import and export data -- Monitor Geode processes -- Launch Geode monitoring tools +- Monitor <%=vars.product_name%> processes +- Launch <%=vars.product_name%> monitoring tools - Shut down a distributed system -- Script various operations involving Geode members +- Script various operations involving <%=vars.product_name%> members - Save the configuration for all members of a distributed system gfsh runs in its own shell, or you can [execute gfsh commands directly from the OS command line](../../tools_modules/gfsh/os_command_line_execution.html#topic_fpf_y1g_tp). gfsh can interact with remote systems [using the http protocol](../../configuring/cluster_config/gfsh_remote.html). You can also [write scripts that run in a gfsh shell](../../tools_modules/gfsh/command_scripting.html#concept_9B2F7550F16C4717831AD40A56922259) to automate system startup. -You can use gfsh to create shared cluster configurations for your distributed system. You can define configurations that apply to the entire cluster, or that apply only to groups of similar members that all share a common configuration. Geode locators maintain these configurations as a hidden region and distribute the configuration to all locators in the distributed system. The locator also persists the shared configurations on disk as `cluster.xml` and `cluster.properties` files. You can use those shared cluster configuration files to re-start your system, migrate the system to a new environment, add new members to a distributed system, or to restore existing members after a failure. +You can use gfsh to create shared cluster configurations for your distributed system. You can define configurations that apply to the entire cluster, or that apply only to groups of similar members that all share a common configuration. <%=vars.product_name%> locators maintain these configurations as a hidden region and distribute the configuration to all locators in the distributed system. The locator also persists the shared configurations on disk as `cluster.xml` and `cluster.properties` files. You can use those shared cluster configuration files to re-start your system, migrate the system to a new environment, add new members to a distributed system, or to restore existing members after a failure. A basic cluster configuration consists of: @@ -55,40 +53,40 @@ A basic cluster configuration consists of: See [Overview of the Cluster Configuration Service](../../configuring/cluster_config/gfsh_persist.html) and [Cluster Configuration Files and Troubleshooting](../../configuring/cluster_config/gfsh_config_troubleshooting.html#concept_ylt_2cb_y4) for additional details on gfsh cluster configuration files. -Using the gfsh tool, you can easily migrate a Geode-based application from a development environment into a testing or production environment. +Using the gfsh tool, you can easily migrate a <%=vars.product_name%>-based application from a development environment into a testing or production environment. ## Executing gfsh commands with the management API -You can also use Geode's management APIs to execute gfsh commands in a Java class. See [Executing gfsh Commands through the Management API](gfsh_and_management_api.html#concept_451F0978285245E69C3E8DE795BD8635). +You can also use <%=vars.product_name%>'s management APIs to execute gfsh commands in a Java class. See [Executing gfsh Commands through the Management API](gfsh_and_management_api.html#concept_451F0978285245E69C3E8DE795BD8635). ## Member Configuration Management -When you issue gfsh commands and have the cluster configuration service enabled (on a locator), Geode saves the configurations created within gfsh by building a `cluster.xml` and `cluster.properties` files for the entire cluster, or group of members. +When you issue gfsh commands and have the cluster configuration service enabled (on a locator), <%=vars.product_name%> saves the configurations created within gfsh by building a `cluster.xml` and `cluster.properties` files for the entire cluster, or group of members. You can also directly create configurations using `cache.xml` and `gemfire.properties` files and manage the members individually. ## Java Management Extension (JMX) MBeans -Geode uses a federated Open MBean strategy to manage and monitor all members of the distributed system. Your Java classes interact with a single MBeanServer that aggregates MBeans from other local and remote members. Using this strategy gives you a consolidated, single-agent view of the distributed system. +<%=vars.product_name%> uses a federated Open MBean strategy to manage and monitor all members of the distributed system. Your Java classes interact with a single MBeanServer that aggregates MBeans from other local and remote members. Using this strategy gives you a consolidated, single-agent view of the distributed system. -Geode's implementation of JMX is industry-standard and friendly to generic JMX clients. You can monitor or manage the distributed system by using any third-party tool that is compliant with JMX. For example, JConsole. +<%=vars.product_name%>'s implementation of JMX is industry-standard and friendly to generic JMX clients. You can monitor or manage the distributed system by using any third-party tool that is compliant with JMX. For example, JConsole. -See [Apache Geode Management and Monitoring](management_and_monitoring.html) +See [<%=vars.product_name_long%> Management and Monitoring](management_and_monitoring.html) -## Geode Java API +## <%=vars.product_name%> Java API -The Geode API provides a set of Java classes you can use to manage and monitor a distributed system. See the <span class="keyword apiname">org.apache.geode.management</span> package in the Geode JavaDocs . +The <%=vars.product_name%> API provides a set of Java classes you can use to manage and monitor a distributed system. See the <span class="keyword apiname">org.apache.geode.management</span> package in the <%=vars.product_name%> JavaDocs . -## Geode Pulse +## <%=vars.product_name%> Pulse -Geode Pulse is a Web Application that provides a graphical dashboard for monitoring vital, real-time health and performance of Geode clusters, members, and regions. +<%=vars.product_name%> Pulse is a Web Application that provides a graphical dashboard for monitoring vital, real-time health and performance of <%=vars.product_name%> clusters, members, and regions. -Use Pulse to examine total memory, CPU, and disk space used by members, uptime statistics, client connections, and critical notifications. Pulse communicates with a Geode JMX manager to provide a complete view of your Geode deployment. +Use Pulse to examine total memory, CPU, and disk space used by members, uptime statistics, client connections, and critical notifications. Pulse communicates with a <%=vars.product_name%> JMX manager to provide a complete view of your <%=vars.product_name%> deployment. -See [Geode Pulse](../../tools_modules/pulse/pulse-overview.html). +See [<%=vars.product_name%> Pulse](../../tools_modules/pulse/pulse-overview.html). ## JConsole -JConsole is a JMX monitoring utility provided with a Java Development Kit (JDK). You use gfsh to connect to Geode, and then launch JConsole with a gfsh command. The JConsole application allows you to browse MBeans, attributes, operations, and notifications. See [Browsing Geode MBeans through JConsole](mbeans_jconsole.html). +JConsole is a JMX monitoring utility provided with a Java Development Kit (JDK). You use gfsh to connect to <%=vars.product_name%>, and then launch JConsole with a gfsh command. The JConsole application allows you to browse MBeans, attributes, operations, and notifications. See [Browsing <%=vars.product_name%> MBeans through JConsole](mbeans_jconsole.html).
http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/management/notification_federation_and_alerts.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/management/notification_federation_and_alerts.html.md.erb b/geode-docs/managing/management/notification_federation_and_alerts.html.md.erb index b8ad3f6..154bff2 100644 --- a/geode-docs/managing/management/notification_federation_and_alerts.html.md.erb +++ b/geode-docs/managing/management/notification_federation_and_alerts.html.md.erb @@ -41,7 +41,7 @@ JMX Managers will emit notifications for all distributed system members with two ## <a id="topic_212EE5A2ABAB4E8E8EF71807C9ECEF1A__section_7463D13112D54406953416356835E290" class="no-quick-link"></a>System Alert Notifications -System alerts are Geode alerts wrapped within a JMX notification. The JMX Manager registers itself as an alert listener with each member of the system, and by default, it receives all messages logged with the SEVERE alert level by any node in the distributed system. Consequently, the DistributedSystemMXBean will then emit notifications for these alerts on behalf of the DistributedSystem. +System alerts are <%=vars.product_name%> alerts wrapped within a JMX notification. The JMX Manager registers itself as an alert listener with each member of the system, and by default, it receives all messages logged with the SEVERE alert level by any node in the distributed system. Consequently, the DistributedSystemMXBean will then emit notifications for these alerts on behalf of the DistributedSystem. By default, the JMX Manager registers itself to send notifications only for SEVERE level alerts. To change the alert level that the JMX Manager will send notifications for, use the `DistributedMXBean.changeAlertLevel` method. Possible alert levels to set are WARNING, ERROR, SEVERE, and NONE. After changing the level, the JMX Manager will only emit that level of log message as notifications. http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/member-reconnect.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/member-reconnect.html.md.erb b/geode-docs/managing/member-reconnect.html.md.erb new file mode 100644 index 0000000..16717ce --- /dev/null +++ b/geode-docs/managing/member-reconnect.html.md.erb @@ -0,0 +1,83 @@ +--- +title: Handling Forced Cache Disconnection Using Autoreconnect +--- + +<!-- +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. +--> + +A <%=vars.product_name%> member may be forcibly disconnected from a <%=vars.product_name%> distributed system if the member is unresponsive for a period of time, or if a network partition separates one or more members into a group that is too small to act as the distributed system. + +## How the Autoreconnection Process Works + +After being disconnected from a distributed system, +a <%=vars.product_name%> member shuts down and, by default, automatically restarts into +a "reconnecting" state, +while periodically attempting to rejoin the distributed system +by contacting a list of known locators. +If the member succeeds in reconnecting to a known locator, the member rebuilds its view of the distributed system from existing members and receives a new distributed member ID. + +If the member cannot connect to a known locator, the member will then check to see if it itself is a locator (or hosting an embedded locator process). If the member is a locator, then the member does a quorum-based reconnect; it will attempt to contact a quorum of the members that were in the membership view just before it became disconnected. If a quorum of members can be contacted, then startup of the distributed system is allowed to begin. Since the reconnecting member does not know which members survived the network partition event, all members that are in a reconnecting state will keep their UDP unicast ports open and respond to ping requests. + +Membership quorum is determined using the same member weighting system used in network partition detection. See [Membership Coordinators, Lead Members and Member Weighting](network_partitioning/membership_coordinators_lead_members_and_weighting.html#concept_23C2606D59754106AFBFE17515DF4330). + +Note that when a locator is in the reconnecting state, +it provides no discovery services for the distributed system. + +The default settings for reconfiguration of the cache once +reconnected assume that the cluster configuration service has +a valid (XML) configuration. +This will not be the case if the cluster was configured using +API calls. +To handle this case, +either disable autoreconnect by setting the property to + +``` +disable-auto-reconnect = true +``` + +or, disable the cluster configuration service by setting the property to + +``` +enable-cluster-configuration = false +``` + +After the cache has reconnected, applications must fetch a reference to the new Cache, Regions, DistributedSystem and other artifacts. Old references will continue to throw cancellation exceptions like `CacheClosedException(cause=ForcedDisconnectException)`. + +See the <%=vars.product_name%> `DistributedSystem` and `Cache` Java API documentation for more information. + +## Managing the Autoreconnection Process + +By default a <%=vars.product_name%> member will try to reconnect until it is told to stop by using the `DistributedSystem.stopReconnecting()` or `Cache.stopReconnecting()` method. You can disable automatic reconnection entirely by setting `disable-auto-reconnect` <%=vars.product_name%> property to "true." + +You can use `DistributedSystem` and `Cache` callback methods to perform actions during the reconnect process, or to cancel the reconnect process if necessary. + +The `DistributedSystem` and `Cache` API provide several methods you can use to take actions while a member is reconnecting to the distributed system: + +- `DistributedSystem.isReconnecting()` returns true if the member is in the process of reconnecting and recreating the cache after having been removed from the system by other members. +- `DistributedSystem.waitUntilReconnected(long, TimeUnit)` waits for a period of time, and then returns a boolean value to indicate whether the member has reconnected to the DistributedSystem. Use a value of -1 seconds to wait indefinitely until the reconnect completes or the member shuts down. Use a value of 0 seconds as a quick probe to determine if the member has reconnected. +- `DistributedSystem.getReconnectedSystem()` returns the reconnected DistributedSystem. +- `DistributedSystem.stopReconnecting()` stops the reconnection process and ensures that the DistributedSystem stays in a disconnected state. +- `Cache.isReconnecting()` returns true if the cache is attempting to reconnect to a distributed system. +- `Cache.waitForReconnect(long, TimeUnit)` waits for a period of time, and then returns a boolean value to indicate whether the DistributedSystem has reconnected. Use a value of -1 seconds to wait indefinitely until the reconnect completes or the cache shuts down. Use a value of 0 seconds as a quick probe to determine if the member has reconnected. +- `Cache.getReconnectedCache()` returns the reconnected Cache. +- `Cache.stopReconnecting()` stops the reconnection process and ensures that the DistributedSystem stays in a disconnected state. + +## Operator Intervention + +You may need to intervene in the autoreconnection process if processes or hardware have crashed or are otherwise shut down before the network connection is healed. In this case the members in a "reconnecting" state will not be able to find the lost processes through UDP probes and will not rejoin the system until they are able to contact a locator. + + http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/cache_consistency.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/cache_consistency.html.md.erb b/geode-docs/managing/monitor_tune/cache_consistency.html.md.erb index adc10c9..86fbc52 100644 --- a/geode-docs/managing/monitor_tune/cache_consistency.html.md.erb +++ b/geode-docs/managing/monitor_tune/cache_consistency.html.md.erb @@ -19,7 +19,7 @@ See the License for the specific language governing permissions and limitations under the License. --> -Maintaining data consistency between caches in a distributed Geode system is vital for ensuring its functional integrity and preventing data loss. +Maintaining data consistency between caches in a distributed <%=vars.product_name%> system is vital for ensuring its functional integrity and preventing data loss. ## <a id="cache_const__section_lf3_lvn_nr" class="no-quick-link"></a>General Guidelines @@ -28,7 +28,7 @@ Maintaining data consistency between caches in a distributed Geode system is vit **Note:** If you revoke a memberâs disk store, do not restart that member with its disk storesâin isolationâat a later time. -Geode stores information about your persisted data and prevents you from starting a member with a revoked disk store in the running system. But Geode cannot stop you from starting a revoked member in isolation, and running with its revoked data. This is an unlikely situation, but it is possible to do: +<%=vars.product_name%> stores information about your persisted data and prevents you from starting a member with a revoked disk store in the running system. But <%=vars.product_name%> cannot stop you from starting a revoked member in isolation, and running with its revoked data. This is an unlikely situation, but it is possible to do: 1. Members A and B are running, both storing Region data to disk. 2. Member A goes down. @@ -43,7 +43,7 @@ Geode stores information about your persisted data and prevents you from startin **Understand Cache Transactions** -Understanding the operation of Geode transactions can help you minimize situations where the cache could get out of sync. +Understanding the operation of <%=vars.product_name%> transactions can help you minimize situations where the cache could get out of sync. Transactions do not work in distributed regions with global scope. @@ -59,7 +59,7 @@ If a cache writer exists during a transaction, then each transaction write opera A region in a cache with transactions may not stay in sync with a region of the same name in another cache without transactions. -Two applications running the same sequence of operations in their transactions may get different results. This could occur because operations happening outside a transaction in one of the members can overwrite the transaction, even in the process of committing. This could also occur if the results of a large transaction exceed the machineâs memory or the capacity of Geode. Those limits can vary by machine, so the two members may not be in sync. +Two applications running the same sequence of operations in their transactions may get different results. This could occur because operations happening outside a transaction in one of the members can overwrite the transaction, even in the process of committing. This could also occur if the results of a large transaction exceed the machineâs memory or the capacity of <%=vars.product_name%>. Those limits can vary by machine, so the two members may not be in sync. ## <a id="cache_const__section_qxx_kvn_nr" class="no-quick-link"></a>Guidelines for Multi-Site Deployments http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/chapter_overview.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/chapter_overview.html.md.erb b/geode-docs/managing/monitor_tune/chapter_overview.html.md.erb index 34f88f9..8f7e921 100644 --- a/geode-docs/managing/monitor_tune/chapter_overview.html.md.erb +++ b/geode-docs/managing/monitor_tune/chapter_overview.html.md.erb @@ -19,42 +19,42 @@ See the License for the specific language governing permissions and limitations under the License. --> -A collection of tools and controls allow you to monitor and adjust Apache Geode performance. +A collection of tools and controls allow you to monitor and adjust <%=vars.product_name_long%> performance. -- **[Improving Performance on vSphere](../../managing/monitor_tune/performance_on_vsphere.html)** +- **[Improving Performance on vSphere](performance_on_vsphere.html)** - This topic provides guidelines for tuning vSphere virtualized environments that host Apache Geode deployments. + This topic provides guidelines for tuning vSphere virtualized environments that host <%=vars.product_name_long%> deployments. -- **[Performance Controls](../../managing/monitor_tune/performance_controls.html)** +- **[Performance Controls](performance_controls.html)** This topic provides tuning suggestions of particular interest to developers, primarily programming techniques and cache configuration. -- **[System Member Performance](../../managing/monitor_tune/system_member_performance.html)** +- **[System Member Performance](system_member_performance.html)** You can modify some configuration parameters to improve system member performance. -- **[Slow Receivers with TCP/IP](../../managing/monitor_tune/slow_receivers.html)** +- **[Slow Receivers with TCP/IP](slow_receivers.html)** You have several options for preventing situations that can cause slow receivers of data distributions. The slow receiver options control only peer-to-peer communication using TCP/IP. This discussion does not apply to client/server or multi-site communication, or to communication using the UDP unicast or multicast protocols. -- **[Slow distributed-ack Messages](../../managing/monitor_tune/slow_messages.html)** +- **[Slow distributed-ack Messages](slow_messages.html)** In systems with distributed-ack regions, a sudden large number of distributed-no-ack operations can cause distributed-ack operations to take a long time to complete. -- **[Socket Communication](../../managing/monitor_tune/socket_communication.html)** +- **[Socket Communication](socket_communication.html)** - Geode processes communicate using TCP/IP and UDP unicast and multicast protocols. In all cases, communication uses sockets that you can tune to optimize performance. + <%=vars.product_name%> processes communicate using TCP/IP and UDP unicast and multicast protocols. In all cases, communication uses sockets that you can tune to optimize performance. -- **[UDP Communication](../../managing/monitor_tune/udp_communication.html)** +- **[UDP Communication](udp_communication.html)** You can make configuration adjustments to improve multicast and unicast UDP performance of peer-to-peer communication. -- **[Multicast Communication](../../managing/monitor_tune/multicast_communication.html)** +- **[Multicast Communication](multicast_communication.html)** - You can make configuration adjustments to improve the UDP multicast performance of peer-to-peer communication in your Geode system. + You can make configuration adjustments to improve the UDP multicast performance of peer-to-peer communication in your <%=vars.product_name%> system. -- **[Maintaining Cache Consistency](../../managing/monitor_tune/cache_consistency.html)** +- **[Maintaining Cache Consistency](cache_consistency.html)** - Maintaining data consistency between caches in a distributed Geode system is vital for ensuring its functional integrity and preventing data loss. + Maintaining data consistency between caches in a distributed <%=vars.product_name%> system is vital for ensuring its functional integrity and preventing data loss. http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/multicast_communication.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/multicast_communication.html.md.erb b/geode-docs/managing/monitor_tune/multicast_communication.html.md.erb index ba823c6..9b87b9a 100644 --- a/geode-docs/managing/monitor_tune/multicast_communication.html.md.erb +++ b/geode-docs/managing/monitor_tune/multicast_communication.html.md.erb @@ -19,27 +19,27 @@ See the License for the specific language governing permissions and limitations under the License. --> -You can make configuration adjustments to improve the UDP multicast performance of peer-to-peer communication in your Geode system. +You can make configuration adjustments to improve the UDP multicast performance of peer-to-peer communication in your <%=vars.product_name%> system. -Before you begin, you should understand Geode [Basic Configuration and Programming](../../basic_config/book_intro.html). See also the general communication tuning and UDP tuning covered in [Socket Communication](socket_communication.html) and [UDP Communication](udp_communication.html#udp_comm). +Before you begin, you should understand <%=vars.product_name%> [Basic Configuration and Programming](../../basic_config/book_intro.html). See also the general communication tuning and UDP tuning covered in [Socket Communication](socket_communication.html) and [UDP Communication](udp_communication.html#udp_comm). -- **[Provisioning Bandwidth for Multicast](../../managing/monitor_tune/multicast_communication_provisioning_bandwidth.html)** +- **[Provisioning Bandwidth for Multicast](multicast_communication_provisioning_bandwidth.html)** Multicast installations require more planning and configuration than TCP installations. With IP multicast, you gain scalability but lose the administrative convenience of TCP. -- **[Testing Multicast Speed Limits](../../managing/monitor_tune/multicast_communication_testing_multicast_speed_limits.html)** +- **[Testing Multicast Speed Limits](multicast_communication_testing_multicast_speed_limits.html)** TCP automatically adjusts its speed to the capability of the processes using it and enforces bandwidth sharing so that every process gets a turn. With multicast, you must determine and explicitly set those limits. -- **[Configuring Multicast Speed Limits](../../managing/monitor_tune/multicast_communication_configuring_speed_limits.html)** +- **[Configuring Multicast Speed Limits](multicast_communication_configuring_speed_limits.html)** After you determine the maximum transmission rate, configure and tune your production system. -- **[Run-time Considerations for Multicast](../../managing/monitor_tune/multicast_communication_runtime_considerations.html)** +- **[Run-time Considerations for Multicast](multicast_communication_runtime_considerations.html)** 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. -- **[Troubleshooting the Multicast Tuning Process](../../managing/monitor_tune/multicast_communication_troubleshooting.html)** +- **[Troubleshooting the Multicast Tuning Process](multicast_communication_troubleshooting.html)** Several problems may arise during the initial testing and tuning process for multicasting. http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/multicast_communication_configuring_speed_limits.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/multicast_communication_configuring_speed_limits.html.md.erb b/geode-docs/managing/monitor_tune/multicast_communication_configuring_speed_limits.html.md.erb index a6cb090..5de92bd 100644 --- a/geode-docs/managing/monitor_tune/multicast_communication_configuring_speed_limits.html.md.erb +++ b/geode-docs/managing/monitor_tune/multicast_communication_configuring_speed_limits.html.md.erb @@ -42,7 +42,7 @@ For best performance, the producer and the consumers should run on different mac - Monitor the members that receive data for signs of data loss. A few data loss messages can happen normally during region creation. Multicast retransmit requests and unicast retransmits can also be monitored to detect data loss. Even when you see data loss, the cause of the problem may have nothing to do with the network. However, if it happens constantly then you should try testing the flow control rate again - If necessary, reconfigure all the `gemfire.properties` files and repeat with lower flow control maximum credits until you find the maximum useful rate for your installation. - Slow system performance might be helped by reducing how far your multicast messaging goes in your network. -- Reduce multicast latency by disabling batching. By default, Geode uses batching for operations when the regionâs scope is distributed-no-ack. Set the `disableBatching` property to true on the application or when starting a cache server process through the `gfsh` command line: +- Reduce multicast latency by disabling batching. By default, <%=vars.product_name%> uses batching for operations when the regionâs scope is distributed-no-ack. Set the `disableBatching` property to true on the application or when starting a cache server process through the `gfsh` command line: ``` pre gfsh>start server --name=server_name --J=-Dp2p.disableBatching=true http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/multicast_communication_runtime_considerations.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/multicast_communication_runtime_considerations.html.md.erb b/geode-docs/managing/monitor_tune/multicast_communication_runtime_considerations.html.md.erb index 2468e47..5e98c0b 100644 --- a/geode-docs/managing/monitor_tune/multicast_communication_runtime_considerations.html.md.erb +++ b/geode-docs/managing/monitor_tune/multicast_communication_runtime_considerations.html.md.erb @@ -23,7 +23,7 @@ When you use multicast for messaging and data distribution, you need to understa **Multicast Health Monitor** -The Geode management and monitoring system is supplemented by a `maxRetransmissionRatio` health +The <%=vars.product_name%> management and monitoring system is supplemented by a `maxRetransmissionRatio` health monitoring setting for distributed system 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, @@ -35,11 +35,11 @@ multicast to transmit cache updates. The new member is added, which is running o 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 Geode Hosts with Multicast** +**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, Geode 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. +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. http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/multicast_communication_testing_multicast_speed_limits.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/multicast_communication_testing_multicast_speed_limits.html.md.erb b/geode-docs/managing/monitor_tune/multicast_communication_testing_multicast_speed_limits.html.md.erb index 1e8faa7..a2a432a 100644 --- a/geode-docs/managing/monitor_tune/multicast_communication_testing_multicast_speed_limits.html.md.erb +++ b/geode-docs/managing/monitor_tune/multicast_communication_testing_multicast_speed_limits.html.md.erb @@ -119,7 +119,7 @@ where: </table> **Note:** -If your Geode distributed system runs across several subnets, start a receiver on each subnet. +If your <%=vars.product_name%> distributed system runs across several subnets, start a receiver on each subnet. In the receiverâs output, look at the Lost/Total Datagrams columns for the number and percentage of lost packets out of the total sent. http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/performance_controls.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/performance_controls.html.md.erb b/geode-docs/managing/monitor_tune/performance_controls.html.md.erb index ddc713c..b8815c2 100644 --- a/geode-docs/managing/monitor_tune/performance_controls.html.md.erb +++ b/geode-docs/managing/monitor_tune/performance_controls.html.md.erb @@ -21,25 +21,25 @@ limitations under the License. This topic provides tuning suggestions of particular interest to developers, primarily programming techniques and cache configuration. -Before you begin, you should understand Apache Geode [Basic Configuration and Programming](../../basic_config/book_intro.html). +Before you begin, you should understand <%=vars.product_name_long%> [Basic Configuration and Programming](../../basic_config/book_intro.html). -- **[Data Serialization](../../managing/monitor_tune/performance_controls_data_serialization.html)** +- **[Data Serialization](performance_controls_data_serialization.html)** - In addition to standard Java serialization, Geode offers serialization options that give you higher performance and greater flexibility for data storage, transfers, and language types. + In addition to standard Java serialization, <%=vars.product_name%> offers serialization options that give you higher performance and greater flexibility for data storage, transfers, and language types. -- **[Setting Cache Timeouts](../../managing/monitor_tune/performance_controls_setting_cache_timeouts.html)** +- **[Setting Cache Timeouts](performance_controls_setting_cache_timeouts.html)** Cache timeout properties can modified through the gfsh `alter runtime` command (or declared in the `cache.xml` file) and can also be set through methods of the interface, `org.apache.geode.cache.Cache`. -- **[Controlling Socket Use](../../managing/monitor_tune/performance_controls_controlling_socket_use.html)** +- **[Controlling Socket Use](performance_controls_controlling_socket_use.html)** For peer-to-peer communication, you can manage socket use at the system member level and at the thread level. -- **[Management of Slow Receivers](../../managing/monitor_tune/performance_controls_managing_slow_receivers.html)** +- **[Management of Slow Receivers](performance_controls_managing_slow_receivers.html)** You have several options for handling slow members that receive data distribution. The slow receiver options control only to peer-to-peer communication between distributed regions using TCP/IP. This topic does not apply to client/server or multi-site communication, or to communication using the UDP unicast or IP multicast protocols. -- **[Increasing the Ratio of Cache Hits](../../managing/monitor_tune/performance_controls_increasing_cache_hits.html)** +- **[Increasing the Ratio of Cache Hits](performance_controls_increasing_cache_hits.html)** The more frequently a get fails to find a valid value in the first cache and has to try a second cache, the more the overall performance is affected. http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/performance_controls_data_serialization.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/performance_controls_data_serialization.html.md.erb b/geode-docs/managing/monitor_tune/performance_controls_data_serialization.html.md.erb index 139f1bb..dd1d4f2 100644 --- a/geode-docs/managing/monitor_tune/performance_controls_data_serialization.html.md.erb +++ b/geode-docs/managing/monitor_tune/performance_controls_data_serialization.html.md.erb @@ -19,8 +19,8 @@ See the License for the specific language governing permissions and limitations under the License. --> -In addition to standard Java serialization, Geode offers serialization options that give you higher performance and greater flexibility for data storage, transfers, and language types. +In addition to standard Java serialization, <%=vars.product_name%> offers serialization options that give you higher performance and greater flexibility for data storage, transfers, and language types. -Under *Developing with Apache Geode*, see [Data Serialization](../../developing/data_serialization/chapter_overview.html#data_serialization). +Under *Developing with <%=vars.product_name_long%>*, see [Data Serialization](../../developing/data_serialization/chapter_overview.html#data_serialization). http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/performance_on_vsphere.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/performance_on_vsphere.html.md.erb b/geode-docs/managing/monitor_tune/performance_on_vsphere.html.md.erb index ac6fa85..921a819 100644 --- a/geode-docs/managing/monitor_tune/performance_on_vsphere.html.md.erb +++ b/geode-docs/managing/monitor_tune/performance_on_vsphere.html.md.erb @@ -23,7 +23,7 @@ limitations under the License. Use the latest supported version of the guest OS, and use Java large paging. -- **Use the latest supported version of the guest operating system**. This guideline is probably the most important. Upgrade the guest OS to a recent version supported by Geode. For example, for RHEL, use at least version 7.0 or for SLES, use at least 11.0. For Windows, use Windows Server 2012. For RedHat Linux users, it is particularly beneficial to use RHEL 7 since there are specific enhancements in the RHEL 7 release that improve virtualized latency sensitive workloads. +- **Use the latest supported version of the guest operating system**. This guideline is probably the most important. Upgrade the guest OS to a recent version supported by <%=vars.product_name%>. For example, for RHEL, use at least version 7.0 or for SLES, use at least 11.0. For Windows, use Windows Server 2012. For RedHat Linux users, it is particularly beneficial to use RHEL 7 since there are specific enhancements in the RHEL 7 release that improve virtualized latency sensitive workloads. - **Use Java large paging in guest OS**. Configure Java on the guest OS to use large pages. Add the following command line option when launching Java: ``` pre @@ -35,7 +35,7 @@ Use the latest supported version of the guest OS, and use Java large paging. This section provides VMware- recommended NUMA, CPU, and BIOS settings for your hardware and virtual machines. - Always enable hyper-threading, and do not overcommit CPU. -- For most production Apache Geode servers, always use virtual machines with at least two vCPUs . +- For most production <%=vars.product_name_long%> servers, always use virtual machines with at least two vCPUs . - Apply non-uniform memory access (NUMA) locality by sizing virtual machines to fit within the NUMA node. - VMware recommends the following BIOS settings: - **BIOS Power Management Mode:** Maximum Performance. @@ -82,45 +82,45 @@ These guidelines help you reduce latency. This topic discusses use limitations of vSphere vMotion, including the use of it with DRS. - When you first commission the data management system, place VMware vSphere Distributed Resource Scheduler⢠(DRS) in manual mode to prevent an automatic VMware vSphere vMotion® operation that can affect response times. -- Reduce or eliminate the use of vMotion to migrate Geode virtual machines when they are under heavy load. -- Do not allow vMotion migrations with Apache Geode locator processes, as the latency introduced to this process can cause other members of the Apache Geode servers to falsely suspect that other members are dead. -- Use dedicated Apache Geode vSphere DRS clusters. This is especially important when you consider that the physical NIC and virtual NIC are specifically tuned to disable Interrupt Coalescing on every NIC of an ESXi host in the cluster. This type of tuning benefits Geode workloads, but it can hurt other non-Apache Geode workloads that are memory throughput-bound as opposed to latency sensitive as in the case of Apache Geode workloads. -- If using a dedicated vSphere DRS cluster is not an option, and Apache Geode must run in a shared DRS cluster, make sure that DRS rules are set up not to perform vMotion migrations on Geode virtual machines. -- If you must use vMotion for migration, VMware recommends that all vMotion migration activity of Apache Geode members occurs over 10GbE, during periods of low activity and scheduled maintenance windows. +- Reduce or eliminate the use of vMotion to migrate <%=vars.product_name%> virtual machines when they are under heavy load. +- Do not allow vMotion migrations with <%=vars.product_name_long%> locator processes, as the latency introduced to this process can cause other members of the <%=vars.product_name_long%> servers to falsely suspect that other members are dead. +- Use dedicated <%=vars.product_name_long%> vSphere DRS clusters. This is especially important when you consider that the physical NIC and virtual NIC are specifically tuned to disable Interrupt Coalescing on every NIC of an ESXi host in the cluster. This type of tuning benefits <%=vars.product_name%> workloads, but it can hurt other non-<%=vars.product_name_long%> workloads that are memory throughput-bound as opposed to latency sensitive as in the case of <%=vars.product_name_long%> workloads. +- If using a dedicated vSphere DRS cluster is not an option, and <%=vars.product_name_long%> must run in a shared DRS cluster, make sure that DRS rules are set up not to perform vMotion migrations on <%=vars.product_name%> virtual machines. +- If you must use vMotion for migration, VMware recommends that all vMotion migration activity of <%=vars.product_name_long%> members occurs over 10GbE, during periods of low activity and scheduled maintenance windows. ## <a id="topic_E53BBF3D09A54953B02DCE2BD00D51E0" class="no-quick-link"></a>Placement and Organization of Virtual Machines This section provides guidelines on JVM instances and placement of redundant copies of cached data. - Have one JVM instance per virtual machine. -- Increasing the heap space to service the demand for more data is better than installing a second instance of a JVM on a single virtual machine. If increasing the JVM heap size is not an option, consider placing the second JVM on a separate newly created virtual machine, thus promoting more effective horizontal scalability. As you increase the number of Apache Geode servers, also increase the number of virtual machines to maintain a 1:1:1 ratio among the Apache Geode server, the JVM, and the virtual machines. -- Size for a minimum of four vCPU virtual machines with one Apache Geode server running in one JVM instance. This allows ample CPU cycles for the garbage collector, and the rest for user transactions. -- Because Apache Geode can place redundant copies of cached data on any virtual machine, it is possible to inadvertently place two redundant data copies on the same ESX/ESXi host. This is not optimal if a host fails. To create a more robust configuration, use VM1-to-VM2 anti-affinity rules, to indicate to vSphere that VM1 and VM2 can never be placed on the same host because they hold redundant data copies. +- Increasing the heap space to service the demand for more data is better than installing a second instance of a JVM on a single virtual machine. If increasing the JVM heap size is not an option, consider placing the second JVM on a separate newly created virtual machine, thus promoting more effective horizontal scalability. As you increase the number of <%=vars.product_name_long%> servers, also increase the number of virtual machines to maintain a 1:1:1 ratio among the <%=vars.product_name_long%> server, the JVM, and the virtual machines. +- Size for a minimum of four vCPU virtual machines with one <%=vars.product_name_long%> server running in one JVM instance. This allows ample CPU cycles for the garbage collector, and the rest for user transactions. +- Because <%=vars.product_name_long%> can place redundant copies of cached data on any virtual machine, it is possible to inadvertently place two redundant data copies on the same ESX/ESXi host. This is not optimal if a host fails. To create a more robust configuration, use VM1-to-VM2 anti-affinity rules, to indicate to vSphere that VM1 and VM2 can never be placed on the same host because they hold redundant data copies. ## <a id="topic_567308E9DE07406BB5BF420BE77B6558" class="no-quick-link"></a>Virtual Machine Memory Reservation This section provides guidelines for sizing and setting memory. - Set memory reservation at the virtual machine level so that ESXi provides and locks down the needed physical memory upon virtual machine startup. Once allocated, ESXi does not allow the memory to be taken away. -- Do not overcommit memory for Geode hosts. -- When sizing memory for a Geode server within one JVM on one virtual machine, the total reserved memory for the virtual machine should not exceed what is available within one NUMA node for optimal performance. +- Do not overcommit memory for <%=vars.product_name%> hosts. +- When sizing memory for a <%=vars.product_name%> server within one JVM on one virtual machine, the total reserved memory for the virtual machine should not exceed what is available within one NUMA node for optimal performance. -## <a id="topic_424B940584044CF6A685E86802548A27" class="no-quick-link"></a>vSphere High Availability and Apache Geode +## <a id="topic_424B940584044CF6A685E86802548A27" class="no-quick-link"></a>vSphere High Availability and <%=vars.product_name_long%> -On Apache Geode virtual machines, disable vSphere High Availability (HA). +On <%=vars.product_name_long%> virtual machines, disable vSphere High Availability (HA). -If you are using a dedicated Apache Geode DRS cluster, then you can disable HA across the cluster. However, if you are using a shared cluster, exclude Geode virtual machines from vSphere HA. +If you are using a dedicated <%=vars.product_name_long%> DRS cluster, then you can disable HA across the cluster. However, if you are using a shared cluster, exclude <%=vars.product_name%> virtual machines from vSphere HA. -Additionally, to support high availability, you can also set up anti-affinity rules between the Apache Geode virtual machines to prevent two Apache Geode servers from running on the same ESXi host within the same DRS cluster. +Additionally, to support high availability, you can also set up anti-affinity rules between the <%=vars.product_name_long%> virtual machines to prevent two <%=vars.product_name_long%> servers from running on the same ESXi host within the same DRS cluster. ## <a id="topic_913B15841C4249A68697F3D91281A645" class="no-quick-link"></a>Storage Guidelines This section provides storage guidelines for persistence files, binaries, logs, and more. -- Use the PVSCSI driver for I/O intensive Apache Geode workloads. +- Use the PVSCSI driver for I/O intensive <%=vars.product_name_long%> workloads. - Align disk partitions at the VMFS and guest operating system levels. -- Provision VMDK files as eagerzeroedthick to avoid lazy zeroing for Apache Geode members. -- Use separate VMDKs for Apache Geode persistence files, binaries, and logs. +- Provision VMDK files as eagerzeroedthick to avoid lazy zeroing for <%=vars.product_name_long%> members. +- Use separate VMDKs for <%=vars.product_name_long%> persistence files, binaries, and logs. - Map a dedicated LUN to each VMDK. - For Linux virtual machines, use NOOP scheduling as the I/O scheduler instead of Completely Fair Queuing (CFQ). Starting with the Linux kernel 2.6, CFQ is the default I/O scheduler in many Linux distributions. See [http://kb.vmware.com/kb/2011861](http://kb.vmware.com/kb/2011861) for more information. http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/slow_messages.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/slow_messages.html.md.erb b/geode-docs/managing/monitor_tune/slow_messages.html.md.erb index 7150802..20e8676 100644 --- a/geode-docs/managing/monitor_tune/slow_messages.html.md.erb +++ b/geode-docs/managing/monitor_tune/slow_messages.html.md.erb @@ -30,7 +30,7 @@ The main reasons why a large number of `distributed-no-ack` messages may delay ` You can take these steps to reduce the impact of this problem: -1. If youâre using TCP, check whether you have socket conservation enabled for your members. It is configured by setting the Geode property `conserve-sockets` to true. If enabled, each applicationâs threads will share sockets unless you override the setting at the thread level. Work with your application programmers to see whether you might disable sharing entirely or at least for the threads that perform `distributed-ack` operations. These include operations on `distributed-ack` regions and also `netSearches` performed on regions of any distributed scope. (Note: `netSearch` is only performed on regions with a data-policy of empty, normal and preloaded.) If you give each thread that performs `distributed-ack` operations its own socket, you effectively let it scoot to the front of the line ahead of the `distributed-no-ack` operations that are being performed by other threads. The thread-level override is done by calling the `DistributedSystem.setThreadsSocketPolicy(false)` metho d. +1. If youâre using TCP, check whether you have socket conservation enabled for your members. It is configured by setting the <%=vars.product_name%> property `conserve-sockets` to true. If enabled, each applicationâs threads will share sockets unless you override the setting at the thread level. Work with your application programmers to see whether you might disable sharing entirely or at least for the threads that perform `distributed-ack` operations. These include operations on `distributed-ack` regions and also `netSearches` performed on regions of any distributed scope. (Note: `netSearch` is only performed on regions with a data-policy of empty, normal and preloaded.) If you give each thread that performs `distributed-ack` operations its own socket, you effectively let it scoot to the front of the line ahead of the `distributed-no-ack` operations that are being performed by other threads. The thread-level override is done by calling the `DistributedSystem.setThreadsSocketPol icy(false)` method. 2. Reduce your buffer sizes to slow down the distributed-no-ack operations. These changes slow down the threads performing distributed-no-ack operations and allow the thread doing the distributed-ack operations to be sent in a more timely manner. - If you're using UDP (you either have multicast enabled regions or have set `disable-tcp` to true in gemfire.properties), consider reducing the byteAllowance of mcast-flow-control to something smaller than the default of 3.5 megabytes. - If you're using TCP/IP, reduce the `socket-buffer-size` in gemfire.properties. http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/slow_receivers.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/slow_receivers.html.md.erb b/geode-docs/managing/monitor_tune/slow_receivers.html.md.erb index 5e4aebe..88e0ded 100644 --- a/geode-docs/managing/monitor_tune/slow_receivers.html.md.erb +++ b/geode-docs/managing/monitor_tune/slow_receivers.html.md.erb @@ -21,13 +21,13 @@ limitations under the License. You have several options for preventing situations that can cause slow receivers of data distributions. The slow receiver options control only peer-to-peer communication using TCP/IP. This discussion does not apply to client/server or multi-site communication, or to communication using the UDP unicast or multicast protocols. -Before you begin, you should understand Geode [Basic Configuration and Programming](../../basic_config/book_intro.html). +Before you begin, you should understand <%=vars.product_name%> [Basic Configuration and Programming](../../basic_config/book_intro.html). -- **[Preventing Slow Receivers](../../managing/monitor_tune/slow_receivers_preventing_problems.html)** +- **[Preventing Slow Receivers](slow_receivers_preventing_problems.html)** During system integration, you can identify and eliminate potential causes of slow receivers in peer-to-peer communication. -- **[Managing Slow Receivers](../../managing/monitor_tune/slow_receivers_managing.html)** +- **[Managing Slow Receivers](slow_receivers_managing.html)** If the receiver fails to receive a message, the sender continues to attempt to deliver the message as long as the receiving member is still in the distributed system. http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/slow_receivers_managing.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/slow_receivers_managing.html.md.erb b/geode-docs/managing/monitor_tune/slow_receivers_managing.html.md.erb index 49e93c4..de3bcfa 100644 --- a/geode-docs/managing/monitor_tune/slow_receivers_managing.html.md.erb +++ b/geode-docs/managing/monitor_tune/slow_receivers_managing.html.md.erb @@ -21,7 +21,7 @@ limitations under the License. If the receiver fails to receive a message, the sender continues to attempt to deliver the message as long as the receiving member is still in the distributed system. -During the retry cycle, Geode throws warnings that include this string: +During the retry cycle, <%=vars.product_name%> throws warnings that include this string: ``` pre will reattempt @@ -69,7 +69,7 @@ When a process disconnects after receiving a request to do so by a producer, it These messages only appear in your logs if logging is enabled and the log level is set to a level that includes warning (which it does by default). See [Logging](../logging/logging.html#concept_30DB86B12B454E168B80BB5A71268865). -If your consumer is unable to receive even high priority messages, only the producerâs warnings will appear in the logs. If you see only producer warnings, you can restart the consumer process. Otherwise, the Geode failure detection code will eventually cause the member to leave the distributed system on its own. +If your consumer is unable to receive even high priority messages, only the producerâs warnings will appear in the logs. If you see only producer warnings, you can restart the consumer process. Otherwise, the <%=vars.product_name%> failure detection code will eventually cause the member to leave the distributed system on its own. **Use Cases** @@ -83,7 +83,7 @@ These are the main use cases for the slow receiver specifications: When using a distribution scope other than distributed-no-ack, alerts are issued for slow receivers. A member that isnât responding to messages may be sick, slow, or missing. Sick or slow members are detected in message transmission and reply-wait processing code, triggering a warning alert first. If a member still isnât responding, a severe warning alert is issued, indicating that the member may be disconnected from the distributed system. This alert sequence is enabled by setting the ack-wait-threshold and the ack-severe-alert-threshold to some number of seconds. -When ack-severe-alert-threshold is set, regions are configured to use ether distributed-ack or global scope, or use the partition data policy. Geode will wait for a total of ack-wait-threshold seconds for a response to a cache operation, then it logs a warning alert ("Membership: requesting removal of entry(\#). Disconnected as a slow-receiver"). After waiting an additional ack-severe-alert-threshold seconds after the first threshold is reached, the system also informs the failure detection mechanism that the receiver is suspect and may be disconnected, as shown in the following figure. +When ack-severe-alert-threshold is set, regions are configured to use ether distributed-ack or global scope, or use the partition data policy. <%=vars.product_name%> will wait for a total of ack-wait-threshold seconds for a response to a cache operation, then it logs a warning alert ("Membership: requesting removal of entry(\#). Disconnected as a slow-receiver"). After waiting an additional ack-severe-alert-threshold seconds after the first threshold is reached, the system also informs the failure detection mechanism that the receiver is suspect and may be disconnected, as shown in the following figure. <img src="../../images_svg/member_severe_alert.svg" id="slow_recv__image_BA474143B16744F28DE0AB1CAD00FB48" class="image" /> The events occur in this order: http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/slow_receivers_preventing_problems.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/slow_receivers_preventing_problems.html.md.erb b/geode-docs/managing/monitor_tune/slow_receivers_preventing_problems.html.md.erb index ec0c199..b7f8b80 100644 --- a/geode-docs/managing/monitor_tune/slow_receivers_preventing_problems.html.md.erb +++ b/geode-docs/managing/monitor_tune/slow_receivers_preventing_problems.html.md.erb @@ -27,19 +27,19 @@ Slowing is more likely to occur when applications run many threads, send large m **Host Resources** -Make sure that the machines that run Geode members have enough CPU available to them. Do not run any other heavyweight processes on the same machine. +Make sure that the machines that run <%=vars.product_name%> members have enough CPU available to them. Do not run any other heavyweight processes on the same machine. -The machines that host Geode application and cache server processes should have comparable computing power and memory capacity. Otherwise, members on the less powerful machines tend to have trouble keeping up with the rest of the group. +The machines that host <%=vars.product_name%> application and cache server processes should have comparable computing power and memory capacity. Otherwise, members on the less powerful machines tend to have trouble keeping up with the rest of the group. **Network Capacity** -Eliminate congested areas on the network by rebalancing the traffic load. Work with your network administrator to identify and eliminate traffic bottlenecks, whether caused by the architecture of the distributed Geode system or by contention between the Geode traffic and other traffic on your network. Consider whether more subnets are needed to separate the Geode administrative traffic from Geode data transport and to separate all the Geode traffic from the rest of your network load. +Eliminate congested areas on the network by rebalancing the traffic load. Work with your network administrator to identify and eliminate traffic bottlenecks, whether caused by the architecture of the distributed <%=vars.product_name%> system or by contention between the <%=vars.product_name%> traffic and other traffic on your network. Consider whether more subnets are needed to separate the <%=vars.product_name%> administrative traffic from <%=vars.product_name%> data transport and to separate all the <%=vars.product_name%> traffic from the rest of your network load. The network connections between hosts need to have equal bandwidth. If not, you can end up with a configuration like the multicast example in the following figure, which creates conflicts among the members. For example, if app1 sends out data at 7Mbps, app3 and app4 would be fine, but app2 would miss some data. In that case, app2 contacts app1 on the TCP channel and sends a log message that itâs dropping data. <img src="../../images_svg/unbalanced_network_capacity_probs.svg" id="slow_recv__image_F8C424AB97C444298993294000676150" class="image" /> **Plan for Growth** -Upgrade the infrastructure to the level required for acceptable performance. Analyze the expected Geode traffic in comparison to the networkâs capacity. Build in extra capacity for growth and high-traffic spikes. Similarly, evaluate whether the machines that host Geode application and cache server processes can handle the expected load. +Upgrade the infrastructure to the level required for acceptable performance. Analyze the expected <%=vars.product_name%> traffic in comparison to the networkâs capacity. Build in extra capacity for growth and high-traffic spikes. Similarly, evaluate whether the machines that host <%=vars.product_name%> application and cache server processes can handle the expected load. http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/socket_communication.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/socket_communication.html.md.erb b/geode-docs/managing/monitor_tune/socket_communication.html.md.erb index a97986a..2da40f9 100644 --- a/geode-docs/managing/monitor_tune/socket_communication.html.md.erb +++ b/geode-docs/managing/monitor_tune/socket_communication.html.md.erb @@ -19,29 +19,29 @@ See the License for the specific language governing permissions and limitations under the License. --> -Geode processes communicate using TCP/IP and UDP unicast and multicast protocols. In all cases, communication uses sockets that you can tune to optimize performance. +<%=vars.product_name%> processes communicate using TCP/IP and UDP unicast and multicast protocols. In all cases, communication uses sockets that you can tune to optimize performance. -The adjustments you make to tune your Geode communication may run up against operating system limits. If this happens, check with your system administrator about adjusting the operating system settings. +The adjustments you make to tune your <%=vars.product_name%> communication may run up against operating system limits. If this happens, check with your system administrator about adjusting the operating system settings. -All of the settings discussed here are listed as `gemfire.properties` and `cache.xml` settings. They can also be configured through the API and some can be configured at the command line. Before you begin, you should understand Geode [Basic Configuration and Programming](../../basic_config/book_intro.html). +All of the settings discussed here are listed as `gemfire.properties` and `cache.xml` settings. They can also be configured through the API and some can be configured at the command line. Before you begin, you should understand <%=vars.product_name%> [Basic Configuration and Programming](../../basic_config/book_intro.html). -- **[Setting Socket Buffer Sizes](../../managing/monitor_tune/socket_communication_setting_socket_buffer_sizes.html)** +- **[Setting Socket Buffer Sizes](socket_communication_setting_socket_buffer_sizes.html)** When you determine buffer size settings, you try to strike a balance between communication needs and other processing. -- **[Ephemeral TCP Port Limits](../../managing/monitor_tune/socket_communication_ephemeral_tcp_port_limits.html)** +- **[Ephemeral TCP Port Limits](socket_communication_ephemeral_tcp_port_limits.html)** By default, Windowsâ ephemeral ports are within the range 1024-4999, inclusive.You can increase the range. -- **[Making Sure You Have Enough Sockets](../../managing/monitor_tune/socket_communication_have_enough_sockets.html)** +- **[Making Sure You Have Enough Sockets](socket_communication_have_enough_sockets.html)** The number of sockets available to your applications is governed by operating system limits. -- **[TCP/IP KeepAlive Configuration](../../managing/monitor_tune/socket_tcp_keepalive.html)** +- **[TCP/IP KeepAlive Configuration](socket_tcp_keepalive.html)** - Geode supports TCP KeepAlive to prevent socket connections from being timed out. + <%=vars.product_name%> supports TCP KeepAlive to prevent socket connections from being timed out. -- **[TCP/IP Peer-to-Peer Handshake Timeouts](../../managing/monitor_tune/socket_communication_tcpip_p2p_handshake_timeouts.html)** +- **[TCP/IP Peer-to-Peer Handshake Timeouts](socket_communication_tcpip_p2p_handshake_timeouts.html)** You can alleviate connection handshake timeouts for TCP/IP connections by increasing the connection handshake timeout interval with the system property p2p.handshakeTimeoutMs. http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/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 839e9be..abadaa8 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 @@ -21,7 +21,7 @@ limitations under the License. The number of sockets available to your applications is governed by operating system limits. -Sockets use file descriptors and the operating systemâs view of your applicationâs socket use is expressed in terms of file descriptors. There are two limits, one on the maximum descriptors available to a single application and the other on the total number of descriptors available in the system. If you get error messages telling you that you have too many files open, you might be hitting the operating system limits with your use of sockets. Your system administrator might be able to increase the system limits so that you have more available. You can also tune your members to use fewer sockets for their outgoing connections. This section discusses socket use in Geode and ways to limit socket consumption in your Geode members. +Sockets use file descriptors and the operating systemâs view of your applicationâs socket use is expressed in terms of file descriptors. There are two limits, one on the maximum descriptors available to a single application and the other on the total number of descriptors available in the system. If you get error messages telling you that you have too many files open, you might be hitting the operating system limits with your use of sockets. Your system administrator might be able to increase the system limits so that you have more available. You can also tune your members to use fewer sockets for their outgoing connections. This section discusses socket use in <%=vars.product_name%> and ways to limit socket consumption in your <%=vars.product_name%> members. ## <a id="socket_comm__section_31B4EFAD6F384AB1BEBCF148D3DEA514" class="no-quick-link"></a>Socket Sharing @@ -158,7 +158,7 @@ In this table, M is the total number of members in the distributed system. </tbody> </table> -With client/server installations, the number of client connections to any single server is undetermined, but Geodeâs server load balancing and conditioning keeps the connections fairly evenly distributed among servers. +With client/server installations, the number of client connections to any single server is undetermined, but <%=vars.product_name%>âs server load balancing and conditioning keeps the connections fairly evenly distributed among servers. Servers are peers in their own distributed system and have the additional socket requirements as noted in the Peer-to-Peer section above. http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/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 665b98b..c029d92 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 @@ -99,7 +99,7 @@ This table lists the settings for the various member relationships and protocols **TCP/IP Buffer Sizes** -If possible, your TCP/IP buffer size settings should match across your Geode installation. At a minimum, follow the guidelines listed here. +If possible, your TCP/IP buffer size settings should match across your <%=vars.product_name%> installation. At a minimum, follow the guidelines listed here. - **Peer-to-peer**. The socket-buffer-size setting in `gemfire.properties` should be the same throughout your distributed system. - **Client/server**. The clientâs pool socket-buffer size-should match the setting for the servers the pool uses, as in these example `cache.xml` snippets: http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/socket_tcp_keepalive.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/socket_tcp_keepalive.html.md.erb b/geode-docs/managing/monitor_tune/socket_tcp_keepalive.html.md.erb index f5512bf..f600d22 100644 --- a/geode-docs/managing/monitor_tune/socket_tcp_keepalive.html.md.erb +++ b/geode-docs/managing/monitor_tune/socket_tcp_keepalive.html.md.erb @@ -19,9 +19,9 @@ See the License for the specific language governing permissions and limitations under the License. --> -Geode supports TCP KeepAlive to prevent socket connections from being timed out. +<%=vars.product_name%> supports TCP KeepAlive to prevent socket connections from being timed out. -The `gemfire.enableTcpKeepAlive` system property prevents connections that appear idle from being timed out (for example, by a firewall.) When configured to true, Geode enables the SO\_KEEPALIVE option for individual sockets. This operating system-level setting allows the socket to send verification checks (ACK requests) to remote systems in order to determine whether or not to keep the socket connection alive. +The `gemfire.enableTcpKeepAlive` system property prevents connections that appear idle from being timed out (for example, by a firewall.) When configured to true, <%=vars.product_name%> enables the SO\_KEEPALIVE option for individual sockets. This operating system-level setting allows the socket to send verification checks (ACK requests) to remote systems in order to determine whether or not to keep the socket connection alive. **Note:** The time intervals for sending the first ACK KeepAlive request, the subsequent ACK requests and the number of requests to send before closing the socket is configured on the operating system level. http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/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 1a3c543..b468bc8 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 @@ -78,7 +78,7 @@ If possible, your TCP/IP buffer size settings should match across your installat ``` **Note:** -WAN deployments increase the messaging demands on a Geode system. To avoid hangs related to WAN messaging, always set `conserve-sockets=false` for GemFire members that participate in a WAN deployment. +WAN deployments increase the messaging demands on a <%=vars.product_name%> system. To avoid hangs related to WAN messaging, always set `conserve-sockets=false` for GemFire members that participate in a WAN deployment. ## <a id="socket_comm__section_4A7C60D4471A4339884AA5AAC97B4DAA" class="no-quick-link"></a>Multi-site (WAN) Socket Requirements http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/system_member_performance.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/system_member_performance.html.md.erb b/geode-docs/managing/monitor_tune/system_member_performance.html.md.erb index 49b9f62..d5ed52f 100644 --- a/geode-docs/managing/monitor_tune/system_member_performance.html.md.erb +++ b/geode-docs/managing/monitor_tune/system_member_performance.html.md.erb @@ -23,19 +23,19 @@ You can modify some configuration parameters to improve system member performanc Before doing so, you should understand [Basic Configuration and Programming](../../basic_config/book_intro.html). -- **[Distributed System Member Properties](../../managing/monitor_tune/system_member_performance_distributed_system_member.html)** +- **[Distributed System Member Properties](system_member_performance_distributed_system_member.html)** Several performance-related properties apply to a cache server or application that connects to the distributed system. -- **[JVM Memory Settings and System Performance](../../managing/monitor_tune/system_member_performance_jvm_mem_settings.html)** +- **[JVM Memory Settings and System Performance](system_member_performance_jvm_mem_settings.html)** You configure JVM memory settings for the Java application by adding parameters to the java invocation. For the cache server, you add them to the command-line parameters for the gfsh `start server` command. -- **[Garbage Collection and System Performance](../../managing/monitor_tune/system_member_performance_garbage.html)** +- **[Garbage Collection and System Performance](system_member_performance_garbage.html)** If your application exhibits unacceptably high latencies, you might improve performance by modifying your JVMâs garbage collection behavior. -- **[Connection Thread Settings and Performance](../../managing/monitor_tune/system_member_performance_connection_thread_settings.html)** +- **[Connection Thread Settings and Performance](system_member_performance_connection_thread_settings.html)** When many peer processes are started concurrently, you can improve the distributed system connect time can by setting the p2p.HANDSHAKE\_POOL\_SIZE system property value to the expected number of members. http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/geode-docs/managing/monitor_tune/system_member_performance_jvm_mem_settings.html.md.erb ---------------------------------------------------------------------- diff --git a/geode-docs/managing/monitor_tune/system_member_performance_jvm_mem_settings.html.md.erb b/geode-docs/managing/monitor_tune/system_member_performance_jvm_mem_settings.html.md.erb index 4440b25..41ebaeb 100644 --- a/geode-docs/managing/monitor_tune/system_member_performance_jvm_mem_settings.html.md.erb +++ b/geode-docs/managing/monitor_tune/system_member_performance_jvm_mem_settings.html.md.erb @@ -45,7 +45,7 @@ You configure JVM memory settings for the Java application by adding parameters gfsh>start server --name=server-name --J=-XX:MaxDirectMemorySize=256M ``` -- JVM stack sizeâEach thread in a Java application has its own stack. The stack is used to hold return addresses, arguments to functions and method calls, and so on. Since Geode is a highly multi-threaded system, at any given point in time there are multiple thread pools and threads that are in use. The default stack size setting for a thread in Java is 1MB. Stack size has to be allocated in contiguous blocks and if the machine is being used actively and there are many threads running in the system (Task Manager shows the number of active threads), you may encounter an `OutOfMemory error: unable to create new native thread`, even though your process has enough available heap. If this happens, consider reducing the stack size requirement for threads on the cache server. The following parameter added to the Java application startup limits the maximum size of the stack. +- JVM stack sizeâEach thread in a Java application has its own stack. The stack is used to hold return addresses, arguments to functions and method calls, and so on. Since <%=vars.product_name%> is a highly multi-threaded system, at any given point in time there are multiple thread pools and threads that are in use. The default stack size setting for a thread in Java is 1MB. Stack size has to be allocated in contiguous blocks and if the machine is being used actively and there are many threads running in the system (Task Manager shows the number of active threads), you may encounter an `OutOfMemory error: unable to create new native thread`, even though your process has enough available heap. If this happens, consider reducing the stack size requirement for threads on the cache server. The following parameter added to the Java application startup limits the maximum size of the stack. ``` pre -Xss384k http://git-wip-us.apache.org/repos/asf/geode/blob/1b84ecbe/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 a42aa25..9b5b913 100644 --- a/geode-docs/managing/monitor_tune/udp_communication.html.md.erb +++ b/geode-docs/managing/monitor_tune/udp_communication.html.md.erb @@ -21,20 +21,20 @@ limitations under the License. You can make configuration adjustments to improve multicast and unicast UDP performance of peer-to-peer communication. -You can tune your Geode UDP messaging to maximize throughput. There are two main tuning goals: to use the largest reasonable datagram packet sizes and to reduce retransmission rates. These actions reduce messaging overhead and overall traffic on your network while still getting your data where it needs to go. Geode also provides statistics to help you decide when to change your UDP messaging settings. +You can tune your <%=vars.product_name%> UDP messaging to maximize throughput. There are two main tuning goals: to use the largest reasonable datagram packet sizes and to reduce retransmission rates. These actions reduce messaging overhead and overall traffic on your network while still getting your data where it needs to go. <%=vars.product_name%> also provides statistics to help you decide when to change your UDP messaging settings. -Before you begin, you should understand Geode [Basic Configuration and Programming](../../basic_config/book_intro.html). See also the general communication tuning and multicast-specific tuning covered in [Socket Communication](socket_communication.html) and [Multicast Communication](multicast_communication.html#multicast). +Before you begin, you should understand <%=vars.product_name%> [Basic Configuration and Programming](../../basic_config/book_intro.html). See also the general communication tuning and multicast-specific tuning covered in [Socket Communication](socket_communication.html) and [Multicast Communication](multicast_communication.html#multicast). ## <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 <%=vars.product_name%> 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 +overrun by incoming no-ack messages. The <%=vars.product_name%> 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 @@ -42,7 +42,7 @@ recharges before they are needed. If the sender's credits run too low, it explic 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: +configured using a three-part <%=vars.product_name%> 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. @@ -52,7 +52,7 @@ In a well-tuned system, where consumers of cache events are keeping up with prod ## <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. +<%=vars.product_name%> 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`
