2012/11/30 Simon Slavin <slav...@bigfraud.org>:
>
> On 29 Nov 2012, at 5:47pm, Kevin Liao <kevin...@gmail.com> wrote:
>
>> Usually it takes only 11-13
>> ms to execute the update commands. Recently I upgrade the kernel to 3.4.6 but
>> find one problem. It takes about 43-51 ms to finish the update command now.
>
> How are you measuring the amount of time it takes ?
>
> Can you try issuing the same command using the sqlite3 shell tool ? You can
> use the '.timer ON' command and it will time how long a command takes. Try
> this using both kernels and see if the newer kernal slows down the sqlite3
> shell tool too.
>
> Simon.
I use the following function before and after issuing the sqlite update
command to measure the time.
static unsigned int MyGetTimerMS(void)
{
struct timeval tv;
gettimeofday(&tv,NULL);
return ((tv.tv_sec * 1000) + (tv.tv_usec / 1000));
}
2012/11/30 Black, Michael (IS) <michael.bla...@ngc.com>:
> The Linux kernel used to default to writeback for a while until 2.6.36 where
> it then defaulted to ordered.
> So you're seeing the ordered behavior now which is the safest mode.
> http://forum.linode.com/viewtopic.php?t=7815
>
> How to convert to writeback if that's what you want...it is a more dangerous
> option.
> http://ubuntuforums.org/showthread.php?t=107856
>
I have checked my system and found that it has already set to writeback mode.
However, from the information you provided, I finally know that the root cause
is the barrier setting. The barrier is turned on by default for EXT3 on kernel
3.4.6 but is turned off on kernel 2.6.33. After turning off barrier on kernel
3.4.6, the write performance is back to same as kernel 2.6.33. Now at least I
can tell my boss what is going on and let him decide wheter to turn off
barrier. Thanks a lot for all the replies.
Kevin
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
