[DRBD-user] Use secondary for read I/O too ?

Lars Ellenberg lars.ellenberg at linbit.com
Mon Aug 25 18:02:53 CEST 2008

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


On Mon, Aug 25, 2008 at 04:12:42PM +0200, Robert wrote:
> Hello,
>
> I was thinking about read optimization a bit more. Especially for  
> database loads two things are important for performance (besides scema  
> optimization :) ) secure async writes (=HW RAID + BBU) and short access  
> times for reads (SSD or many fast disks).

right. short acces times for reads.
low latency for small, random, reads.

and you want to add in network latency,
where you now have only "local disk" latency.

especially for latency, it is best to stay on "local disk" for reads.
unless your network latency is neglectable in comparison with your
local disk latency. which is not the case in my experience.

with typical GbE latency, it will rather double the "access time".

> Simply speaking a DRBD device  is something like a raid1 over the
> network where reads are done from one  side ONLY. If reads would be
> done on both sided - it would in theory be  possible to double the
> read rate.

yes. it should in theory improve throughput for streaming io.

> This would also warm up the buffer  cache on the standby side.

no. it would not, as DRBD sits below the buffer cache.
and yes, it is below the cache for a reason: do avoid deadlock.
it is not that easy.

> A configurable parameter to enable reads on both nodes would
> be nice to  have.

to work correctly, it would need some more than just the config
parameter.

> Is this planned in future drbd releases?

it is unlikely to help reduce latency on small random reads.
it should improve throughput on streaming reads.
it may apear sometime. or not.
I don't think we will add it in the near future.

> (I've seen that hot cache is
> on the roadmap)

that was once on the roadmap, and has been found to be not as easy to
implement, as necessary kernel infrastructure would have to be coded
(and accepted upstream) first.

-- 
: Lars Ellenberg                
: LINBIT HA-Solutions GmbH
: DRBD®/HA support and consulting    http://www.linbit.com

DRBD® and LINBIT® are registered trademarks
of LINBIT Information Technologies GmbH
__
please don't Cc me, but send to list   --   I'm subscribed



More information about the drbd-user mailing list