sos: Too many task files slows down SoS
This is separated from #796. There is slowness not only in job preparation but also at the end of every for loop in tasks – my task queue will always halt for about 10 seconds before submitting the next batch of jobs, ie, the overhead of submitting 1000 jobs is 500 seconds. Today I finally can no longer live with the slowness so I removed my ~/.sos/tasks. Out of curiosity I tar zcf before I delete it. It took quite a while to archive it, and generated for me a 1.9G tar.gz file. That might be a 10GB sqlite database if that’s what we will end up doing, and growing … that sounds disturbing.
This may be an important issue for heavy duty work. I’m really curious how other software deal with this problem.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 22 (22 by maintainers)
Commits related to this issue
- Using a dedicated thread to save task files. #810 — committed to vatlab/sos by deleted user 7 years ago
- Using a dedicated thread to submit tasks in batch. #810 — committed to vatlab/sos by deleted user 7 years ago
- Temporarily revert patch for issue 810 because of the many problems it causes #810 — committed to vatlab/sos by deleted user 7 years ago
- Re-implement patch for #810 without using multi-threading — committed to vatlab/sos by deleted user 7 years ago
- Rename functions of the task interface #810 — committed to vatlab/sos by deleted user 7 years ago
- Release sos 0.9.9.6 with fix to #810 — committed to vatlab/sos by deleted user 7 years ago
- Fix error handling of the new task handling code #810 — committed to vatlab/sos by deleted user 7 years ago
- Restore no wait test after re-implementation of #810. (close #831) — committed to vatlab/sos by deleted user 7 years ago
One by one, let me first streamline the generation and execution of tasks, basically sending tasks to workers right after they are created.