Hi,
I have an application that uses sqlite3.
Investigating a problem with the app stalling occasionally I found that
(every hour or two) an fdsync() system call from sqlite3_step() was
taking over 3 seconds to return.
On closer investigation, the file descriptor in these calls point to the
directory in which the database resides, rather than the database of
journal file itself, and are opened with O_LARGEFILE flag and no O_RDWR
and transfers zero bytes.
Presumably this is updating metadata, but I understood fdsync() doesn't
touch metadata.
Can anybody suggest a way to prevent sqlite making these fdsync()
calls? The database updates aren't high volume (maybe 20/sec max) but
the app needs to be responsive. I traced mmap() calls in my process and
found none relating to the sqlite db. I thought maybe I could force
sqlite to not cache writes this way. It seems that using pragma to
disable caching in sqlite simply exposes the database to corruption
rather than forcing synchronous writing to disk. Is this correct?
I'm using Solaris 10 with zfs and I may be able to disable write caching
on the entire disk, but would prefer not to! Any ideas appreciated.
Cheers,
Jono P.
--
------------------------------
This email, including any attachments, is only for the intended recipient.
It is subject to copyright, is confidential and may be the subject of legal
or other privilege, none of which is waived or lost by reason of this
transmission.
If you are not an intended recipient, you may not use, disseminate,
distribute or reproduce such email, any attachments, or any part thereof.
If you have received a message in error, please notify the sender
immediately and erase all copies of the message and any attachments.
Unfortunately, we cannot warrant that the email has not been altered or
corrupted during transmission nor can we guarantee that any email or any
attachments are free from computer viruses or other conditions which may
damage or interfere with recipient data, hardware or software. The
recipient relies upon its own procedures and assumes all risk of use and of
opening any attachments.
------------------------------
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
