> It's not only speed in KB/sec that matters. It's also disk system
> usage as reported by iostat. If it's close to 100% then SQLite can't
> do any better.
A sad day.
I copied the database to a faster driver with RAID 0, made another
copy of the database (referred to as DB1), and ran another set of
tests:
test1: two sequential processes of sqlite count(*) table1 and table 2
in DB1 --> 7m15s
test2: two concurrent processes of sqlite count(*) table1 and table2
in DB1 --> 5m22s
test3: four concurrent processes of sqlite count(*) table 1, 2, 3, and
4 in DB1 --> 12m58s
test4: two concurrent processes of sqlite count(*) table1 in DB1, and
table1 in DB2 --> 9m51s.
Although running two or more processes can save some time, the
performance gain is not that big (tests 2 and 3), splitting the
database into several smaller ones would not help either (test 4).
Anyway, the iostat output of my system is
2011 Oct 22 21:16:36, load: 0.03, disk_r: 2676 KB, disk_w: 0 KB
UID PID PPID CMD DEVICE MAJ MIN D BYTES
0 0 0 ?? 14 8 65536
503 732 730 sqlite3 ?? 14 14 R 1323008
503 731 730 sqlite3 ?? 14 14 R 1355776
If I understand correctly, the IO load is only 3% when two sqlite3
processes are running, so perhaps I can still tweak sqlite3 to run
faster. I will also copy the database around and see if other disks
(SSD?), operating system (linux?), and file systems can provide better
performance.
Thanks again for all the help,
Bo
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
