Roger Binns wrote: > Sebastian Arcus wrote: > >> The SQLite documentation talks about entire database locks by operations >> of the order of milliseconds - 10 seconds seems a long way off. >> > > There is a possible but unlikely cause for what you are seeing. In order to > ensure the database and/or journal are fully on disk, SQLite calls the fsync > system call on the relevant file handle. > > Due to the internals of the way the ext3 filesystem is written, an fsync > call actually turns into a sync call which means the fsync does not return > until all outstanding data on that filesystem has been written to disk. If > you have a slow disk (your laptop most likely does) plus lots of outstanding > data then 10 seconds is quite possible, especially if "laptop mode" is > active (increases the periodic background filesystem sync to 5 minutes in > some cases). A fun way of showing this is to do a hefty compile as that > will generate lots of big files quickly. > > I recommend you run "vmstat 1" in a terminal somewhere while doing your > operations. Look at the bo/bi columns which show the 1kb blocks being > read/written from disk per second. The so/si columns show if any swap > activity is happening also using a 1kb reporting unit. > 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. I am running a very lightly loaded system - fluxbox as a desktop environment - in order to get quite snappy performance from what is otherwise not a very fast CPU.
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. P.S. I don't know why my initial post has shown as a reply to another poster's topic - apologies - I don't understand why that happened - I've sent a new message to the list - not a reply. > Roger > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
