From 08787f3244bcc796bd6a600b67025750eae05c53 Mon Sep 17 00:00:00 2001 From: jon-wei Date: Fri, 24 May 2019 11:44:39 -0700 Subject: [PATCH] Fix references to removed performance FAQ page --- docs/content/operations/recommendations.md | 8 +++----- docs/content/querying/groupbyquery.md | 3 ++- docs/content/toc.md | 1 - 3 files changed, 5 insertions(+), 7 deletions(-) diff --git a/docs/content/operations/recommendations.md b/docs/content/operations/recommendations.md index 311b46d0c435..61cb871112c1 100644 --- a/docs/content/operations/recommendations.md +++ b/docs/content/operations/recommendations.md @@ -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 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) [Performance-FAQ](../operations/performance-faq.html) +2) The [Basic Cluster Tuning Guide](../operations/basic-cluster-tuning.html) offers introductory guidelines for tuning your Druid cluster. diff --git a/docs/content/querying/groupbyquery.md b/docs/content/querying/groupbyquery.md index 125d793faadb..e6451a2a2830 100644 --- a/docs/content/querying/groupbyquery.md +++ b/docs/content/querying/groupbyquery.md @@ -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 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. diff --git a/docs/content/toc.md b/docs/content/toc.md index 57ed63222a0a..44e9542fc3d4 100644 --- a/docs/content/toc.md +++ b/docs/content/toc.md @@ -143,7 +143,6 @@ layout: toc * Tuning and Recommendations * [Basic Cluster Tuning](/docs/VERSION/operations/basic-cluster-tuning.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) * Tools * [Dump Segment Tool](/docs/VERSION/operations/dump-segment.html)