-
Notifications
You must be signed in to change notification settings - Fork 47
DOC-1643 single source client connections in docs #1357
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
4aa065f
25bdef4
29e4549
6747246
a8115cb
2051365
4ef6a9d
8906946
6e1f9aa
548245a
d15e72e
674fb6a
2b6963a
235b6a9
1d4d557
a14a75c
c712d09
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,6 +1,7 @@ | ||
| = Configure Client Connections | ||
| :description: Guidelines for configuring Redpanda clusters for optimal availability. | ||
| :page-categories: Management, Networking | ||
| // tag::single-source[] | ||
|
|
||
| Optimize the availability of your clusters by configuring and tuning properties. | ||
|
|
||
|
|
@@ -10,14 +11,16 @@ A malicious Kafka client application may create many network connections to exec | |
|
|
||
| The following Redpanda cluster properties limit the number of connections: | ||
|
|
||
| * xref:reference:cluster-properties.adoc#kafka_connections_max[`kafka_connections_max`]: Similar to Kafka's `max.connections`, this sets the maximum number of connections per broker. | ||
| * xref:reference:cluster-properties.adoc#kafka_connections_max_per_ip[`kafka_connections_max_per_ip`]: Similar to Kafka's `max.connections.per.ip`, this sets the maximum number of connections accepted per IP address by a broker. | ||
| * xref:reference:cluster-properties.adoc#kafka_connections_max_overrides[`kafka_connections_max_overrides`]: A list of IP addresses for which `kafka_connections_max_per_ip` is overridden and doesn't apply. | ||
| ifndef::env-cloud[] | ||
| * xref:reference:cluster-properties.adoc#kafka_connections_max[`kafka_connections_max`]: Similar to Kafka's `max.connections`, this sets the maximum number of connections per broker. | ||
|
|
||
| Redpanda also provides properties to manage the rate of connection creation: | ||
|
|
||
| * xref:reference:cluster-properties.adoc#kafka_connection_rate_limit[`kafka_connection_rate_limit`]: This property limits the maximum rate of connections created per second. It applies to each CPU core. | ||
| * xref:reference:cluster-properties.adoc#kafka_connection_rate_limit_overrides[`kafka_connection_rate_limit_overrides`]: A list of IP addresses for which `kafka_connection_rate_limit` is overridden and doesn't apply. | ||
| endif::[] | ||
|
|
||
| [NOTE] | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @travisdowns is the note below accurate about connections counts? 'Typically two or three' sounds just wrong. Doesn't a client open a connection for each broker its connected to (or for each partition its producing/consuming to/from). Its good to first note that num connections != num clients, but I think the message here is the max expected # of connections per client is 'on the order of [insert something]' cc @micheleRP
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, 2 or 3 would be a large underestimate if there are many brokers, and if clients connect to each broker (which is workload dependent). Here are the full details: https://redpandadata.atlassian.net/wiki/spaces/CORE/pages/510099463/How+many+connections That's probably not going to make it into this paragraph, but a conservative estimate is N+2 connections per client where
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thank you @travisdowns! I changed that bullet (typically 2-3 connections per client) to:
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. LGTM. |
||
| ==== | ||
|
|
@@ -46,10 +49,21 @@ See also: xref:develop:produce-data/configure-producers.adoc[Configure Producers | |
|
|
||
| A Redpanda broker may create log segments at startup. If a broker crashes after startup, and if it gets stuck in a crash loop, it could produce progressively more stored state that uses more disk space and takes more time for each restart to process. | ||
|
|
||
| ifndef::env-cloud[] | ||
| To prevent infinite crash loops, the Redpanda broker property xref:reference:node-properties.adoc#crash_loop_limit[`crash_loop_limit`] sets an upper limit on the number of consecutive crashes that can happen within one hour of each other. After it reaches the limit, a broker cannot restart until its internal consecutive crash counter is reset to zero by one of the following conditions: | ||
| endif::[] | ||
|
|
||
| ifdef::env-cloud[] | ||
| To prevent infinite crash loops, the Redpanda broker property [`crash_loop_limit`] sets an upper limit on the number of consecutive crashes that can happen within one hour of each other. After it reaches the limit, a broker cannot restart until its internal consecutive crash counter is reset to zero by one of the following conditions: | ||
| endif::[] | ||
|
|
||
| * The `redpanda.yaml` configuration file is updated. | ||
| ifndef::env-cloud[] | ||
| * The `startup_log` file in the broker's xref:reference:node-properties.adoc#data_directory[data_directory] is manually deleted. | ||
| endif::[] | ||
| ifdef::env-cloud[] | ||
| * The `startup_log` file in the broker's `data_directory` is manually deleted. | ||
| endif::[] | ||
| * One hour has elapsed since the last crash. | ||
| * The broker is properly shut down. (This is not possible after `crash_loop_limit` has been reached and the broker cannot be restarted.) | ||
|
|
||
|
|
@@ -59,4 +73,12 @@ To prevent infinite crash loops, the Redpanda broker property xref:reference:nod | |
| * If the limit is less than two, the broker is blocked from restarting after every crash, until one of the reset conditions is met. | ||
| ==== | ||
|
|
||
| ifndef::env-cloud[] | ||
| To facilitate debugging in environments where a broker is stuck in a crash loop, set the xref:reference:properties/broker-properties.adoc#crash_loop_sleep_sec[`crash_loop_sleep_sec` configuration]. This setting determines how long the broker sleeps before terminating the process after reaching the crash loop limit. The window during which the broker remains available allows you to troubleshoot the issue. This setting is most useful when xref:troubleshoot:errors-solutions/k-resolve-errors.adoc[troubleshooting in Kubernetes environments]. | ||
| endif::[] | ||
|
|
||
| ifdef::env-cloud[] | ||
| To facilitate debugging in environments where a broker is stuck in a crash loop, set the `crash_loop_sleep_sec` configuration. This setting determines how long the broker sleeps before terminating the process after reaching the crash loop limit. The window during which the broker remains available allows you to troubleshoot the issue. | ||
| endif::[] | ||
|
|
||
| // end::single-source[] | ||
Uh oh!
There was an error while loading. Please reload this page.