-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqGRHcACgkQmOOfHg372QSwbQCg4Nqct/BJQ8Sm8/Wdr8NH8Mvn rIEAoN/yoHWFPTBHDxMR1p47qJNdewnn =Eyrr -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
