This message was deleted.
# nebula-userss
Slackbot
11/29/2022, 9:00 PMThis message was deleted.
w
wey
11/30/2022, 11:15 AMThe compression algo change shouldn’t impact the query, have you got a chance to trigger compaction?
g
Goran Cvijanovic
11/30/2022, 12:41 PMI use only automatic compactions, not forcing with explicit command for compaction.
Goran Cvijanovic
11/30/2022, 12:43 PMI found that issue I have is related to Index which doesn’t return all records matching index using LOOKUP,
but FETCH-ing data by VertexID returns that record.
w
wey
12/01/2022, 1:32 AMChecked with storage guys, and it looks like auto-compaction time out due to the compression-algorithm change.
Could you trigger a manual compaction?
g
Goran Cvijanovic
12/01/2022, 9:07 AMI can, but how it will help with that indexes problem, that LOOKUPs not having all data in index ?
Goran Cvijanovic
12/01/2022, 9:16 AMI’ve noticed that executing query with WHERE clause with ‘==’ or STARTS WITH ‘abcdefgh’
didn’t return all rows of data.
Then I experimented with STARTS WITH ‘abcdef’ and got some larger number of rows, then repeating query
with STARTS WITH ‘abcdefgh’ returns all rows which match the where clause.
Looks like “repair on read” but don’t know what actually happened.
I can see some activity on storage which produce some increased reads/writes like some background process, started after I reverted changes for leveled compression parameter and restarted storaged services on all nodes on cluster.
w
wey
12/01/2022, 11:18 AMIt’s 3.3.0 or? what is the storage client timeout configuration in your cluster?
g
Goran Cvijanovic
12/01/2022, 11:52 AMYes it is 3.3.0
Copy code
# storage client timeout
--storage_client_timeout_ms=60000w
wey
12/06/2022, 6:40 AMDear @Goran Cvijanovic let’s continue the thread in DM here to enable involving other guys later.
Timed out in 60 secs is quite abnormal, may I know if it’s HDD or SDD?
wey
12/06/2022, 6:40 AMThe log level was v4 by default or you just switched it so now?
5 Views