Wanting is not needing. If a highly I/O bound process interferes with the I/O performed by other (not I/O bound) processes, then the OS is broken and the proper solution is to get a better O/S. These sorts of problems were solved back in the 60's (okay, maybe 70's).
Therefore, unless a Redmond Operating System is in use (for which the only repair is choosing a better OS), then the problem is most likely bad or ill-suited hardware choices (insufficient cache, no data phase disconnect, excessive queueing, etc) or OS configuration deliberately set to ill-suited values (such as to use a "user" scheduler rather than a "server" scheduler, or a lack of pre-emption). --- Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. Sometimes theory and practice are combined: nothing works and no one knows why. >-----Original Message----- >From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- >boun...@sqlite.org] On Behalf Of Roger Binns >Sent: Monday, 8 December, 2014 16:16 >To: General Discussion of SQLite Database >Subject: Re: [sqlite] Artificially slow VACUUM by injecting a sleep() >somewhere? > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On 12/08/2014 01:35 PM, Max Vlasov wrote: >> I wonder whether I/O "sleeping" possible in the first place. > >In this particular case the OP wants to vacuum while the machine is >doing other I/O activity unrelated to the vacuum. Having more >sleeping during the vacuum will allow the other I/O a greater share. > >Roger > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1 > >iEYEARECAAYFAlSGMTgACgkQmOOfHg372QRxMACgz3qZHBGcUrOyf4DkFR5Km1a4 >jm4AoL49txXLfzPQefbjlnGg9UZ4GtcP >=9gAV >-----END PGP SIGNATURE----- >_______________________________________________ >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
