Dossy,
Dossy Shiobara wrote:
Hmm. It's not unusual that the first query to a database pool will take
longer, because it has to essentially "connect" to the data source -- in
the case of sqlite3, it has to open the database file, read in metadata,
and whatever other housekeeping it must do when opening a database.
Subsequent accesses should definitely be faster.
But, a 15-20 second delay sounds like something is wrong. How large is
the database file? Is it on local disk, or an NFS mount, or something
like that? Is there an error being written into your syslog (disk read
errors, etc.) that could explain the delay on first access to the DB?
The db is 6K on a locally mounted (UFS) FreeBSD 6.0 machine. There
doesn't appear to be any sort of disk error. Nothing else is using the
db. If I use sqlite on the command line the response is instantaneous.
What OS/platform are you on? I'd try tracing the nsd process while you
connect to the DB to see what it's doing when it's doing the 15-20
second wait.
I have a ktrace here. I've chopped most of it out as it is very verbose.
These are the last few lines before it pauses:
18808 nsd GIO fd 2 wrote 116 bytes
"[15/Mar/2006:13:38:37][18808.135164416][-conn:hamster::0]
Notice: dbdrv: opening dat\
abase 'sqlite3:/tmp/sqlite3.db'
"
18808 nsd RET write 116/0x74
18808 nsd CALL open(0x8101060,0x202,0x1a4)
18808 nsd NAMI "/tmp/sqlite3.db"
18808 nsd RET open 12/0xc
18808 nsd CALL fstat(0xc,0xbf7d95b4)
18808 nsd RET fstat 0
18808 nsd CALL dup(0xc)
18808 nsd RET dup 13/0xd
18808 nsd CALL mmap(0xbf6c9000,0x101000,0x3,0x400,0xffffffff,0,0,0)
18808 nsd RET mmap -1083404288/0xbf6c9000
18808 nsd CALL mprotect(0xbf6c9000,0x1000,0)
18808 nsd RET mprotect 0
18808 nsd CALL mmap(0xbf5c8000,0x101000,0x3,0x400,0xffffffff,0,0,0)
18808 nsd RET mmap -1084456960/0xbf5c8000
18808 nsd CALL mprotect(0xbf5c8000,0x1000,0)
18808 nsd RET mprotect 0
18808 nsd CALL kse_release(0xbf7d9434)
18808 nsd RET kse_release 0
18808 nsd CALL kse_release(0xbf9fef5c)
The pause starts here.
After almost 20 seconds it carried on and you can see it has stated
reading the db on the last line below.
18808 nsd RET kse_release 0
18808 nsd CALL kse_release(0xbf9fef5c)
18808 nsd RET kse_release 0
18808 nsd CALL clock_gettime(0,0xbf7fcd8c)
18808 nsd RET clock_gettime 0
18808 nsd CALL clock_gettime(0,0xbf7fcd3c)
18808 nsd RET clock_gettime 0
18808 nsd CALL kse_release(0xbf7fcd44)
18808 nsd RET kse_release 0
18808 nsd CALL fcntl(0xd,0x8,0xbf7d9578)
18808 nsd RET fcntl 0
18808 nsd CALL kse_wakeup(0x809d10c)
18808 nsd RET kse_wakeup 0
18808 nsd RET kse_release 0
18808 nsd CALL fcntl(0xd,0x8,0xbf7d9598)
18808 nsd RET fcntl 0
18808 nsd CALL kse_release(0xbf7d9434)
18808 nsd CALL kse_wakeup(0x809d10c)
18808 nsd RET kse_wakeup 0
18808 nsd RET kse_release 0
18808 nsd CALL kse_release(0x8051f4c)
18808 nsd CALL close(0xd)
18808 nsd RET close 0
18808 nsd CALL lseek(0xc,0,0,0,0)
18808 nsd RET lseek 0
18808 nsd CALL read(0xc,0xbf7d97e4,0x64)
18808 nsd GIO fd 12 read 100 bytes
0x0000 5351 4c69 7465 2066 6f72 6d61 7420 3300 0400 0101
|SQLite format 3.....|
I can't see anything odd here.
Alternatively, if you can't solve the problem, you could always schedule
something to execute right after server startup to "warm up" the
database, to fire off an empty query to the database. Like:
ns_schedule_proc -once 0 {
set db [ns_db gethandle poolname]
ns_db exec $db ""
ns_db releasehandle $db
}
It's not a solution, but it at least addresses your problem in the short
term.
I'll give it a try.
-- Dossy
Thanks,
John.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
