Open ethanyzhang opened 1 year ago
@amitkdutta, @mbasmanova, @oerling
@xiaoxmeng @majetideepak : This error is in AsyncDataCache. Please can you'll take a stab at it.
Berthold was able to reproduce it with SF 1K. Internal: https://ibm-analytics.slack.com/archives/C055RAP6BM0/p1695233450279949?thread_ts=1695229124.127739&cid=C055RAP6BM0
The invariant is that the file id is expected to be defined (exist in the FileIds()) map because the HiveDataSource owns a shared ptr to the corresponding FileHandle. The FileHandle has a StringIdLease that keeps the file id to file name mapping live for the duration of the split. The file name acquires an id when the FileHandle is made. As long as the FileHandle exists this mapping stays. The file is then referenced by the CacheInputStream with this id. If this mapping is used in AsyncDataCacheENtry the entry keeps the id to name mapping live because it has a FileCacheKey that contains the StringIdLease for the mapping
Now we see from the stack that we are making an entry with a file id that does not have a live mapping to the file name. If this happens, we presumably have a wrong id in the CacheInputStream that differs from the id in the FileHandle that is owned by the HiveDataSource. This could be checked. The diagnostic is to log the FileHandle on the error throw path (like with a folly::makeGuard) that logs the FileHandle on the error unwind. Or the id - name mapping could have been deleted if its use count had been decremented by some kind of memory corruption. Checking the integrity of the StringIdMap and periodically asserting this is another diagnostic step. The reasonable action at this time is to add an integrity check at the place where the error is signalled.
Prestissimo Worker config:
presto.version=0.284
coordinator=false
http-server.http.port=8090
discovery.uri=http://xxx.yyy.ibm.com:8091/
optimizer.optimize-hash-generation=false
task.max-drivers-per-task=80
query.max-memory-per-node=600GB
Java Presto co-ordinator config
coordinator=true
node-scheduler.include-coordinator=false
optimizer.optimize-hash-generation=false
http-server.http.port=8091
query.max-memory=1.9TB
query.max-total-memory=2.0TB
query.max-memory-per-node=300GB
query.max-total-memory-per-node=310GB
query.stage-count-warning-threshold=100
query.max-history=3000
# default for heap headroom is :JVM max memory * 0.3; reduce to 20%
memory.heap-headroom-per-node=70GB
discovery-server.enabled=true
discovery.uri=http://xxx.yyyy.ibm.com:8091
task.max-drivers-per-task=80
# To make q35 work: VeloxRuntimeError: vector Unexpected type of the result vector: BIGINT
use-alternative-function-signatures=true
@majetideepak can you give an update?
No longer reproducible.
@yzhang1991 : We may not hit this again if we are lucky. But we should add diagnostics as Orri has suggested in https://github.com/prestodb/presto/issues/20019#issuecomment-1730489305
@oerling @xiaoxmeng @aditi-pandit The problem appears to not be re-creatable at this time. There were some changes in the area which may have fixed the problem.
Nonetheless, I made a draft PR to propose changes to check the StringMapId
maps against each other (https://github.com/facebookincubator/velox/pull/7458) and add a logging point when StringLease's destructor is called (when FileHandle
is deallocated). There is already a VLOG(1)
log point when the FileHandle
starts a lease - so we can see the life cycle of the lease.
If the issue occurs again we can check with a repro and the --v=1
log options when starting presto_server
to get better diagnostics.
Only found when running TPC-DS SF-10K