Roger Binns wrote: > > Sebastian Arcus wrote: > >> Hi and thanks for the suggestion. I did as you advised and ran 'vmstat >> 1' in a terminal. Very little activity - maybe 20-40kb every 6-7 seconds >> on the bo - pretty much nothing on bi. Also, zeros all around on so/si. >> > > That rules out disk activity as the cause. Consequently I would pronounce > your problem to be caused by whatever layers you have on top of SQLite. > Another useful tool on Linux is ltrace which shows library calls. Note > however that it can't show calls made to libraries loaded via dlopen which > is usually most of them. > > >> People seem to be talking about operations on tens to hundreds of >> thousands of records, and performance in some circumstances close to >> MySQL - it just seems all very far off from waiting 10 seconds on a >> single UPDATE or INSERT SQL statement. I must be doing something wrong. >> > > It will be the layer above SQLite causing the problem. Disks are orders of > magnitude slower than memory. The performance choke point is having to do > syncs to ensure data is on disk, but both SQLite and database servers have > to do that. SQLite then also benefits from running in the same process as > whatever is using it, omitting network round trips. In general the way > servers win is by dedicating gigabytes of memory to caching but SQLite can > also a lot if you increase various defaults. > > I've just noticed another interesting thing. A read operation after a write on same table (like a SELECT statement after an INSERT) works perfectly fine - instantly. Which is bizarre, as I would have expected a write to keep a much longer lock on the table then a read. So it's only writes after reads that causes the lock.
I just thought it was interesting to note. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
