[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [linux-lvm] Very slow i/o after snapshotting



> Do you write to the snapshot ?

Not so often but there is like 1-5% usage allocation.

> It's known FACT that performance of old snapshot is very far from being
> ideal - it's very simply implementation - for a having consistent system to
> make a backup of the volume - so for backup it doesn't really matter how
> slow is that (it just needs to remain usable)

True. But in case of domains running on a hypervisor, the purpose of doing
a live backup slingshots and dies! I know it's not LVM's fault but
sluggishness is!

> I'd suggest to go with much smaller chunks - i.e. 4-8-16KB - since if you
> update a single 512 sector  -  512KB of data has to be copied!!! so really
> bad idea, unless you overwrite large continuous portion of a device.

I just tried that and got 2-3% improvement.
Here are the gritty details, if someone's interested.
  --- Logical volume ---
  LV Write Access        read/write
  LV snapshot status     active destination for lvma
  LV Status              available
  # open                 1
  LV Size                200.10 GiB
  Current LE             51226
  COW-table size         100.00 GiB
  COW-table LE           25600
  Allocated to snapshot  0.14%
  Snapshot chunk size    4.00 KiB
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     16384
  Block device           253:26

> And yes - if you have rotational hdd - you need to expect horrible seek
> times as well when reading/writing from snapshot target....

Yes, they do. But I reproduced this one with multiple machines (and kernels)!

> And yes - there are some horrible Segate hdd drives (as I've seen just
> yesterday) were 2 disk reading programs at the same time may degrade 100MB/s
> -> 4MB/s (and there is no  dm involved)

Haha, no doubt. Seagates' are the worst ones. IMHO, Hitachi's drives
run cooler and
that's what Nagios tells me!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]