Mailing-List: contact general-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.217.164 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=RavN+moSwwsZda1SyzWLRfxs1vqP/2mz7fn0dBwmbZXYw2tCWJfvGqcQJ2lfQXV61v
         htR5SIhyynlaeKWw9zY8JfZcCyDV7UMlfEzz0be5a5ibKgNcP4xCF4wkwXxVWnXZqyR/
         MInUG8A5ZUtYCPzylmbEEIhWjfz05jtE5PY9A=
MIME-Version: 1.0
In-Reply-To: <22905809.post@talk.nabble.com>
References: <22828976.post@talk.nabble.com>
 <c7d45fc70904011246q44e62e88ycccfa3e08bcbdac6@mail.gmail.com>
	<22905809.post@talk.nabble.com>
Date: Mon, 6 Apr 2009 10:37:21 -0700
Message-ID: <c7d45fc70904061037l5d8bc10dm418d98ea7fec5476@mail.gmail.com>
Subject: Re: replication caching high query and lot of update
From: Ted Dunning <ted.dunning@gmail.com>
To: general@lucene.apache.org
Content-Type: multipart/alternative; boundary=000e0cd47e54a57ae50466e65a0f

--000e0cd47e54a57ae50466e65a0f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

I hope that these are not yet production machines that you are working on.
Otherwise, this could turn into the painful sort of learning experience.

That said, changing I/O scheduler is not likely to cause total disaster.
Normally, this would be considered highly advanced system administration,
but it is relatively safer than many other things you could be doing.

On most modern linux machines there is a directory called /sys that allows
tuning of various aspects of the system.  For changing the I/O scheduler,
you need to find the directory /sys/block/<disk-device> where disk-device
corresponds to the disk you are using.  You can find out which disk using
mount.

On one of my machines, mount output looks like this:

... lots of stuff deleted ..
/dev/sdb1 on /data1 type ext3 (rw,relatime)

That means that /data1 is mount on disk /dev/sdb in partition 1.

Looking at /sys/block/sdb/queue, I see this:

$ ls /sys/block/sdb/queue/
iosched/           max_sectors_kb     read_ahead_kb
max_hw_sectors_kb  nr_requests        scheduler

The directory /sys/block/sdb/queue/iosched is used to tune whichever scheduler
you have chosen and /sys/block/sdb/queue/scheduler is used to select which
scheduler.

I can look at my machine to determine which scheduler I am using:

$ cat /sys/block/sdb/queue/scheduler
noop anticipatory [deadline] cfq

The square brackets indicate which one is in play.

You can find a bit more information at
http://en.wikipedia.org/wiki/Deadline_scheduler or
http://www.mjmwired.net/kernel/Documentation/block/switching-sched.txt

>From here you are pretty much on your own.  You will need to be very careful
to observe how your system works and you will need to understand that the
"files" under /sys are not actually files, but are actually clever little
illusions that let you configure the system (by writing to these "files")
and interrogate the status of the system (by reading them).

My recommendation on the tunables is:

read_expire      *Make this relatively small (say 100 or 200 ms)*
write_expire     *Make this relatively long (5000 to 10000 ms)*
fifo_batch       *Default is 16 which might be fine.  Try larger and
smaller values if you have time.*
writes_starved   *Default is 2, which could be increased reasonably.
Try 5 or 10.*
front_merges     *Leave alone.*

The goal with these recommendations is to aggressively starve write
performance in favor of read performance.  This will slow down your updates
somewhat but will hopefully avoid your current problem of long delays.

On Mon, Apr 6, 2009 at 3:07 AM, sunnyfr <johanna.34@gmail.com> wrote:

>
> Hi Ted,
>
> I'm newbie in linux, can you give me advice to set this ?
>
> Thanks,
>
>
> Ted Dunning wrote:
> >
> > This may be largely due to poor I/O scheduling at the OS layer.
> >
> > Try switching to an I/O scheduler that puts reads ahead of writes.
> >
> > On Wed, Apr 1, 2009 at 8:20 AM, sunnyfr <johanna.34@gmail.com> wrote:
> >
> >> >And about my cache, with a such activity, is it interesting to have a
> >> cache
> >> stored or not ??
> >>
> >> My big point is during replication, my respond time of my request is
> sooo
> >> slow.
> >>
> >
> >
> >
> > --
> > Ted Dunning, CTO
> > DeepDyve
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/replication-caching-high-query-and-lot-of-update-tp22828976p22905809.html
> Sent from the Lucene - General mailing list archive at Nabble.com.
>
>


-- 
Ted Dunning, CTO
DeepDyve

--000e0cd47e54a57ae50466e65a0f--