[opensuse-support] Leap 15 performance issue
Hi again, I still face an issue on the Desktop I have converted from Leap 42.3 to 15. Desktop (KDE) is partly unresponsive for 2 Minutes, full load on both CPU cores, most likely due to disk-activities (baloo....). Not even CRTL-ESC is working during this time. Is there any tweak to make it more responsive? - Different kind of Kernel or Kernel scheduler? Currently running the default kernel. - any idea to reduce the priority of baloo in order to reduce the disk activities? Dual Core Intel G4400@3.3 GHz, 8G RAM, MSI H110M PRO-D Motherboard Any additional information needed? Thanks Axel -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
* Axel Braun <docb@opensuse.org> [06-22-18 07:53]:
have you tried top or htop to see what process(s) is stalling your system rather than "most likely" as you leave us shooting in the dark. if it is akonadi* related, you can issue: akonadictl stop use your computer and then akonadictl start to allow the database to complete its rebuilding (istr that you removed it). you mention baloo above, the same actions are available for baloo, balooctl stop ... still w/o knowing what is stalling your system, it is just a guess. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Am Freitag, 22. Juni 2018, 14:25:52 CEST schrieb Patrick Shanahan:
you are right, top gives a better overview than KDE process monitor At the top of the list, esp, when there is no response from the desktop, is plasmashell and kwin_X11. Graphics is an Intel i915 - is this maybe related? southpole: # lspci -s 00:02.0 -v 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 510 (rev 06) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7996 Flags: bus master, fast devsel, latency 0, IRQ 122 Memory at de000000 (64-bit, non-prefetchable) [size=16M] Memory at c0000000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [40] Vendor Specific Information: Len=0c <?> Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [100] Process Address Space ID (PASID) Capabilities: [200] Address Translation Service (ATS) Capabilities: [300] Page Request Interface (PRI) Kernel driver in use: i915 Kernel modules: i915 Best, Axel -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
* Axel Braun <DocB@opensuse.org> [06-22-18 10:45]:
so it is probably not akonadi or baloo which is causing your system to crawl, but plasmascreen. not a solution but will probably releave your system, in a terminal window: kquitapp5 plasmashell && sleep 2 && kstart plasmashell & disown && sleep 10 && exit that is one line. I would guess you are having problems with the drivers for your video card. I cannot help you there. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Am Freitag, 22. Juni 2018, 16:58:32 CEST schrieb Patrick Shanahan: [...]
with the hint from Carlos to use iotop: baloo_file_extractor works hard on the disk (and, as Gertjan mentioned, the old index DB was already removed), but the real problem comes from plasmashell
Since I had run this command it seems that plasmashell is more responsive. No more breals for minutes....
I would guess you are having problems with the drivers for your video card. I cannot help you there.
Video driver is the i915 Intel driver. No special boot parameter. Can this 'communication' between video driver and plasmashell be monitored somehow? Cheers Axel -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
* Axel Braun <DocB@opensuse.org> [06-23-18 08:21]:
so perhaps you need to examine baloo's configuration or wait for baloo to finish rebuilding it's indexes you do have the option to suspend the indexing to rule out, or not, baloo as the problem.
does "minutes..." mean you have relief or only momentary and then the same lack of system response? if this provides relief, it would seem that baloo was not really the problem but the video drivers.
have we determined that video is the problem or are we chasing a path which will not provide a solution? understanding that *you* want to solve your problems and gain knowledge while doing so, your hesitation to provide requested details is not making others attempts to provide you solution any easier. please be more forthcoming. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Am Samstag, 23. Juni 2018, 14:35:39 CEST schrieb Patrick Shanahan:
As written, ballo seems not to be the problem in that case.
After I played some more with the command, it is _not_ giving durable relief. It still needs a minute or so to open a new window, like dolphin. Inside e.g. the terminal, output of top refreshes regulary
Hm, I though I have phrased that above, sorry itf that did not come through properly. So yes, it looks it is video/plasmashell. Even the text while typing is partly stalled for some seconds, until it arrives Thanks Axeö -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
* Axel Braun <DocB@opensuse.org> [06-23-18 12:01]: [...]
and what does top show. what is consuming your cpu? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Am Samstag, 23. Juni 2018, 18:11:00 CEST schrieb Patrick Shanahan:
As written before, plasmashell, kwin_X11 and X Additionally I have posted the output of iotop, maybe that helps as well: http://paste.opensuse.org/48571917 Each Thread shows 0 Disk write, but the summary line on top says 2.55 M/s. Thats strange, IMHO. Additionally, how to interpret IO? Does it mean that the CPU is 99.99% of the time dedicated to that process busy waiting, not computing? Cheers Axel -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
* Axel Braun <DocB@opensuse.org> [06-23-18 12:52]:
man iotop or man iotop Usage: /usr/sbin/iotop [OPTIONS] DISK READ and DISK WRITE are the block I/O bandwidth used during the sampling period. SWAPIN and IO are the percentages of time the thread spent respectively while swapping in and waiting on I/O more generally. PRIO is the I/O priority at which the thread is running (set using the ionice command). Controls: left and right arrows to change the sorting column, r to invert the sorting order, o to toggle the --only option, p to toggle the --processes option, a to toggle the --accumulated option, i to change I/O priority, q to quit, any other key to force a refresh. Options: --version show program's version number and exit -h, --help show this help message and exit -o, --only only show processes or threads actually doing I/O -b, --batch non-interactive mode -n NUM, --iter=NUM number of iterations before ending [infinite] -d SEC, --delay=SEC delay between iterations [1 second] -p PID, --pid=PID processes/threads to monitor [all] -u USER, --user=USER users to monitor [all] -P, --processes only show processes, not all threads -a, --accumulated show accumulated I/O instead of bandwidth -k, --kilobytes use kilobytes instead of a human friendly unit -t, --time add a timestamp on each line (implies --batch) -q, --quiet suppress some lines of header (implies --batch) -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 2018-06-23 18:51, Axel Braun wrote:
In that photo, the disk is writing 2.5M/s, which is not much if they are contiguous writes, but much more relevant if they are random writes. We do not know, however, which process is writing. What is relevant, however, is the IO column: 3 processes have the CPU waiting for I/O 99.99% of the time allocated to them, instead of actually computing. Even the iotop process itself is waiting. Plasmashell, however, is only 65% waiting. Why did you add the "-P"? Are there messages related to errors or disk problems on the logs? -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Hi, When I do fault isolation on my systems (usually Linux routers at work or my own DAW (digital audio workstation)) I usually start with this, as root: watch cat /proc/interrupts It'll give you a listing of updated interrupts every other second. Use -n for other intervals. Locate the one that gives you most interrupts and go from there. As an example my DAW had serious overload on one USB-port together with other interrupts on CPU0. I moved my mixer to another port (ending up on CPU3) and all's well after that. If you need to you can move interrupts to another cpu-core with help of smp_affinity. Cheers, -- /bengan -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Den 2018-06-25 kl. 11:56, skrev Carlos E. R.:
Interrupts are tied to a certain core? I thought they were dynamically assigned to a non busy core.
Yes. Your right. I think I was a bit unclear. What I meant was that if you have the need to redirect one interrupt source to a certain core it can be done via smp-affinity. Normally you shouldn't need that but there are cases where it is of great importance. The two cases I referred to (router and DAW) is such cases. They are real time cases. Under heavy load in a recording (audio) situation you do not want disturbance in any way and as low latency as possible. In the case of router it's crucial if you have a production system and you don't have an out-of-band solution to access the router and the traffic is very high. We did this in three different projects about 11-13 years ago where we showed that 10Gbit/s forwarding in a Linux router is possible. There we redirected the ssh-port to CPU0 and the rest of the packets were handled by core CPU1-CPU7 so that the control plane were separated from data plane. But to get back to the "watch cat /proc/interrupts". It's to see were the interrupts comes from. Cheers, -- /bengan -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 2018-06-25 13:17, Bengt Gördén wrote:
I see :-)
But to get back to the "watch cat /proc/interrupts". It's to see were the interrupts comes from.
Yes, it is a good idea. Long ago, my computer was running very slow one day (perhaps SuSE 7.x). The process "init" was very, very busy. Single core CPU. I don't remember how I found out, but the modem was sending a flurry of interrupts over the serial port. I power cycled the modem and problem solved. :-) It never happened again. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
Am Montag, 25. Juni 2018, 13:17:17 CEST schrieb Bengt Gördén:
Here is a shot of the interrupts: http://paste.opensuse.org/88070748 When the system is stuck, the interrupts on ahci and i915 count up, both on different cores. I guess thats the issue? Cheers Axel -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 2018-06-22 16:44, Axel Braun wrote:
Am Freitag, 22. Juni 2018, 14:25:52 CEST schrieb Patrick Shanahan:
* Axel Braun <> [06-22-18 07:53]:
You could also try to run in another terminal "iotop -o -d 3.3333" which will tell you if there are processes making the disk very busy. Sometimes the CPU doesn't appear loaded, but still, the system is unresponsive. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
participants (6)
-
Axel Braun -
Axel Braun
-
Bengt Gördén -
Carlos E. R. -
Knurpht＠openSUSE -
Patrick Shanahan