Optimise hot reading from remote tables by nickitat · Pull Request #49287 · ClickHouse/ClickHouse

nickitat · 2023-04-27T17:13:04Z

Changelog category (leave one):

Performance Improvement

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

for reading from remote tables we use smaller tasks (instead of reading the whole part) to make tasks stealing work
task size is determined by size of columns to read
always use 1MB buffers for reading from s3
boundaries of cache segments aligned to 1MB so they have decent size even with small tasks. it also should prevent fragmentation

robot-ch-test-poll3 · 2023-05-01T18:29:09Z

This is an automated comment for commit b2921df with description of existing statuses. It's updated for the latest CI running
The full report is available here
The overall status of the commit is 🔴 failure

Check name	Description	Status
AST fuzzer	Runs randomly generated queries to catch program errors. The build type is optionally given in parenthesis. If it fails, ask a maintainer for help	🟢 success
CI running	A meta-check that indicates the running CI. Normally, it's in success or pending state. The failed status indicates some problems with the PR	🟡 pending
ClickHouse build check	Builds ClickHouse in various configurations for use in further steps. You have to fix the builds that fail. Build logs often has enough information to fix the error, but you might have to reproduce the failure locally. The cmake options can be found in the build log, grepping for cmake. Use these options and follow the general build process	🟢 success
Compatibility check	Checks that clickhouse binary runs on distributions with old libc versions. If it fails, ask a maintainer for help	🟢 success
Docker image for servers	The check to build and optionally push the mentioned image to docker hub	🟢 success
Fast test	Normally this is the first check that is ran for a PR. It builds ClickHouse and runs most of stateless functional tests, omitting some. If it fails, further checks are not started until it is fixed. Look at the report to see which tests fail, then reproduce the failure locally as described here	🟢 success
Flaky tests	Checks if new added or modified tests are flaky by running them repeatedly, in parallel, with more randomization. Functional tests are run 100 times with address sanitizer, and additional randomization of thread scheduling. Integrational tests are run up to 10 times. If at least once a new test has failed, or was too long, this check will be red. We don't allow flaky tests, read the doc	🟢 success
Install packages	Checks that the built packages are installable in a clear environment	🟢 success
Integration tests	The integration tests report. In parenthesis the package type is given, and in square brackets are the optional part/total tests	🟢 success
Mergeable Check	Checks if all other necessary checks are successful	🟢 success
Performance Comparison	Measure changes in query performance. The performance test report is described in detail here. In square brackets are the optional part/total tests	🟢 success
Push to Dockerhub	The check for building and pushing the CI related docker images to docker hub	🟢 success
SQLancer	Fuzzing tests that detect logical bugs with SQLancer tool	🟢 success
Sqllogic	Run clickhouse on the sqllogic test set against sqlite and checks that all statements are passed	🟢 success
Stateful tests	Runs stateful functional tests for ClickHouse binaries built in various configurations -- release, debug, with sanitizers, etc	🟢 success
Stateless tests	Runs stateless functional tests for ClickHouse binaries built in various configurations -- release, debug, with sanitizers, etc	🔴 failure
Stress test	Runs stateless functional tests concurrently from several clients to detect concurrency-related errors	🟢 success
Style Check	Runs a set of checks to keep the code style clean. If some of tests failed, see the related log from the report	🟢 success
Upgrade check	Runs stress tests on server version from last release and then tries to upgrade it to the version from the PR. It checks if the new server can successfully startup without any errors, crashes or sanitizer asserts	🟢 success

src/Disks/IO/CachedOnDiskReadBufferFromFile.cpp

src/Storages/MergeTree/MergeTreePrefetchedReadPool.cpp

kssenii · 2023-05-19T12:31:06Z

src/Storages/MergeTree/MergeTreeReadPool.cpp

    , backoff_settings{context_->getSettingsRef()}
    , backoff_state{threads_}
 {
+    if (std::ranges::count(is_part_on_remote_disk, true))


hm, is_part_on_remote_disk is initialized in fillPerPartInfo below this check, so this check is always false?

what a shame )

