Cool, this makes sense. At that point, sqlite is probably using a mutex/semaphore underneath, so we shouldn’t need to set anything manually. It is competing with fopen after all.
Not quite understanding this yet, but perhaps this has more to do with sqlite. I’m assuming it isn’t trying to do a mmap of the indexes. When it reads from disk, those pages should be cached by linux, so that memory should show up in buffers/caches and not in beam.
Then there’s the pragma cache limit which appears to be separate. I suppose the nif is doing it’s own malloc as it would need to have some memory when doing large queries. I was playing around with observer last night and there were hardly any memory changes that I found. Does using malloc mean that the memory doesn’t show up in observer/beam or did I just miss it?
If my understanding is correct, the memory usage should be:
- per pool connection - up to 2MB sqlite cache + general elixir overhead + any malloc overhead for being able to execute the queries
- linux virtual memory - caching/flushing the pages of the database file in memory which is shared across all fd’s
Does that sound right?
Interesting results. I didn’t think the networking overhead would cost that much for the inserts. Before doing the port of my data, I quickly checked the performance of the entire phoenix call between postgres and sqlite and it was between 50-100ms for both of them. This may seem unusually high, but I’m testing on a 10 year old laptop in dev mode. In prod, we’re looking at under 10ms for postgres.
