3 ms·
On a project we had to deal with some properietary software that was highly optimized for its CPU-bound steady-state workload but suffered from terrible startup
by the8472 5y ago
On a project we had to deal with some properietary software that was highly optimized for its CPU-bound steady-state workload but suffered from terrible startup times due to single-threaded, blocking IO to EFS. Part of the workaround was a wrapper that preopened files on multiple threads, issued readaheads and then rewrote the data to point to /proc/<pid>/fd/<number> paths instead of the paths on EFS. That alone already cut load times from 6 minutes to < 30 seconds.
Lower latency storage helps, but applications not doing things the most naive way possible would be great too. Spawn a few threads if you have thousands of files to open. Issueing IO operations in batches to io_uring would help too but libraries need to catch up first.
- RyanHamilton 5y ago"Spawn a few threads if you have thousands of files to open." You've gone so deep into the trees that you can't see the forest. Creating a workaround wrapper or spawning unnecessary threads is a bad idea. You want async io or io_uring.
- otterley 5y ago“Proprietary software” suggests the commenter did not have the source code or resources to do that. Sometimes you just have to make the best hack you can.
- secondcoming 5y agoI was under the impression that Linux does not support async file access and so people have to fake it with threads.
- coder543 5y agoThis is no longer true since the arrival of io_uring, and that's why the person you replied to referenced it.