On 9/24/07, Kees Nuyt <[EMAIL PROTECTED]> wrote: > > On Mon, 24 Sep 2007 07:13:51 -0700, Gururaja Nittur wrote: > > >Sqlite experts, > > > >I am running Sqlite version 3.4.1. I ran some performance tests and > >observed that sqlite sometimes consumes more CPU than normal (I am > >using same dataset, all inserts and recreating new database for each > >test). Tried running oprofiile and got the following result. The > >function 'syncJournal' is taking around 60% of total Sqlite's CPU > >usage. > > > > 1. Is this normal behaviour? If not, is there a known fix for this? > > Do you use transactions? If not, every INSERT or UPDATE is a > separate transaction, causing a lot of overhead because the > journal is flushed for every transaction.
Yes! I do use transaction. But, I am testing my application's worst case here (Inserting one record per transaction). > > > 2. Are there any tunables that can be used to ease the issue? > > Several pragma's are available, the documentation is quite > clear: http://www.sqlite.org/pragma.html > > Also read: > http://www.sqlite.org/cvstrac/wiki?p=PerformanceConsiderations > > >PS: My database is pretty small. > >I am setting max_page_count=896 and > >page_size = 512 (Max database size = 3.5MB). > > I don't understand that one. > 512 Bytes * 896 Pages would be 458752 Bytes. > I think you would need 7168 pages of 512 bytes to accomodate 3.5 > MByte. Oops! my fault. You are right. I had changed the max_page_count=896 to test with smaller database. I do see similar behavior when max size is 3.5M. > > Ideally, the page_size should equal the allocation unit (for > Window: the cluster size of the formatted disk). > Also, if your rows can be large, a too small page_size would > cause overflow pages, and thus additional overhead. I expect most of my rows to be less than 512 bytes and hence using smaller page_size. Thanks for the response. I just wanted to find out if there are any known issues with syncJournal. I will tweak more parameters and try to measure again. Best regards, Guru > > >Thanks in advance. > > I hope this helps. > -- > ( Kees Nuyt > ) > c[_] > > ----------------------------------------------------------------------------- > To unsubscribe, send email to [EMAIL PROTECTED] > ----------------------------------------------------------------------------- > > ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
