[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Baloo] [Bug 333655] Baloo indexing I/O introduces serious noticable delays
From:       Martin Steigerwald <Martin () Lichtvoll ! de>
Date:       2014-05-15 11:14:31
Message-ID: bug-333655-17878-k0S7CSzkTa () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=333655

--- Comment #44 from Martin Steigerwald <Martin@Lichtvoll.de> ---
(In reply to comment #43)
> Created attachment 86645 [details]
> atop raw log
> 
> I have SSHD disk - 1 TB classical HDD with 7200 RPM speeded by 8 GB flash
> cache.
> $ balooctl start
> Today morning I upgraded to 4.13.1 from openSUSE pacakges, I like balooctl
> function, but the situation remains as tragic as on beginning...
> $ atop -w atop-baloo-file-stresser.raw 10

Was that during running my test case shell script I don ´t see a bash process
active in CPU list or just during *using* the machine?

For some reason atop missed per process disk activity logs and shows the
following error on pressing "d" with it:

No disk-activity figures available; request ignored!

Maybe your kernel misses a configuration option for it. Can you try with
standard OpenSUSE kernel – in case you use a self-compiled one.

General statistics clearly show that disk is oversaturated for extended periods
of time. And extreme example:

LVM |      cr_home | busy    100% | read       0 | write      1 | KiB/r      0
|              | KiB/w     48 | MBr/s   0.00 | MBw/s   0.00 | avq  3358.85 |
avio 10000 ms
DSK |          sda | busy    100% | read       0 | write   1140 | KiB/r      0
|              | KiB/w     11 | MBr/s   0.00 | MBw/s   1.29 | avq   143.21 |
avio 8.77 ms |

1140 write accesses with about 1,29 MB/s for writing. That must be random I/O
considering the disk utilization and insanely high LVM volume latency.

Also atopsar -d shows the disk being busy.

$ atopsar -r atop-baloo-file-stresser.raw -d

veles  3.11.10-7-desktop  #1 SMP PREEMPT Mon Feb 3 09:41:24 UTC 2014 (750023e) 
x86_64  2014/05/15

-------------------------- analysis date: 2014/05/15 --------------------------

11:54:03  disk           busy read/s KB/read  writ/s KB/writ avque avserv _dsk_ 
11:54:13  sdb              0%    0.0     0.0     0.1     4.0   1.0   2.00 ms
          sda            100%    0.0     0.0   116.3    10.9 143.4   8.64 ms
11:54:23  sdb              0%    0.0     0.0     0.6     3.3   1.7   1.50 ms
          sda            100%    0.0     0.0   117.8    11.0 143.0   8.52 ms
11:54:33  sda            100%    0.0     0.0   120.0    10.8 143.9   8.36 ms
11:54:43  sda            100%    0.0     0.0   114.4    11.6 143.2   8.77 ms
11:55:08  sdb              0%    0.0     0.0     0.2     3.0   1.3   1.50 ms
[… it goes on like this …]

Well… it may be nice to see disk I/O process statistic here. But I think the
case has been made.

Baloo doesn ´t yet work well with frequently appended to files. I may come up
with a fio job to simulate random I/O inside a file.

As a temporary work-around I suggest: If you know about any applications that
write to files inside home directory – not hidden files or directories – try to
exclude these pathes from indexing.

-- 
You are receiving this mail because:
You are watching all bug changes.=
[prev in list] [next in list] [prev in thread] [next in thread]