Something that might be useful is to strace that program Use the "-c" switch to summarize the system calls first. Then use the "-tt" to show relative timestamps to identify specific bottlenecks.
Also, set up a ram disk on the system and see if that's slow too. That will test the LVM idea. Also, try using a memory database and see how that does. Differential diagnostics will get you there eventually. Michael D. Black Senior Scientist Advanced Analytics Directorate Advanced GEOINT Solutions Operating Unit Northrop Grumman Information Systems ________________________________ From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of xp [needforspeed1...@gmail.com] Sent: Monday, July 16, 2012 10:11 AM To: sqlite-users@sqlite.org Subject: EXT :Re: [sqlite] Updating on 32bit os slower than 64bit? Michael, Thanks for your reply. My /home is not NFS mounted. It is mounted locally using LVM. I just tested on another 32 bit linux system (rhel 5, not using LVM). It ran much faster than the 32 bit fedora, not as fast as the 64 bit scientific linux but close. I also tried to test on /tmp on the fedora, but it is very slow. The /tmp is also mounted using LVM. Do you think LVM might be the problem? Thanks! -- View this message in context: http://sqlite.1065341.n5.nabble.com/Updating-on-32bit-os-slower-than-64bit-tp63292p63313.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
