snapvault slow performance

Hi all,
I face performance issue on snapvault for some specific volumes.
First I explain my configuration. Around 10primary filers are
configured for snapvault on single R200 and used data size is around
45TB. Now almost all volumes are taking place overnight for changed
data but on some volumes it takes more than 24hr. If I compare those
volumes with others then I found that no. of files on these volumes are

more and average file size is also very less. But I feel snapvault
works at block level so these factors should not affect.
So can you suggest where should I hit or how to findout the reason.


Thanks & Regards,
Raju Mahala
Storage & Backup Admin
STMicroelectronics Pvt. Ltd.
INDIA

Raju Mahala wrote:
Hi all,
I face performance issue on snapvault for some specific volumes.
First I explain my configuration. Around 10primary filers are
configured for snapvault on single R200 and used data size is around
45TB. Now almost all volumes are taking place overnight for changed
data but on some volumes it takes more than 24hr. If I compare those
volumes with others then I found that no. of files on these volumes are

more and average file size is also very less. But I feel snapvault
works at block level so these factors should not affect.
So can you suggest where should I hit or how to findout the reason.


while snapvault only transfers changed blocks, it searches for changes
by looking at the files in the filesystem so it is definitely possible
that large numbers of small files will make things worse.

Peter

On 26 Jan 2007 08:56:33 -0800, "Raju Mahala"
wrote:

Hi all,
I face performance issue on snapvault for some specific volumes.
First I explain my configuration. Around 10primary filers are
configured for snapvault on single R200 and used data size is around
45TB. Now almost all volumes are taking place overnight for changed
data but on some volumes it takes more than 24hr. If I compare those
volumes with others then I found that no. of files on these volumes are

more and average file size is also very less. But I feel snapvault
works at block level so these factors should not affect.
So can you suggest where should I hit or how to findout the reason.


Thanks & Regards,
Raju Mahala
Storage & Backup Admin
STMicroelectronics Pvt. Ltd.
INDIA


Snapvault works at the qtree level, so it's a logical seperation from
the physical blocks.

Even though it only transfers changed blocks it still has to map files
to blocks to determine which blocks/files in a qtree changed. This
mapping can be very resource intensive and take a long time if the
file count is extremely high.

If you snapmirror at the volume level (no snapvault available at the
volume level) then you will get pure block transfers with no mapping.
But the benefit of snapvault is the scheduling and snapshot
coalescing, neither of which snapmirror has (qtree or volume level).

~F

On Jan 27, 2:15 am, Faeandar wrote:
On 26 Jan 2007 08:56:33 -0800, "Raju Mahala"
wrote:





Hi all,
I face performance issue on snapvault for some specific volumes.
First I explain my configuration. Around 10primary filers are
configured for snapvault on single R200 and used data size is around
45TB. Now almost all volumes are taking place overnight for changed
data but on some volumes it takes more than 24hr. If I compare those
volumes with others then I found that no. of files on these volumes are

more and average file size is also very less. But I feel snapvault
works at block level so these factors should not affect.
So can you suggest where should I hit or how to findout the reason.

Thanks & Regards,
Raju Mahala
Storage & Backup Admin
STMicroelectronics Pvt. Ltd.
INDIA
Snapvault works at the qtree level, so it's a logical seperation from
the physical blocks.

Even though it only transfers changed blocks it still has to map files
to blocks to determine which blocks/files in a qtree changed. This
mapping can be very resource intensive and take a long time if the
file count is extremely high.

If you snapmirror at the volume level (no snapvault available at the
volume level) then you will get pure block transfers with no mapping.
But the benefit of snapvault is the scheduling and snapshot
coalescing, neither of which snapmirror has (qtree or volume level).

~F- Hide quoted text -- Show quoted text -

first of all thanks alot but just to make crystal clear let me
understand.
you mean to say during transfer from primary to secondary, it goes
through the map (mapping between files and block) on primary to
determine changed block for that particular qtree and in case of
snapmirror, which happens on volume level doesn't require to go
through that map because whole volume is to transfer.
am I getting correct ? so it means volume which has more no of files
will take more time.
One another question. Whether it has any relation with fragmentation
also ?

On 27 Jan 2007 10:35:18 -0800, "Raju Mahala"
wrote:



On Jan 27, 2:15 am, Faeandar wrote:
On 26 Jan 2007 08:56:33 -0800, "Raju Mahala"
wrote:





Hi all,
I face performance issue on snapvault for some specific volumes.
First I explain my configuration. Around 10primary filers are
configured for snapvault on single R200 and used data size is around
45TB. Now almost all volumes are taking place overnight for changed
data but on some volumes it takes more than 24hr. If I compare those
volumes with others then I found that no. of files on these volumes are

more and average file size is also very less. But I feel snapvault
works at block level so these factors should not affect.
So can you suggest where should I hit or how to findout the reason.

Thanks & Regards,
Raju Mahala
Storage & Backup Admin
STMicroelectronics Pvt. Ltd.
INDIA
Snapvault works at the qtree level, so it's a logical seperation from
the physical blocks.

Even though it only transfers changed blocks it still has to map files
to blocks to determine which blocks/files in a qtree changed. This
mapping can be very resource intensive and take a long time if the
file count is extremely high.

If you snapmirror at the volume level (no snapvault available at the
volume level) then you will get pure block transfers with no mapping.
But the benefit of snapvault is the scheduling and snapshot
coalescing, neither of which snapmirror has (qtree or volume level).

~F- Hide quoted text -- Show quoted text -

first of all thanks alot but just to make crystal clear let me
understand.
you mean to say during transfer from primary to secondary, it goes
through the map (mapping between files and block) on primary to
determine changed block for that particular qtree and in case of
snapmirror, which happens on volume level doesn't require to go
through that map because whole volume is to transfer.
am I getting correct ?

Yes. Qtree snapmirror suffers from the same problem as snapvault but
volume snapmirror does not.

so it means volume which has more no of files
will take more time.

yes. This is true on every filesystem to date. Even the so-called
next generation file systems.

One another question. Whether it has any relation with fragmentation
also ?

Not in this case. Fragmentation can cause performance issues for
access but generally speaking, unless the file system is very full,
sequential reads (like backups) suffer less from it. File count is
the main culprit.

~F