It seems my system CPUs overheats regularly and so the system throttle the CPU speed. It is definitely not good, I need to disassemble my laptop, clean everything, and probably replace the conductive cpu paste.
However, this does not explain anything. sqlite3 appears IO bound, not CPU bound: in fact the programs seems to use 5% of the CPU tops. Any other idea of what can I try? Perhaps my filesystem is misconfigured? On Tue, Aug 18, 2015 at 3:02 PM, Paolo Bolzoni <paolo.bolzoni.brown at gmail.com> wrote: > I think the ATTACH slowness was a misunderstanding caused by the > optimization as it does not happen anymore now I compiled with -O0. > The long time was actually deleting the table from the input db, this > explains also why sqlite was making the journal file for the > operation. > > I am aware it sounds implausible, but I really have not idea why the > standard error message was not appearing before. > > Yes, I am using Linux > > % uname -a > Linux slyrogue 4.1.4-1-ARCH #1 SMP PREEMPT Mon Aug 3 21:30:37 UTC 2015 > x86_64 GNU/Linux > > > About hardware failures I do read some: > mce: [Hardware Error]: Machine check events logged > lines in dmesg. I try to investigate more. > > On Tue, Aug 18, 2015 at 12:28 PM, Simon Slavin <slavins at bigfraud.org> > wrote: >> >> On 18 Aug 2015, at 4:14am, Paolo Bolzoni <paolo.bolzoni.brown at gmail.com> >> wrote: >> >>> In the input and output database I had a table of the same name and using: >>> >>> DROP TABLE IF EXISTS WaysNodes; >>> >>> sqlite3 was actually deleting the table of the input db, this was >>> unexpected as I thought that >>> without any prefix it deleted from the main database. >> >> So did I. I'm glad you have a working solution but there is still something >> wrong. Not only is your text above correct but it shouldn't take 13 hours >> to do an integrity check on a 13 Gig database with simple indexes. >> >> I'm still suspecting some kind of hardware problem. I'll be interested to >> know what happens if you ATTACH your copy of the input database, on the >> other disk, rather than the original. Does it still take a very long time ? >> >> Hmm. What OS are you using again ? Oh, you used iostat. Linux. So not >> the Windows pre-read caching bug. Okay. >> >> Simon. >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users at mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
