On Mar 3, 2017, at 1:13 PM, Andrew Brown <andrew.br...@economicmodeling.com>
wrote:
>
> This is being run on 64 and 72 core machines, and the more cores I run it on,
> the slower it ends up going.
What happens if you rework the app to do only one thing, single-threaded, but
run between 64 and 108 instances in parallel on the same system? (108 == 72 *
1.5, a common work factor value for parallel applications.)
You can use a tool like GNU parallel to manage the work queue:
https://www.gnu.org/software/parallel/
If nothing else, this would separate out the in-process locking from the file
locking, thereby making more clear where the delays are coming from.
Your __raw_spin_lock() result isn’t terribly enlightening because that’s a very
low level Linux kernel mechanism. It doesn’t tell us whether the slowdown is
due to file locking in SQLite, mutexes in SQLite, some non-optimal pthreads use
in .NET Core, etc.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
