mirror of https://github.com/apache/druid.git
Fix references to removed performance FAQ page (#7755)
This commit is contained in:
parent
eb0e1a056c
commit
cfb7756c9b
|
@ -84,10 +84,8 @@ Timeseries and TopN queries are much more optimized and significantly faster tha
|
||||||
Segments should generally be between 300MB-700MB in size. Too many small segments results in inefficient CPU utilizations and
|
Segments should generally be between 300MB-700MB in size. Too many small segments results in inefficient CPU utilizations and
|
||||||
too many large segments impacts query performance, most notably with TopN queries.
|
too many large segments impacts query performance, most notably with TopN queries.
|
||||||
|
|
||||||
# Read FAQs
|
# FAQs and Guides
|
||||||
|
|
||||||
You should read common problems people have here:
|
1) The [Ingestion FAQ](../ingestion/faq.html) provides help with common ingestion problems.
|
||||||
|
|
||||||
1) [Ingestion-FAQ](../ingestion/faq.html)
|
2) The [Basic Cluster Tuning Guide](../operations/basic-cluster-tuning.html) offers introductory guidelines for tuning your Druid cluster.
|
||||||
|
|
||||||
2) [Performance-FAQ](../operations/performance-faq.html)
|
|
||||||
|
|
|
@ -288,7 +288,8 @@ disk space.
|
||||||
|
|
||||||
With groupBy v2, cluster operators should make sure that the off-heap hash tables and on-heap merging dictionaries
|
With groupBy v2, cluster operators should make sure that the off-heap hash tables and on-heap merging dictionaries
|
||||||
will not exceed available memory for the maximum possible concurrent query load (given by
|
will not exceed available memory for the maximum possible concurrent query load (given by
|
||||||
druid.processing.numMergeBuffers). See [How much direct memory does Druid use?](../operations/performance-faq.html) for more details.
|
druid.processing.numMergeBuffers). See the [Basic Cluster Tuning Guide](../operations/basic-tuning-guide.html)
|
||||||
|
for more details about direct memory usage, organized by Druid process type.
|
||||||
|
|
||||||
Brokers do not need merge buffers for basic groupBy queries. Queries with subqueries (using a "query" [dataSource](datasource.html#query-data-source)) require one merge buffer if there is a single subquery, or two merge buffers if there is more than one layer of nested subqueries. Queries with [subtotals](groupbyquery.html#more-on-subtotalsspec) need one merge buffer. These can stack on top of each other: a groupBy query with multiple layers of nested subqueries, and that also uses subtotals, will need three merge buffers.
|
Brokers do not need merge buffers for basic groupBy queries. Queries with subqueries (using a "query" [dataSource](datasource.html#query-data-source)) require one merge buffer if there is a single subquery, or two merge buffers if there is more than one layer of nested subqueries. Queries with [subtotals](groupbyquery.html#more-on-subtotalsspec) need one merge buffer. These can stack on top of each other: a groupBy query with multiple layers of nested subqueries, and that also uses subtotals, will need three merge buffers.
|
||||||
|
|
||||||
|
|
|
@ -143,7 +143,6 @@ layout: toc
|
||||||
* Tuning and Recommendations
|
* Tuning and Recommendations
|
||||||
* [Basic Cluster Tuning](/docs/VERSION/operations/basic-cluster-tuning.html)
|
* [Basic Cluster Tuning](/docs/VERSION/operations/basic-cluster-tuning.html)
|
||||||
* [General Recommendations](/docs/VERSION/operations/recommendations.html)
|
* [General Recommendations](/docs/VERSION/operations/recommendations.html)
|
||||||
* [Performance FAQ](/docs/VERSION/operations/performance-faq.html)
|
|
||||||
* [JVM Best Practices](/docs/VERSION/configuration/index.html#jvm-configuration-best-practices)
|
* [JVM Best Practices](/docs/VERSION/configuration/index.html#jvm-configuration-best-practices)
|
||||||
* Tools
|
* Tools
|
||||||
* [Dump Segment Tool](/docs/VERSION/operations/dump-segment.html)
|
* [Dump Segment Tool](/docs/VERSION/operations/dump-segment.html)
|
||||||
|
|
Loading…
Reference in New Issue