Re: postgres large database backup

Поиск
Список
Период
Сортировка
От Michael Loftis
Тема Re: postgres large database backup
Дата
Msg-id CAHDg04vE914BtRx9UD-O9WcZgGoT6giZ3aq9tqyjCCebf_AbyA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: postgres large database backup  (Michael Loftis <mloftis@wgops.com>)
Список pgsql-general
On Thu, Dec 1, 2022 at 9:21 AM Michael Loftis <mloftis@wgops.com> wrote:
>
>
>
> On Thu, Dec 1, 2022 at 06:40 Mladen Gogala <gogala.mladen@gmail.com> wrote:
>>
>> On 11/30/22 20:41, Michael Loftis wrote:
>>
>>
>> ZFS snapshots don’t typically have much if  any performance impact versus not having a snapshot (and already being
onZFS) because it’s already doing COW style semantics. 
>>
>> Hi Michael,
>>
>> I am not sure that such statement holds water. When a snapshot is taken, the amount of necessary I/O requests goes
updramatically. For every block that snapshot points to, it is necessary to read the block, write it to the spare
locationand then overwrite it, if you want to write to a block pointed by snapshot. That gives 3 I/O requests for every
blockwritten. NetApp is trying to optimize it by using 64MB blocks, but ZFS on Linux cannot do that, they have to use
standardCoW because they don't have the benefit of their own hardware and OS. And the standard CoW is tripling the
numberof I/O requests for every write to the blocks pointed to by the snapshot, for every snapshot. CoW is a very
expensiveanimal, with horns. 

And if you want to know more, ARS wrote a good ZFS 101 article -- the
write semantics I described in overview are on page three,
https://arstechnica.com/information-technology/2020/05/zfs-101-understanding-zfs-storage-and-performance/3/


--

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler



В списке pgsql-general по дате отправления:

Предыдущее
От: Michael Loftis
Дата:
Сообщение: Re: postgres large database backup
Следующее
От: Dominique Devienne
Дата:
Сообщение: Re: Stored procedure code no longer stored in v14 and v15, changed behaviour