-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tomasz Chmielewski wrote:
> Ferenc Wagner schrieb:
>
> (...)
>
>>> I saw an old message from 2006 on this list, where it is said that
>>> "Common understanding is that LVM2 snapshots are unstable".
>>
>> I don't understand this statement.
>
> Anything older than 2.6.18 (so, including 2.6.18) will use lots of
> memory for a snapshot. This means, you won't be able to do more than a
> handful of snapshots even on a system with lots of free memory (you may
> expect trouble i.e. you have 512 MB RAM, only 30 MB used, and want to do
> 10-20 snapshots).
>
> You have 400 MB memory left, did 30 snapshots, and it still works for
> you? You may reconsider - when they fill, (kernel) memory usage will
> rise, until your machine is unresponsive. As it's kernel memory being
> used, oom-killer won't help much here; bigger swap won't help either,
> because real RAM is needed.
>
>
> To make the things worse, you will probably be unable to boot the
> machine again. As the system starts, LVM volumes are detected, memory is
> full again... You're out of luck, unable to even remove the snapshots in
> order to boot properly, unless you have some more RAM sticks at hand to
> fix the problem.
>
>
> Coincidentally, 2.6.18 kernel is the one Xen is based on (at least
> dom0), so if you want your Xen server to be a storage server at the same
> time, you might run into problems as your system grows.
> Some major distributions base on this kernel as well (i.e., Debian Etch).
Right. :)
> A workaround might be:
> - using bigger stripes with LVM (it should take less memory)
> - use a newer kernel - as a rule of thumb - the newer, the better -
> might be problematic with Xen dom0,
> - have storage on a separate machine (i.e., iSCSI SAN) with a newer
> kernel than your Xen dom0 machine
>
>
> Newer kernels (2.6.20, maybe even 2.6.19, and later) are not affected by
> this "phenomenon".
>
> Another LVM disadvantage is that every snapshot means additional writes.
> I.e. if you have a logical volume, and 4 snapshots, writing to the
> origin will mean 4 more writes are needed. This is a serious scalability
> problem.
Well, what I was thinking, was to do a sync on the VM, and flush the
MySQL database and then immediately afterwards, taking a snapshot of the
system, backup that snapshot and then after backup "releasing"
(deleting) the snapshot.
We're stuck with .18 for now, as that's what Debian comes with and we
try to stick with off-the-shelf packages.
Do you think that's feasible?
- -Morten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFI9QVxmq0JiiIWC2oRAg8DAJ48kRkq1NHVOfEPg5UIh5Pc1jRgCwCgxfcD
v97XYGPHBPGJk3FdqSDVszY=
=dpsD
-----END PGP SIGNATURE-----
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home