> It's this code in __wt_btree_sync():
>
do { ret = __wt_evict_file_serial(session, 0); } while (ret == WT_RESTART);
> I was wondering why a WT_RESTART might show up there?
Looking at that change [1], the issue is workloads that fill up the eviction request queue. The issue was with many files open and many threads, some workloads were filling up the request queue with force page eviction requests, which meant that there was no slot available when a sync or close request came in. Rather than failing, I made that into a loop.
More recent changes have made this very unlikely: forced page eviction always leaves an empty slot and doesn't tie up a slot if it needs to be retried. That said, a better solution would be to not use a fixed-sized array of requests – we're holding a lock, so it wouldn't be a big deal to grow the array instead of failing.
Michael.
[1] https://github.com/wiredtiger/wiredtiger/commit/12337e75de6cdd57eb87305b0c6bc61f1b8b8b24
- is related to
-
WT-201 Fileevict
- Closed