kssenii · 2023-05-19T12:32:55Z

src/Interpreters/Cache/FileCache_fwd.h

 {

-static constexpr int FILECACHE_DEFAULT_MAX_FILE_SEGMENT_SIZE = 100 * 1024 * 1024;
+static constexpr int FILECACHE_DEFAULT_MAX_FILE_SEGMENT_SIZE = 8 * 1024 * 1024;


isn't it too small?

first of all, why change it. since we start to share segments between tasks ('cause of alignment) now some of them that actually need to read only from the end of the segment could read the whole segment in pre-download. so it seems logical to limit size of the segments.
from what perspective do you think it might be too small? overhead per segment during processing seems very small. the only downside I could think of is prob number of GetObject-s will increase.

the only downside I could think of is prob number of GetObject-s will increase.

yeah, this is what I was thinking about. The solution could be to make changes to CachedOnDiskReadBufferFromFile around setReadUntilPosition method, currently it sets the end to the end of the file segment and defines the boundaries of range request, so reading for the next file segment means making a new getObject request. So to improve this we could do setReadUntilPosition to the right boundary of the last non-downloaded file segment in a row. The only complication is to control the boundary of writing into current file segment as our buffer might contain more.
This increase in the number of getObject requests can actually be very serious, I saw several times that profile event that counts time we spent to just make a getObject request (in initialize() method of ReadBufferFromS3) strikes to >1sec randomly more and more if the number of such requests is quite high.

I also saw this effect, in my case it was because of connection timeouts that start to happen more frequently when we increase number of parallel requests. for this i added conn pool for s3 reading in the second pr.
and I like your idea of coalescing reads on GetObject level

kssenii · 2023-05-19T12:45:03Z

src/Disks/IO/CachedOnDiskReadBufferFromFile.cpp

+    /// We allocate buffers not less than 1M so that s3 requests will not be too small. But the same buffers (members of AsynchronousReadIndirectBufferFromRemoteFS)
+    /// are used for reading from files. Some of these readings are fairly small and their performance degrade when we use big buffers (up to ~20% for queries like Q23 from ClickBench).
+    if (use_external_buffer && read_type == ReadType::CACHED && settings.local_fs_buffer_size < internal_buffer.size())
+        internal_buffer.resize(settings.local_fs_buffer_size);


below when calling predownload() we might decide to bypass cache and change read_method, so we need to resize the buffer back somewhere there

if I'm not missing smth, we do resize only if read_type == ReadType::CACHED and in the only place where we assign positive value to bytes_to_predownload we also set read_type = REMOTE_FS_READ_AND_PUT_IN_CACHE

ah, yes, sorry

kssenii · 2023-05-19T12:49:45Z

src/Disks/IO/AsynchronousReadIndirectBufferFromRemoteFS.cpp

+static size_t chooseBufferSize(const ReadSettings & settings, size_t file_size)
+{
+    /// Buffers used for prefetch or pre-download better to have enough size, but not bigger than the whole file.
+    return std::min<size_t>(std::max<size_t>(settings.prefetch_buffer_size, DBMS_DEFAULT_BUFFER_SIZE), file_size);


is max with DBMS_DEFAULT_BUFFER_SIZE necessary? seems redundant, if user makes the buffer too small it's his fault? as by default prefetch_buffer_size is equal to DBMS_DEFAULT_BUFFER_SIZE then it should be ok

ClickHouse/src/Storages/MergeTree/MergeTreeReaderStream.cpp

Line 87 in 3dfc0bd

read_settings = read_settings.adjustBufferSize(max_mark_range_bytes);

we adjust buffer size (including prefetch buffer) based on mark range sizes. they could be fairly small (few KBs).
since we use them to download segments that (almost) cannot be smaller than 1MB I think it makes sense to enforce this lower bound.

yes, good point

azat · 2023-06-08T10:25:37Z

src/Interpreters/executeQuery.cpp

    /// we still have enough span logs for the execution of external queries.
    std::shared_ptr<OpenTelemetry::SpanHolder> query_span = internal ? nullptr : std::make_shared<OpenTelemetry::SpanHolder>("query");
+    if (query_span)
+        LOG_DEBUG(&Poco::Logger::get("executeQuery"), "Query span trace_id for opentelemetry log: {}", query_span->trace_id);


Maybe it worth to check for query_span->isTraceEnabled() ? To print trace_id only if tracing is enabled

azat · 2023-06-08T10:26:23Z

src/Storages/MergeTree/MergeTreeReadPool.cpp

            parts_queue.push(std::move(info.second));
    }

+    LOG_DEBUG(log, "min_marks_for_concurrent_read={}", min_marks_for_concurrent_read);


This looks like it deserves to be under LOG_TEST

impl

de03b90

robot-ch-test-poll3 added the pr-performance Pull request with some performance improvements label Apr 27, 2023

Merge branch 'master' into optimize_reading2

71a092d

kssenii self-assigned this Apr 28, 2023

nickitat added 3 commits April 28, 2023 14:08

fix build

c862eca

fix test

e0abb25

fix

979b68a

nickitat added 2 commits May 2, 2023 14:23

Merge branch 'master' into optimize_reading2

67bd861

fix

30d216f

nickitat force-pushed the optimize_reading2 branch from 0cfb561 to 30d216f Compare May 3, 2023 13:49

kssenii reviewed May 10, 2023

View reviewed changes

src/Disks/IO/CachedOnDiskReadBufferFromFile.cpp Show resolved Hide resolved

src/Disks/IO/CachedOnDiskReadBufferFromFile.cpp Show resolved Hide resolved

kssenii reviewed May 10, 2023

View reviewed changes

src/Disks/IO/CachedOnDiskReadBufferFromFile.cpp Show resolved Hide resolved

nickitat marked this pull request as ready for review May 10, 2023 11:50

nickitat added 2 commits May 10, 2023 17:24

Merge branch 'master' into optimize_reading2

ec63a6e

fix build

1cc2499

nickitat mentioned this pull request May 10, 2023

Improve reading with prefetch #49732

Merged

nickitat added 2 commits May 12, 2023 12:59

Merge branch 'master' into optimize_reading2

536c5ac

Merge branch 'master' into optimize_reading2

0dd67ba

nickitat commented May 18, 2023

View reviewed changes

src/Storages/MergeTree/MergeTreePrefetchedReadPool.cpp Outdated Show resolved Hide resolved

Update src/Storages/MergeTree/MergeTreePrefetchedReadPool.cpp

971cc09

kssenii reviewed May 19, 2023

View reviewed changes

fix

c93836b

kssenii approved these changes May 23, 2023

View reviewed changes

nickitat added 4 commits May 28, 2023 18:04

Merge branch 'master' into optimize_reading2

42a9072

Merge branch 'master' into optimize_reading2

a3652f1

fix build

be62c8f

Merge branch 'master' into optimize_reading2

b2921df

alexey-milovidov merged commit 9e938d7 into ClickHouse:master Jun 2, 2023

azat reviewed Jun 8, 2023

View reviewed changes

nikitamikhaylov added pr-must-backport-cloud and removed pr-must-backport-cloud labels Jun 23, 2023

nickitat mentioned this pull request Sep 11, 2023

Next improvements for read prefetch #54131

Closed

Conversation

nickitat commented Apr 27, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changelog category (leave one):

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Uh oh!

robot-ch-test-poll3 commented May 1, 2023 • edited by robot-ch-test-poll1 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

nickitat commented Apr 27, 2023 •

edited

Loading

robot-ch-test-poll3 commented May 1, 2023 •

edited by robot-ch-test-poll1

Loading