* snapshot destruction making IO extremely slow
@ 2015-03-22 8:11 Marc Cousin
2015-03-22 8:23 ` Marc Cousin
2015-03-25 1:19 ` David Sterba
0 siblings, 2 replies; 14+ messages in thread
From: Marc Cousin @ 2015-03-22 8:11 UTC (permalink / raw)
To: linux-btrfs
Hi,
I've noticed this problem for a while (I started to use snapper a while ago): while destroying snapshots, it's almost impossible to do IO on the volume.
There is almost no IO active on this volume (it is made of sdb,sdc and sdd).
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
sdd 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
sdc 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
sde 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
sdg 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
avg-cpu: %user %nice %system %iowait %steal %idle
1,77 0,00 13,24 0,00 0,00 84,99
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
sdd 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
sdc 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
sde 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
sdg 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
avg-cpu: %user %nice %system %iowait %steal %idle
0,88 0,00 13,03 0,25 0,00 85,84
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
sda 0,00 1,00 4,00 2,00 0,08 0,01 30,67 0,01 1,67 0,00 5,00 1,67 1,00
sdd 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
sdc 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
sde 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
sdg 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
(sda isn't into this btrfs filesystem)
The btrfs cleaner is 100% active:
1501 root 20 0 0 0 0 R 100,0 0,0 9:10.40 [btrfs-cleaner]
As soon as it terminates its job, the filesystem becomes usable again. But while waiting it is extremely unresponsive. Any program doing a write there hangs.
Some more information: the 3 disks are 2.7TB, the raid is RAID1
# btrfs fi df /mnt/btrfs
Data, RAID1: total=3.18TiB, used=3.14TiB
System, RAID1: total=32.00MiB, used=480.00KiB
Metadata, RAID1: total=6.00GiB, used=4.32GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
What is "funny" is that the filesystem seems to be working again when there is some IO activity and btrfs-cleaner gets to a lower cpu usage (around 70%).
By the way, there are quite a few snapshots there:
# btrfs subvolume list /mnt/btrfs | wc -l
142
and I think snapper tries to destroy around 10 of them on one go.
I can do whatever test you want, as long as I keep the data on my disks :)
Regards,
Marc
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: snapshot destruction making IO extremely slow
2015-03-22 8:11 snapshot destruction making IO extremely slow Marc Cousin
@ 2015-03-22 8:23 ` Marc Cousin
2015-03-25 1:19 ` David Sterba
1 sibling, 0 replies; 14+ messages in thread
From: Marc Cousin @ 2015-03-22 8:23 UTC (permalink / raw)
To: linux-btrfs
On 22/03/2015 09:11, Marc Cousin wrote:
> Hi,
>
> I've noticed this problem for a while (I started to use snapper a while ago): while destroying snapshots, it's almost impossible to do IO on the volume.
>
> There is almost no IO active on this volume (it is made of sdb,sdc and sdd).
>
>
>
> Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
> sdb 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> sdd 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> sdc 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> sde 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> sdg 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
>
> avg-cpu: %user %nice %system %iowait %steal %idle
> 1,77 0,00 13,24 0,00 0,00 84,99
>
> Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
> sdb 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> sdd 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> sdc 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> sde 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> sdg 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
>
> avg-cpu: %user %nice %system %iowait %steal %idle
> 0,88 0,00 13,03 0,25 0,00 85,84
>
> Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
> sdb 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> sda 0,00 1,00 4,00 2,00 0,08 0,01 30,67 0,01 1,67 0,00 5,00 1,67 1,00
> sdd 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> sdc 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> sde 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
> sdg 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
>
> (sda isn't into this btrfs filesystem)
>
> The btrfs cleaner is 100% active:
>
> 1501 root 20 0 0 0 0 R 100,0 0,0 9:10.40 [btrfs-cleaner]
>
> As soon as it terminates its job, the filesystem becomes usable again. But while waiting it is extremely unresponsive. Any program doing a write there hangs.
>
> Some more information: the 3 disks are 2.7TB, the raid is RAID1
>
> # btrfs fi df /mnt/btrfs
> Data, RAID1: total=3.18TiB, used=3.14TiB
> System, RAID1: total=32.00MiB, used=480.00KiB
> Metadata, RAID1: total=6.00GiB, used=4.32GiB
> GlobalReserve, single: total=512.00MiB, used=0.00B
>
>
> What is "funny" is that the filesystem seems to be working again when there is some IO activity and btrfs-cleaner gets to a lower cpu usage (around 70%).
>
> By the way, there are quite a few snapshots there:
>
> # btrfs subvolume list /mnt/btrfs | wc -l
> 142
>
> and I think snapper tries to destroy around 10 of them on one go.
>
> I can do whatever test you want, as long as I keep the data on my disks :)
>
> Regards,
>
> Marc
>
I forgot the obvious. Kernel 3.19.2 (from archlinux). :)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: snapshot destruction making IO extremely slow
2015-03-22 8:11 snapshot destruction making IO extremely slow Marc Cousin
2015-03-22 8:23 ` Marc Cousin
@ 2015-03-25 1:19 ` David Sterba
2015-03-25 10:55 ` Marc Cousin
1 sibling, 1 reply; 14+ messages in thread
From: David Sterba @ 2015-03-25 1:19 UTC (permalink / raw)
To: Marc Cousin; +Cc: linux-btrfs
On Sun, Mar 22, 2015 at 09:11:03AM +0100, Marc Cousin wrote:
> I've noticed this problem for a while (I started to use snapper a
> while ago): while destroying snapshots, it's almost impossible to do
> IO on the volume.
The snapshots get cleaned in the background, which usuall touches lots
of data (depending on the "age" of the extents, IOW the level of sharing
among the live and deleted snapshots).
The slowdown is caused due to contention on the metadata (locking,
readig from disk, scattered blocks, lots of seeking).
Snapper might add to that if you have
EMPTY_PRE_POST_CLEANUP="yes"
as it reads the pre/post snapshots and deletes them if the diff is
empty. This adds some IO stress.
> The btrfs cleaner is 100% active:
>
> 1501 root 20 0 0 0 0 R 100,0 0,0 9:10.40 [btrfs-cleaner]
That points to the snapshot cleaning, but the cleaner thread does more
than that. It may also process delayed file deletion and work scheduled
if 'autodefrag' is on.
> As soon as it terminates its job, the filesystem becomes usable again.
> But while waiting it is extremely unresponsive. Any program doing a
> write there hangs.
>
> Some more information: the 3 disks are 2.7TB, the raid is RAID1
>
> # btrfs fi df /mnt/btrfs
> Data, RAID1: total=3.18TiB, used=3.14TiB
> System, RAID1: total=32.00MiB, used=480.00KiB
> Metadata, RAID1: total=6.00GiB, used=4.32GiB
Space looks ok, enough data and metadata so it's not affected by low
space conditions.
> What is "funny" is that the filesystem seems to be working again when
> there is some IO activity and btrfs-cleaner gets to a lower cpu usage
> (around 70%).
Possibly a behaviour caused by scheduling (both cpu and io), the other
process gets a slice and slows down cleaner that hogs the system.
> By the way, there are quite a few snapshots there:
>
> # btrfs subvolume list /mnt/btrfs | wc -l
> 142
>
> and I think snapper tries to destroy around 10 of them on one go.
The snapshots get cleaned in the order of deletion, and if there is some
amount of sharing, the metadata blocks are probably cached. So it may
actually help to delete them in a group.
> I can do whatever test you want, as long as I keep the data on my disks :)
So far it looks like effects of filesystem aging in the presence of
snapshots. Right now, I think we could try to somehow adjust the io
scheduling priority in case the cleaner processes the deleted
subvolumes, but this is unfortunatelly done in an asynchronous manner
and the metadata are read by other threads so this could be fairly
intrusive patch.
Or, introduce an interface that would set the subvolume cleaning
behaviour, eg. only if idle, or normal or immediate. The dead and
uncleaned subvolumes pin the space so we cannot make it 'idle' by
default.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: snapshot destruction making IO extremely slow
2015-03-25 1:19 ` David Sterba
@ 2015-03-25 10:55 ` Marc Cousin
2015-03-25 11:38 ` Rich Freeman
2015-03-30 14:25 ` David Sterba
0 siblings, 2 replies; 14+ messages in thread
From: Marc Cousin @ 2015-03-25 10:55 UTC (permalink / raw)
To: dsterba, linux-btrfs
On 25/03/2015 02:19, David Sterba wrote:
>
> The snapshots get cleaned in the background, which usuall touches lots
> of data (depending on the "age" of the extents, IOW the level of sharing
> among the live and deleted snapshots).
>
> The slowdown is caused due to contention on the metadata (locking,
> readig from disk, scattered blocks, lots of seeking).
>
> Snapper might add to that if you have
>
> EMPTY_PRE_POST_CLEANUP="yes"
>
> as it reads the pre/post snapshots and deletes them if the diff is
> empty. This adds some IO stress.
I couldn't find a clear explanation in the documentation. Does it mean
that when there is absolutely no difference between two snapshots, one
of them is deleted ? And that snapper does a diff between them to
determine that ?
If so, yes, I can remove it, I don't care about that :)
>
>> The btrfs cleaner is 100% active:
>>
>> 1501 root 20 0 0 0 0 R 100,0 0,0 9:10.40 [btrfs-cleaner]
>
> That points to the snapshot cleaning, but the cleaner thread does more
> than that. It may also process delayed file deletion and work scheduled
> if 'autodefrag' is on.
autodefrag is activated. These are mechanical drives, so I'd rather keep
it on, shouldn't I ?
>
>> What is "funny" is that the filesystem seems to be working again when
>> there is some IO activity and btrfs-cleaner gets to a lower cpu usage
>> (around 70%).
>
> Possibly a behaviour caused by scheduling (both cpu and io), the other
> process gets a slice and slows down cleaner that hogs the system.
I have almost no IO on these disks during the problem (I had put an
iostat on the first email). Only one CPU core at 100% load. That's why I
felt it looked more like a locking or serialization issue.
>
>> By the way, there are quite a few snapshots there:
>>
>> # btrfs subvolume list /mnt/btrfs | wc -l
>> 142
>>
>> and I think snapper tries to destroy around 10 of them on one go.
>
> The snapshots get cleaned in the order of deletion, and if there is some
> amount of sharing, the metadata blocks are probably cached. So it may
> actually help to delete them in a group.
There is a lot of sharing between the snapshots. Only a few files are
altered between them. I think I only have the slowdown while the kernel
thread is at 100%. When it is lower (and I have disk activity), I have a
slight slowdown, but it is completely bearable.
>
>> I can do whatever test you want, as long as I keep the data on my disks :)
>
> So far it looks like effects of filesystem aging in the presence of
> snapshots. Right now, I think we could try to somehow adjust the io
> scheduling priority in case the cleaner processes the deleted
> subvolumes, but this is unfortunatelly done in an asynchronous manner
> and the metadata are read by other threads so this could be fairly
> intrusive patch.
I have almost no IO when the problem occurs.
Regards
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: snapshot destruction making IO extremely slow
2015-03-25 10:55 ` Marc Cousin
@ 2015-03-25 11:38 ` Rich Freeman
2015-03-30 14:30 ` David Sterba
2015-03-30 14:25 ` David Sterba
1 sibling, 1 reply; 14+ messages in thread
From: Rich Freeman @ 2015-03-25 11:38 UTC (permalink / raw)
To: Marc Cousin; +Cc: dsterba, Btrfs BTRFS
On Wed, Mar 25, 2015 at 6:55 AM, Marc Cousin <cousinmarc@gmail.com> wrote:
> On 25/03/2015 02:19, David Sterba wrote:
>> as it reads the pre/post snapshots and deletes them if the diff is
>> empty. This adds some IO stress.
>
> I couldn't find a clear explanation in the documentation. Does it mean
> that when there is absolutely no difference between two snapshots, one
> of them is deleted ? And that snapper does a diff between them to
> determine that ?
>
It seems like there should be some supported way of doing a diff on
two btrfs subvolumes. There should be no need to recursively scan
trees if the heads of those trees are shared. If I change one file at
the bottom of a 10 layer directory hierarchy, it should only take a
small number of reads to determine this.
The problem is that we don't have any functionality in kernel space to
do this (that I'm aware of), and we don't expose the necessary
information to userspace for it to do this smartly (again, as far as
I'm aware).
Maybe there would be some way to do it using btrfs send and parsing the output.
--
Rich
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: snapshot destruction making IO extremely slow
2015-03-25 10:55 ` Marc Cousin
2015-03-25 11:38 ` Rich Freeman
@ 2015-03-30 14:25 ` David Sterba
2015-03-30 15:09 ` Marc Cousin
1 sibling, 1 reply; 14+ messages in thread
From: David Sterba @ 2015-03-30 14:25 UTC (permalink / raw)
To: Marc Cousin; +Cc: linux-btrfs
On Wed, Mar 25, 2015 at 11:55:36AM +0100, Marc Cousin wrote:
> On 25/03/2015 02:19, David Sterba wrote:
> > Snapper might add to that if you have
> >
> > EMPTY_PRE_POST_CLEANUP="yes"
> >
> > as it reads the pre/post snapshots and deletes them if the diff is
> > empty. This adds some IO stress.
>
> I couldn't find a clear explanation in the documentation. Does it mean
> that when there is absolutely no difference between two snapshots, one
> of them is deleted ?
Only the pre-post snapshots, ie. no timeline or other types (eg.
manually created one).
> And that snapper does a diff between them to
> determine that ?
AFAIK yes.
> If so, yes, I can remove it, I don't care about that :)
>
> >
> >> The btrfs cleaner is 100% active:
> >>
> >> 1501 root 20 0 0 0 0 R 100,0 0,0 9:10.40 [btrfs-cleaner]
> >
> > That points to the snapshot cleaning, but the cleaner thread does more
> > than that. It may also process delayed file deletion and work scheduled
> > if 'autodefrag' is on.
>
> autodefrag is activated. These are mechanical drives, so I'd rather keep
> it on, shouldn't I ?
You should (I do have autogefrag on), unless you applications are
latency sensitive and you can measure the difference. Autodefrag tends
to read/write surrounding blocks for random write so it may imply some
seek penalty if the affected block is far from the others.
> >> What is "funny" is that the filesystem seems to be working again when
> >> there is some IO activity and btrfs-cleaner gets to a lower cpu usage
> >> (around 70%).
> >
> > Possibly a behaviour caused by scheduling (both cpu and io), the other
> > process gets a slice and slows down cleaner that hogs the system.
>
> I have almost no IO on these disks during the problem (I had put an
> iostat on the first email). Only one CPU core at 100% load. That's why I
> felt it looked more like a locking or serialization issue.
So it would be good to sample the active threads and see where it's
spending the time. It could be the somewhere in the rb-tree representing
extents, but that's a guess.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: snapshot destruction making IO extremely slow
2015-03-25 11:38 ` Rich Freeman
@ 2015-03-30 14:30 ` David Sterba
0 siblings, 0 replies; 14+ messages in thread
From: David Sterba @ 2015-03-30 14:30 UTC (permalink / raw)
To: Rich Freeman; +Cc: Marc Cousin, Btrfs BTRFS
On Wed, Mar 25, 2015 at 07:38:20AM -0400, Rich Freeman wrote:
> On Wed, Mar 25, 2015 at 6:55 AM, Marc Cousin <cousinmarc@gmail.com> wrote:
> > On 25/03/2015 02:19, David Sterba wrote:
> >> as it reads the pre/post snapshots and deletes them if the diff is
> >> empty. This adds some IO stress.
> >
> > I couldn't find a clear explanation in the documentation. Does it mean
> > that when there is absolutely no difference between two snapshots, one
> > of them is deleted ? And that snapper does a diff between them to
> > determine that ?
> >
>
> It seems like there should be some supported way of doing a diff on
> two btrfs subvolumes.
> The problem is that we don't have any functionality in kernel space to
> do this (that I'm aware of), and we don't expose the necessary
> information to userspace for it to do this smartly (again, as far as
> I'm aware).
> Maybe there would be some way to do it using btrfs send and parsing the output.
If the subvolumes are read-only than the lightweight send (ioctl with
flag bit set BTRFS_SEND_FLAG_NO_FILE_DATA) could be used and I think
this was the expected usecase.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: snapshot destruction making IO extremely slow
2015-03-30 14:25 ` David Sterba
@ 2015-03-30 15:09 ` Marc Cousin
2015-03-31 17:05 ` David Sterba
0 siblings, 1 reply; 14+ messages in thread
From: Marc Cousin @ 2015-03-30 15:09 UTC (permalink / raw)
To: dsterba, linux-btrfs
On 30/03/2015 16:25, David Sterba wrote:
> On Wed, Mar 25, 2015 at 11:55:36AM +0100, Marc Cousin wrote:
>> On 25/03/2015 02:19, David Sterba wrote:
>>> Snapper might add to that if you have
>>>
>>> EMPTY_PRE_POST_CLEANUP="yes"
>>>
>>> as it reads the pre/post snapshots and deletes them if the diff is
>>> empty. This adds some IO stress.
>>
>> I couldn't find a clear explanation in the documentation. Does it mean
>> that when there is absolutely no difference between two snapshots, one
>> of them is deleted ?
>
> Only the pre-post snapshots, ie. no timeline or other types (eg.
> manually created one).
>
>> And that snapper does a diff between them to
>> determine that ?
>
> AFAIK yes.
>
>> If so, yes, I can remove it, I don't care about that :)
>>
>>>
>>>> The btrfs cleaner is 100% active:
>>>>
>>>> 1501 root 20 0 0 0 0 R 100,0 0,0 9:10.40 [btrfs-cleaner]
>>>
>>> That points to the snapshot cleaning, but the cleaner thread does more
>>> than that. It may also process delayed file deletion and work scheduled
>>> if 'autodefrag' is on.
>>
>> autodefrag is activated. These are mechanical drives, so I'd rather keep
>> it on, shouldn't I ?
>
> You should (I do have autogefrag on), unless you applications are
> latency sensitive and you can measure the difference. Autodefrag tends
> to read/write surrounding blocks for random write so it may imply some
> seek penalty if the affected block is far from the others.
>
>>>> What is "funny" is that the filesystem seems to be working again when
>>>> there is some IO activity and btrfs-cleaner gets to a lower cpu usage
>>>> (around 70%).
>>>
>>> Possibly a behaviour caused by scheduling (both cpu and io), the other
>>> process gets a slice and slows down cleaner that hogs the system.
>>
>> I have almost no IO on these disks during the problem (I had put an
>> iostat on the first email). Only one CPU core at 100% load. That's why I
>> felt it looked more like a locking or serialization issue.
>
> So it would be good to sample the active threads and see where it's
> spending the time. It could be the somewhere in the rb-tree representing
> extents, but that's a guess.
>
I just need to be told how to do that :)
Something like a perf top ?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: snapshot destruction making IO extremely slow
2015-03-30 15:09 ` Marc Cousin
@ 2015-03-31 17:05 ` David Sterba
2015-04-20 9:51 ` Marc Cousin
0 siblings, 1 reply; 14+ messages in thread
From: David Sterba @ 2015-03-31 17:05 UTC (permalink / raw)
To: Marc Cousin; +Cc: linux-btrfs
On Mon, Mar 30, 2015 at 05:09:52PM +0200, Marc Cousin wrote:
> > So it would be good to sample the active threads and see where it's
> > spending the time. It could be the somewhere in the rb-tree representing
> > extents, but that's a guess.
> >
> I just need to be told how to do that :)
>
> Something like a perf top ?
for i in `pgrep btrfs`; do
ps $i
sudo cat /proc/$i/stack 2>/dev/null
done
and capture samples every second.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: snapshot destruction making IO extremely slow
2015-03-31 17:05 ` David Sterba
@ 2015-04-20 9:51 ` Marc Cousin
2015-04-23 15:42 ` Marc Cousin
0 siblings, 1 reply; 14+ messages in thread
From: Marc Cousin @ 2015-04-20 9:51 UTC (permalink / raw)
To: dsterba, linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 60922 bytes --]
On 31/03/2015 19:05, David Sterba wrote:
> On Mon, Mar 30, 2015 at 05:09:52PM +0200, Marc Cousin wrote:
>>> So it would be good to sample the active threads and see where it's
>>> spending the time. It could be the somewhere in the rb-tree representing
>>> extents, but that's a guess.
>>>
>> I just need to be told how to do that :)
>>
>> Something like a perf top ?
>
> for i in `pgrep btrfs`; do
> ps $i
> sudo cat /proc/$i/stack 2>/dev/null
> done
>
> and capture samples every second.
>
Sorry, it took me a while to reproduce this (I needed to be in front of the machine when it happens :) )
It's not the same machine, anyway, but the problem is the same.
Here, it is on a SSD-backed storage, with a dm-crypt in between. The other machine where it occurs has nothing of this, btrfs uses bare disks.
Anyway, here it is.
First, to see when it happens:
while true; do date; time touch /home/test; time rm /home/test ; sleep 1; done
Here is an excerpt
lun. avril 20 11:42:24 CEST 2015
real 0m0.001s
user 0m0.003s
sys 0m0.000s
real 0m0.001s
user 0m0.000s
sys 0m0.000s
lun. avril 20 11:42:25 CEST 2015
real 0m0.001s
user 0m0.000s
sys 0m0.000s
real 0m0.001s
user 0m0.000s
sys 0m0.000s
lun. avril 20 11:42:26 CEST 2015
real 0m0.001s
user 0m0.000s
sys 0m0.000s
real 0m0.001s
user 0m0.000s
sys 0m0.000s
lun. avril 20 11:42:27 CEST 2015
real 1m2.225s <---- ouch, more than one minute to touch a file.
user 0m0.000s
sys 0m0.000s
real 0m0.001s
user 0m0.000s
sys 0m0.000s
lun. avril 20 11:43:30 CEST 2015
real 0m0.001s
user 0m0.000s
sys 0m0.000s
real 0m0.001s
user 0m0.000s
sys 0m0.000s
There was almost nothing else happening on this machine. At least nothing IO-intensive.
On the same period, here is what happens on IOs (sorry, it's quite big):
iostat -x -m 1 -t
20/04/2015 11:42:23
avg-cpu: %user %nice %system %iowait %steal %idle
5,78 0,00 30,15 0,00 0,00 64,07
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:24
avg-cpu: %user %nice %system %iowait %steal %idle
10,50 0,00 31,00 0,00 0,00 58,50
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:25
avg-cpu: %user %nice %system %iowait %steal %idle
14,36 0,00 36,67 0,00 0,00 48,97
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 375,00 0,00 2,20 12,03 0,09 0,24 0,00 0,24 0,02 0,60
dm-0 0,00 0,00 0,00 375,00 0,00 2,20 12,03 1,22 3,26 0,00 3,26 0,02 0,70
dm-1 0,00 0,00 0,00 375,00 0,00 2,20 12,03 1,22 3,26 0,00 3,26 0,02 0,60
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:26
avg-cpu: %user %nice %system %iowait %steal %idle
10,00 0,00 33,08 0,00 0,00 56,92
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 2,00 0,00 0,03 0,00 32,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 2,00 0,00 0,03 0,00 32,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 2,00 0,00 0,03 0,00 32,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:27
avg-cpu: %user %nice %system %iowait %steal %idle
20,81 0,00 30,96 0,00 0,00 48,22
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 9,00 0,00 0,14 0,00 32,00 0,01 1,11 1,11 0,00 0,44 0,40
dm-0 0,00 0,00 9,00 0,00 0,14 0,00 32,00 0,01 1,11 1,11 0,00 0,33 0,30
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 9,00 0,00 0,14 0,00 32,00 0,01 1,11 1,11 0,00 0,33 0,30
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:28
avg-cpu: %user %nice %system %iowait %steal %idle
8,84 0,00 31,82 0,25 0,00 59,09
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:29
avg-cpu: %user %nice %system %iowait %steal %idle
15,91 0,00 34,34 0,00 0,00 49,75
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:30
avg-cpu: %user %nice %system %iowait %steal %idle
10,78 0,00 35,34 0,25 0,00 53,63
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 2,00 14,00 1,04 0,05 138,50 0,03 2,06 3,50 1,86 1,25 2,00
dm-0 0,00 0,00 2,00 14,00 1,04 0,05 138,50 0,03 2,06 3,50 1,86 1,25 2,00
dm-1 0,00 0,00 0,00 12,00 0,00 0,05 8,00 0,02 1,42 0,00 1,42 1,42 1,70
dm-2 0,00 0,00 2,00 0,00 1,04 0,00 1060,00 0,01 3,50 3,50 0,00 2,00 0,40
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:31
avg-cpu: %user %nice %system %iowait %steal %idle
8,31 0,00 27,20 0,50 0,00 63,98
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:32
avg-cpu: %user %nice %system %iowait %steal %idle
9,50 0,00 34,00 0,00 0,00 56,50
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:33
avg-cpu: %user %nice %system %iowait %steal %idle
15,29 0,00 35,09 0,00 0,00 49,62
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:34
avg-cpu: %user %nice %system %iowait %steal %idle
8,47 0,00 33,90 0,00 0,00 57,63
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:35
avg-cpu: %user %nice %system %iowait %steal %idle
15,12 0,00 31,95 0,00 0,00 52,93
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 2,00 0,00 0,01 0,00 8,00 0,00 1,50 1,50 0,00 1,50 0,30
dm-0 0,00 0,00 2,00 0,00 0,01 0,00 8,00 0,00 1,50 1,50 0,00 1,50 0,30
dm-1 0,00 0,00 2,00 0,00 0,01 0,00 8,00 0,00 1,50 1,50 0,00 1,50 0,30
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:36
avg-cpu: %user %nice %system %iowait %steal %idle
21,45 0,00 37,59 0,00 0,00 40,96
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 6,00 0,00 0,02 5,33 0,01 1,67 0,00 1,67 1,17 0,70
dm-0 0,00 0,00 0,00 6,00 0,00 0,02 5,33 0,01 1,67 0,00 1,67 1,17 0,70
dm-1 0,00 0,00 0,00 4,00 0,00 0,02 8,00 0,01 1,50 0,00 1,50 1,75 0,70
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:37
avg-cpu: %user %nice %system %iowait %steal %idle
7,90 0,00 32,84 0,00 0,00 59,26
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:38
avg-cpu: %user %nice %system %iowait %steal %idle
4,53 0,00 28,21 0,00 0,00 67,25
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:39
avg-cpu: %user %nice %system %iowait %steal %idle
14,25 0,00 36,00 0,00 0,00 49,75
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 1,00 0,00 0,00 8,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 1,00 0,00 0,00 8,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 1,00 0,00 0,00 8,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:40
avg-cpu: %user %nice %system %iowait %steal %idle
9,18 0,00 33,00 0,00 0,00 57,82
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 616,00 0,00 4,41 14,66 0,95 1,55 0,00 1,55 0,02 1,30
dm-0 0,00 0,00 0,00 616,00 0,00 4,41 14,66 5,01 8,14 0,00 8,14 0,02 1,30
dm-1 0,00 0,00 0,00 616,00 0,00 4,41 14,66 5,01 8,14 0,00 8,14 0,02 1,30
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:41
avg-cpu: %user %nice %system %iowait %steal %idle
9,27 0,00 32,08 0,25 0,00 58,40
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 10,00 0,00 0,03 6,40 0,01 1,30 0,00 1,30 1,00 1,00
dm-0 0,00 0,00 0,00 10,00 0,00 0,03 6,40 0,01 1,30 0,00 1,30 1,00 1,00
dm-1 0,00 0,00 0,00 8,00 0,00 0,03 8,00 0,01 1,25 0,00 1,25 1,25 1,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:42
avg-cpu: %user %nice %system %iowait %steal %idle
10,10 0,00 29,29 0,00 0,00 60,61
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:43
avg-cpu: %user %nice %system %iowait %steal %idle
10,84 0,00 33,74 0,25 0,00 55,17
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:44
avg-cpu: %user %nice %system %iowait %steal %idle
9,55 0,00 34,42 0,00 0,00 56,03
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:45
avg-cpu: %user %nice %system %iowait %steal %idle
9,34 0,00 29,80 0,00 0,00 60,86
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:46
avg-cpu: %user %nice %system %iowait %steal %idle
3,02 0,00 29,72 0,00 0,00 67,25
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:47
avg-cpu: %user %nice %system %iowait %steal %idle
6,55 0,00 31,49 0,25 0,00 61,71
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 6,00 0,00 0,02 5,33 0,01 1,67 0,00 1,67 1,17 0,70
dm-0 0,00 0,00 0,00 6,00 0,00 0,02 5,33 0,01 1,67 0,00 1,67 1,17 0,70
dm-1 0,00 0,00 0,00 4,00 0,00 0,02 8,00 0,01 1,50 0,00 1,50 1,75 0,70
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:48
avg-cpu: %user %nice %system %iowait %steal %idle
7,04 0,00 31,41 0,00 0,00 61,56
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:49
avg-cpu: %user %nice %system %iowait %steal %idle
3,26 0,00 26,57 0,00 0,00 70,18
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:50
avg-cpu: %user %nice %system %iowait %steal %idle
4,53 0,00 31,23 0,00 0,00 64,23
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:51
avg-cpu: %user %nice %system %iowait %steal %idle
16,46 0,00 33,67 0,00 0,00 49,88
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:52
avg-cpu: %user %nice %system %iowait %steal %idle
5,01 0,00 31,58 0,00 0,00 63,41
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:53
avg-cpu: %user %nice %system %iowait %steal %idle
3,26 0,00 27,32 0,00 0,00 69,42
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:54
avg-cpu: %user %nice %system %iowait %steal %idle
10,78 0,00 32,33 0,00 0,00 56,89
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 2,00 0,00 10,00 0,00 0,04 8,00 0,01 1,00 0,00 1,00 0,60 0,60
dm-0 0,00 0,00 0,00 12,00 0,00 0,04 6,67 0,01 0,83 0,00 0,83 0,58 0,70
dm-1 0,00 0,00 0,00 4,00 0,00 0,02 8,00 0,01 1,75 0,00 1,75 1,75 0,70
dm-2 0,00 0,00 0,00 6,00 0,00 0,02 8,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:55
avg-cpu: %user %nice %system %iowait %steal %idle
8,33 0,00 33,84 0,00 0,00 57,83
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 422,00 0,00 2,28 11,07 0,01 0,04 0,00 0,04 0,02 1,00
dm-0 0,00 0,00 0,00 422,00 0,00 2,28 11,07 2,36 5,59 0,00 5,59 0,02 1,00
dm-1 0,00 0,00 0,00 422,00 0,00 2,28 11,07 2,36 5,59 0,00 5,59 0,02 1,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:56
avg-cpu: %user %nice %system %iowait %steal %idle
5,03 0,00 30,15 0,00 0,00 64,82
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:57
avg-cpu: %user %nice %system %iowait %steal %idle
19,90 0,00 28,26 0,00 0,00 51,84
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:58
avg-cpu: %user %nice %system %iowait %steal %idle
30,90 0,00 36,68 0,00 0,00 32,41
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:42:59
avg-cpu: %user %nice %system %iowait %steal %idle
34,59 0,00 33,58 0,00 0,00 31,83
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:00
avg-cpu: %user %nice %system %iowait %steal %idle
27,14 0,00 29,65 0,50 0,00 42,71
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 7,00 0,00 0,02 5,71 0,02 2,29 0,00 2,29 2,00 1,40
dm-0 0,00 0,00 0,00 7,00 0,00 0,02 5,71 0,02 2,29 0,00 2,29 1,86 1,30
dm-1 0,00 0,00 0,00 5,00 0,00 0,02 8,00 0,01 2,60 0,00 2,60 2,60 1,30
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:01
avg-cpu: %user %nice %system %iowait %steal %idle
23,38 0,00 32,09 0,00 0,00 44,53
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:02
avg-cpu: %user %nice %system %iowait %steal %idle
9,32 0,00 31,99 0,00 0,00 58,69
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:03
avg-cpu: %user %nice %system %iowait %steal %idle
12,85 0,00 31,74 0,00 0,00 55,42
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 19,00 1,00 0,34 0,00 35,20 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 19,00 1,00 0,34 0,00 35,20 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 19,00 0,00 0,34 0,00 36,63 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 1,00 0,00 0,00 8,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:04
avg-cpu: %user %nice %system %iowait %steal %idle
4,00 0,00 28,25 0,00 0,00 67,75
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:05
avg-cpu: %user %nice %system %iowait %steal %idle
7,05 0,00 32,49 0,00 0,00 60,45
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:06
avg-cpu: %user %nice %system %iowait %steal %idle
11,72 0,00 33,92 0,50 0,00 53,87
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 15,00 0,00 0,05 6,93 0,01 0,93 0,00 0,93 0,67 1,00
dm-0 0,00 0,00 0,00 15,00 0,00 0,05 6,93 0,01 0,93 0,00 0,93 0,67 1,00
dm-1 0,00 0,00 0,00 13,00 0,00 0,05 8,00 0,01 0,77 0,00 0,77 0,77 1,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:07
avg-cpu: %user %nice %system %iowait %steal %idle
3,53 0,00 27,71 0,00 0,00 68,77
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:08
avg-cpu: %user %nice %system %iowait %steal %idle
4,80 0,00 29,80 0,00 0,00 65,40
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:09
avg-cpu: %user %nice %system %iowait %steal %idle
10,13 0,00 32,41 0,00 0,00 57,47
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 6,00 0,00 0,02 8,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 6,00 0,00 0,02 8,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 6,00 0,00 0,02 8,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:10
avg-cpu: %user %nice %system %iowait %steal %idle
4,29 0,00 33,08 0,00 0,00 62,63
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 584,00 0,00 4,38 15,34 1,08 1,85 0,00 1,85 0,02 1,00
dm-0 0,00 0,00 0,00 584,00 0,00 4,38 15,34 3,34 5,71 0,00 5,71 0,02 1,00
dm-1 0,00 0,00 0,00 584,00 0,00 4,38 15,34 3,34 5,71 0,00 5,71 0,02 1,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:11
avg-cpu: %user %nice %system %iowait %steal %idle
4,76 0,00 28,07 0,25 0,00 66,92
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 7,00 0,00 0,02 5,71 0,02 2,29 0,00 2,29 1,86 1,30
dm-0 0,00 0,00 0,00 7,00 0,00 0,02 5,71 0,02 2,43 0,00 2,43 1,86 1,30
dm-1 0,00 0,00 0,00 5,00 0,00 0,02 8,00 0,01 2,60 0,00 2,60 2,60 1,30
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:12
avg-cpu: %user %nice %system %iowait %steal %idle
6,30 0,00 30,23 0,00 0,00 63,48
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:13
avg-cpu: %user %nice %system %iowait %steal %idle
15,33 0,00 36,43 0,25 0,00 47,99
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:14
avg-cpu: %user %nice %system %iowait %steal %idle
6,53 0,00 32,66 0,00 0,00 60,80
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:15
avg-cpu: %user %nice %system %iowait %steal %idle
7,52 0,00 27,57 0,00 0,00 64,91
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:16
avg-cpu: %user %nice %system %iowait %steal %idle
4,75 0,00 31,00 0,00 0,00 64,25
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:17
avg-cpu: %user %nice %system %iowait %steal %idle
8,02 0,00 31,08 0,25 0,00 60,65
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 6,00 0,00 0,02 5,33 0,02 2,83 0,00 2,83 2,17 1,30
dm-0 0,00 0,00 0,00 6,00 0,00 0,02 5,33 0,02 2,83 0,00 2,83 2,33 1,40
dm-1 0,00 0,00 0,00 4,00 0,00 0,02 8,00 0,01 3,25 0,00 3,25 3,50 1,40
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:18
avg-cpu: %user %nice %system %iowait %steal %idle
11,03 0,00 32,83 0,00 0,00 56,14
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:19
avg-cpu: %user %nice %system %iowait %steal %idle
4,50 0,00 26,25 0,75 0,00 68,50
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:20
avg-cpu: %user %nice %system %iowait %steal %idle
7,96 0,00 32,09 0,00 0,00 59,95
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:21
avg-cpu: %user %nice %system %iowait %steal %idle
11,69 0,00 34,33 0,00 0,00 53,98
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:22
avg-cpu: %user %nice %system %iowait %steal %idle
5,04 0,00 32,24 0,00 0,00 62,72
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:23
avg-cpu: %user %nice %system %iowait %steal %idle
3,78 0,00 26,20 0,00 0,00 70,03
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:24
avg-cpu: %user %nice %system %iowait %steal %idle
9,82 0,00 33,75 0,25 0,00 56,17
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 14,00 0,00 0,05 6,86 0,02 1,21 0,00 1,21 0,71 1,00
dm-0 0,00 0,00 0,00 14,00 0,00 0,05 6,86 0,02 1,14 0,00 1,14 0,71 1,00
dm-1 0,00 0,00 0,00 11,00 0,00 0,04 8,00 0,01 0,91 0,00 0,91 0,91 1,00
dm-2 0,00 0,00 0,00 1,00 0,00 0,00 8,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:25
avg-cpu: %user %nice %system %iowait %steal %idle
6,28 0,00 31,41 0,00 0,00 62,31
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 10,00 0,00 0,04 8,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 10,00 0,00 0,04 8,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 10,00 0,00 0,04 8,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:26
avg-cpu: %user %nice %system %iowait %steal %idle
5,79 0,00 30,48 0,00 0,00 63,73
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:27
avg-cpu: %user %nice %system %iowait %steal %idle
7,58 0,00 28,79 0,00 0,00 63,64
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:28
avg-cpu: %user %nice %system %iowait %steal %idle
6,30 0,00 31,74 0,00 0,00 61,96
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
20/04/2015 11:43:29
avg-cpu: %user %nice %system %iowait %steal %idle
10,78 0,00 32,08 0,00 0,00 57,14
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-1 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-2 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
dm-3 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
There is only one disk. Here is the mapping
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 894,3G 0 disk
├─sda1 8:1 0 2M 0 part
├─sda2 8:2 0 200M 0 part /boot
└─sda3 8:3 0 894,1G 0 part
└─lvm 254:0 0 894,1G 0 crypt
├─datavg-rootlv 254:1 0 25G 0 lvm /
├─datavg-homelv 254:2 0 830G 0 lvm /home
└─datavg-swaplv 254:3 0 2G 0 lvm [SWAP]
Attached is, as required, the result of this script:
#!/bin/sh
export LANG=C
while true; do
date
echo '============================================'
for i in `pgrep btrfs`; do
ps $i
sudo cat /proc/$i/stack 2>/dev/null
done
sleep 1
done
over the same period.
Please telle me if there is something more I can provide.
Regards
Marc
[-- Attachment #2: btrfs_capture.gz --]
[-- Type: application/gzip, Size: 3222 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: snapshot destruction making IO extremely slow
2015-04-20 9:51 ` Marc Cousin
@ 2015-04-23 15:42 ` Marc Cousin
2017-05-24 8:10 ` Marc Cousin
0 siblings, 1 reply; 14+ messages in thread
From: Marc Cousin @ 2015-04-23 15:42 UTC (permalink / raw)
To: dsterba, linux-btrfs
On 20/04/2015 11:51, Marc Cousin wrote:
> On 31/03/2015 19:05, David Sterba wrote:
>> On Mon, Mar 30, 2015 at 05:09:52PM +0200, Marc Cousin wrote:
>>>> So it would be good to sample the active threads and see where it's
>>>> spending the time. It could be the somewhere in the rb-tree representing
>>>> extents, but that's a guess.
>>>>
>>> I just need to be told how to do that :)
>>>
>>> Something like a perf top ?
>>
>> for i in `pgrep btrfs`; do
>> ps $i
>> sudo cat /proc/$i/stack 2>/dev/null
>> done
>>
>> and capture samples every second.
>>
>
> Sorry, it took me a while to reproduce this (I needed to be in front of the machine when it happens :) )
Hi,
Anything more I can provide on this issue ?
Regards
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: snapshot destruction making IO extremely slow
2015-04-23 15:42 ` Marc Cousin
@ 2017-05-24 8:10 ` Marc Cousin
2017-05-24 8:23 ` Marat Khalili
0 siblings, 1 reply; 14+ messages in thread
From: Marc Cousin @ 2017-05-24 8:10 UTC (permalink / raw)
To: dsterba, linux-btrfs
2015-04-23 17:42 GMT+02:00 Marc Cousin <cousinmarc@gmail.com>:
> On 20/04/2015 11:51, Marc Cousin wrote:
>> On 31/03/2015 19:05, David Sterba wrote:
>>> On Mon, Mar 30, 2015 at 05:09:52PM +0200, Marc Cousin wrote:
>>>>> So it would be good to sample the active threads and see where it's
>>>>> spending the time. It could be the somewhere in the rb-tree representing
>>>>> extents, but that's a guess.
>>>>>
>>>> I just need to be told how to do that :)
>>>>
>>>> Something like a perf top ?
>>>
>>> for i in `pgrep btrfs`; do
>>> ps $i
>>> sudo cat /proc/$i/stack 2>/dev/null
>>> done
>>>
>>> and capture samples every second.
>>>
>>
>> Sorry, it took me a while to reproduce this (I needed to be in front of the machine when it happens :) )
>
> Hi,
>
> Anything more I can provide on this issue ?
>
> Regards
>
Hi,
It took me a while (two years :) ), but I think I found what makees
this problem appear, as I just triggered it on a system after this
change. It occurs when enabling quotas on a volume. When there are a
lot of snapshots that are deleted, the system becomes extremely
unresponsive (IO often waiting for 30s on a SSD). When I don't have
quotas, removing snapshots is fast.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: snapshot destruction making IO extremely slow
2017-05-24 8:10 ` Marc Cousin
@ 2017-05-24 8:23 ` Marat Khalili
2017-06-05 8:30 ` Jakob Schürz
0 siblings, 1 reply; 14+ messages in thread
From: Marat Khalili @ 2017-05-24 8:23 UTC (permalink / raw)
To: linux-btrfs
Hello,
> It occurs when enabling quotas on a volume. When there are a
> lot of snapshots that are deleted, the system becomes extremely
> unresponsive (IO often waiting for 30s on a SSD). When I don't have
> quotas, removing snapshots is fast.
Same problem here. It is now common knowledge in the list that qgroups
cause performance problems. I try to avoid deleting many snapshots at
once because of this.
--
With Best Regards,
Marat Khalili
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: snapshot destruction making IO extremely slow
2017-05-24 8:23 ` Marat Khalili
@ 2017-06-05 8:30 ` Jakob Schürz
0 siblings, 0 replies; 14+ messages in thread
From: Jakob Schürz @ 2017-06-05 8:30 UTC (permalink / raw)
To: linux-btrfs
Am 2017-05-24 um 10:23 schrieb Marat Khalili:
> Hello,
>
>> It occurs when enabling quotas on a volume. When there are a
>> lot of snapshots that are deleted, the system becomes extremely
>> unresponsive (IO often waiting for 30s on a SSD). When I don't have
>> quotas, removing snapshots is fast.
> Same problem here. It is now common knowledge in the list that qgroups
> cause performance problems. I try to avoid deleting many snapshots at
> once because of this.
I enabled quota a few weeks ago, then my system gets so unresponsible,
that services stopped working and nothing worked anymore... disabling
qouta was also not able, it endet up in a kernel-panic and frozen system.
Hat to reinstall my system back from the backup...
greetings
Jakob
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2017-06-05 8:30 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-22 8:11 snapshot destruction making IO extremely slow Marc Cousin
2015-03-22 8:23 ` Marc Cousin
2015-03-25 1:19 ` David Sterba
2015-03-25 10:55 ` Marc Cousin
2015-03-25 11:38 ` Rich Freeman
2015-03-30 14:30 ` David Sterba
2015-03-30 14:25 ` David Sterba
2015-03-30 15:09 ` Marc Cousin
2015-03-31 17:05 ` David Sterba
2015-04-20 9:51 ` Marc Cousin
2015-04-23 15:42 ` Marc Cousin
2017-05-24 8:10 ` Marc Cousin
2017-05-24 8:23 ` Marat Khalili
2017-06-05 8:30 ` Jakob Schürz
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.