Replies: 2 comments
-
|
feel free to make PR, i created issue #1465 |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
sorry for late reply |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
@Slach hi,
We use ClickHouse (different versions) + clickhouse-backup in production, on setups with a lot of
tables (for example: ~50K MergeTree + ~500K Join, ~954 GiB).
I noticed that hashing takes a really long time during backup.
Looks like fetching
hash_of_all_filesfromsystem.partsruns together withFREEZEand they contend on some mutex inside ClickHouse - FREEZE jumps from ~100ms to ~5000ms per table because of it.I tried just skipping that lookup and the difference is huge:
create~9.5hcreate~26minI know
hash_of_all_filesisn't useless - incrementalcreate --diff-from-remoteuses it todedup parts against the previous full backup, so skipping it on full backups would quietly hurt
future increments.
That's why I only did it behind an opt-in flag, not automatically.
Concretely, what I did:
clickhouse.skip_hash_of_all_files(envCLICKHOUSE_SKIP_HASH_OF_ALL_FILES);--skip-hash-of-all-filesCLI flag tocreate/create_remote/watch;AddTableToLocalBackup- one extra condition, so the defaultbehavior is unchanged:
When the flag is off (default) everything works exactly as today; when it's on, the per-part
hash_of_all_filesread fromsystem.partsis skipped and the FREEZE contention goes away.My two main questions:
--diff-from-remote?system.partslookup so it doesn't fight with
FREEZE- so no flag would be needed at all?Beta Was this translation helpful? Give feedback.
All reactions