tests: fix flakiness of tests for system.filesystem_cache#79633
tests: fix flakiness of tests for system.filesystem_cache#79633alexey-milovidov merged 5 commits intoClickHouse:masterfrom
Conversation
… segments Merges in those tables can take significant amount of time (more them 10 minutes on some debug builds) and for the whole time they can lock some cache segments and SYSTEM DROP FILESYSTEM CACHE cannot prune them.
It is ignored due to build folder can contain them, but we use them in tests to store some additional helpers
f0184a5 to
856d0cd
Compare
…ache (slow) Now it is 2x faster
The problem is that for flaky check the thread fuzzer is enabled, and access to system.remote_data_paths is too slow with it, i.e. 2.5 sec vs 7.7 sec, but on CI it is even bigger.
| SAMPLE BY intHash32(UserID) SETTINGS index_granularity = 8192, storage_policy='s3_cache'" | ||
|
|
||
| # Avoid locking filesystem cache | ||
| clickhouse-client --query "SYSTEM STOP MERGES test.hits" |
There was a problem hiding this comment.
I'd rather not stop merges, but use a its own cache for tests which fail if it actually does not matter for the test (there are tests which on purpose use a common cache to generate more load/concurrency with it). In this exact case for tests which were modified in this PR it does not matter.
Reason - I think I remember cases when caching on background merges helped to find some bug.
There was a problem hiding this comment.
I don't see how separate cache will help.
Let me try to explain the problem, 02286_drop_filesystem_cache assumes that there will be no cache entries after SYSTEM DROP FILESYSTEM CACHE, but, due to very slow merges for test.hits some entries has not been removed since they are still in use.
Reason - I think I remember cases when caching on background merges helped to find some bug.
I think merges for other tables in tests should be enough to cover this.
There was a problem hiding this comment.
02286_drop_filesystem_cache assumes that there will be no cache entries after SYSTEM DROP FILESYSTEM CACHE, but, due to very slow merges for test.hits some entries has not been removed since they are still in use.
yes, but there is no need to use the same cache object in test 02286_drop_filesystem_cache as for test.hits, so with independent caches we do not care about slow merges of test.hits. system.filesystem_cache has a name column, which is a name of the cache, so we can check only a specific cache in 02286_drop_filesystem_cache, so test.hits will not have any impact on it.
Changelog category (leave one):
The problem is that some entries can be locked, i.e. due to merges, so let's:
SYSTEM DROP FILESYSTEM CACHEinto all tests that querysystem.filesystem_cachew/o extra filters (i.e. bykey)Fixes: #75876