search

vmware / splinterdb

High Performance Embedded Key-Value Store
https://splinterdb.org
Apache License 2.0
680 stars 57 forks source link

CI: Bump timeout from 2h to 3h. shmem-tests cause debug test runs to take longer. #566

Closed gapisback closed 1 year ago

gapisback commented 1 year ago

In-flight stabilization of shared memory support in Splinter is bringin along with tons more additional tests. We are effetively running most of the existing twice; once w/o and once w/ shared memory configured. Debug-build test runs are timing out at 2 hours. Bump timeout to 3hs, and once stabilized, we can look into dropping this to 2h.

netlify[bot] commented 1 year ago

Deploy Preview for splinterdb canceled.

Name Link
Latest commit f65c2b5ab8692d84f4923df5f5f790a305e9da6d
Latest deploy log https://app.netlify.com/sites/splinterdb/deploys/643953b5c6fca00008453a09
gapisback commented 1 year ago

@rosenhouse - I have applied this change to /main, to see if this helps complete my recent shmem stabilization PRs' test cycles.

See these two recent failures due to time out: 25 and 26.

gapisback commented 1 year ago

HI, @rosenhouse - I re-ran my /shmem stabilization runs with this increased time out -plus- commented out a few new longish-running unit-test cases. (The problem seems to be on Splinter-side.)

Now the test runs have finished in just less than 2 hours:

See: no. 27: debug-clang: All Tests: [ 1h 52m 41s ] See: no. 27: debug-gcc: All Tests: [ 1h 52m 28s ]

It's just under 2 hours, so I'd still like to bump up the timeout to be safe & clear.

I suspect we will eventually need something 2+ hrs as quite a bit of new tests are coming in.