Description of problem: Very preliminary testing here tells me that using applications that are CPU and thread intensive are making M7 hog all of available memory and swap memory. Applications such as HandBrake and ffmpeg when working one file into another format consume a lot of CPU(s) and while doing so M7 eats through all of the available memory and then max's out swap memory. I am in the early stages of defining this process. The easiest way to see this is to use KSysGuard or Htop. Stopping the application does not free up the memory. Exiting the user space does not free up the memory. The only way to free up memory is to reboot the system. So far I have only experienced this on an Intel platform. More testing is needed.
Please reproduce the issue and then try to run, as root: journalctl -ab > log.txt and attach log.txt to this report If that is impossible, then please reboot after reproducing the issue and run (before running any intensive app.), as root: journalclt -ab -1 > log.txt to fetch the logs from when this happened.
CC: (none) => isobuild, marja11Keywords: (none) => 7beta2, NEEDINFO
(In reply to Marja Van Waes from comment #1) > Please reproduce the issue and then try to run, as root: > journalctl -ab > log.txt Thanks. Will do. Something going on here and I can't quite put my finger on it
I believe HandBrake and ffmpeg are using the same underlying codec libraries. Are you seeing this problem with any other applications?
CC: (none) => mageia
I don't think this is specifically related to HandBrake or ffmpeg. For some reason during initial set up or intensive usage DRAM and SWAP memory spike to full usage and stay there. I mentioned at the QA meeting that during initial M7 set up the HD usage was fully saturated and didn't settle down for many minutes. I believe during this time DRAM and SWAP are saturated. I've never seen this in any previous version of Mageia/Mandrake/Mandriva. David mentioned this was due to Akonadi working ( too hard? ). Maybe working overtime. In the next days I'll try to find a repeatable process to demonstrate this. After awhile it does settle down and go away. But I think comes back. Thanks for your interest and help.
On real hardware, M7, Plasma, 64-bit Hardware: Intel Core i5-4460 Haswell Quad-Core 3.2GHz LGA 115 Gigabyte GA-B85M-D3H LGA 1150 Intel B85 chipset Integrated Graphics Processor - Intel HD Graphics support Audito chipset - Realtek ALC892, 7.1 channels Corsair Vengeance 8GB ( 2 x 4GB ) 240-pin DDR3 SDRAM 1600 System install is just fine. Using the following command in a terminal: [wilcal@localhost ~]$ free -m -s 2 Every 2-seconds I get readout of the status of DRAM and SWAP Reports are as follows: total used free shared buff/cache available Mem: 7796 7260 238 70 297 236 Swap: 4093 1708 2384 total used free shared buff/cache available Mem: 7796 7260 238 70 297 236 Swap: 4093 1708 2384 total used free shared buff/cache available Mem: 7796 7260 233 70 302 235 Swap: 4093 1708 2384 total used free shared buff/cache available Mem: 7796 7260 232 70 303 235 Swap: 4093 1708 2384 Applications and launches are sluggish as both DRAM and SWap are max'd out. Hard drive is running continuously. KSysGuard indicates that both DRAM and Swap are max'd out Run the following commands in an su terminal: sync; echo 1 > /proc/sys/vm/drop_caches sync; echo 2 > /proc/sys/vm/drop_caches sync; echo 3 > /proc/sys/vm/drop_caches Then back to: [wilcal@localhost ~]$ free -m -s 2 results in the following: total used free shared buff/cache available Mem: 7796 338 7153 83 305 7145 Swap: 4093 397 3695 total used free shared buff/cache available Mem: 7796 339 7123 69 333 7157 Swap: 4093 397 3695 total used free shared buff/cache available Mem: 7796 341 6986 69 469 7156 Swap: 4093 397 3695 Applications and launches are peppy and quick. KSysGuard indicates minimal DRAM and Swap memory usage.
Clear PageCache only: sync; echo 1 > /proc/sys/vm/drop_caches Clear dentries and inodes: sync; echo 2 > /proc/sys/vm/drop_caches Clear PageCache, dentries and inodes: sync; echo 3 > /proc/sys/vm/drop_caches
When in the high memory use state, what is the output of ps agux --sort -rss | head -30
Created attachment 10754 [details] Reboot High Memory usage
I'm running out of time here today but will get back at it again tomorrow. Thanks for the help
(In reply to Martin Whitaker from comment #7) > When in the high memory use state, what is the output of > > ps agux --sort -rss | head -30 Result attached.
The firefox usage is going to be controlled by what pages are loaded. On my m7 vb x86_64 guest fully updates, running plasma with firefox loading it's default two tabs ... $ free -m total used free shared buff/cache available Mem: 3944 769 2470 130 704 2829 Swap: 4093 0 4093 Try closing firefox, then the echo to the drop_caches files.
CC: (none) => davidwhodgins
Today I executed a new install to a blank drive using: Mageia-7-beta2-x86_64.iso 2/15/19 Plasma md5sum: 4c9df0b5ce8c58585cc85d74566f0a59 Install was clean, boots to a working desktop. DRAM and Swap are quiet and minimal. As soon as I started to configure the desktop DRAM and Swap were completely filled and the install became mostly unusable. For me this is a serious problem and makes M7 not very usable. Sorry, I gotta push away from my test computer for awhile on this one. Dave, I never opened Firefox on this test. Also the: sync; echo 1 > /proc/sys/vm/drop_caches sync; echo 2 > /proc/sys/vm/drop_caches sync; echo 3 > /proc/sys/vm/drop_caches no longer clears cache. :-(
A revisit to the test platform. As defined in Comment 5 Hardware: Intel Core i5-4460 Haswell Quad-Core 3.2GHz LGA 115 Gigabyte GA-B85M-D3H LGA 1150 Intel B85 chipset Integrated Graphics Processor - Intel HD Graphics support Audito chipset - Realtek ALC892, 7.1 channels Corsair Vengeance 8GB ( 2 x 4GB ) 240-pin DDR3 SDRAM 1600 The platform features a removable replaceable HD system. Turn off the computer, unlock HD tray with Drive A and remove it Slide in another HD tray lets call it Drive B. Lock drive in place. Power up test platform with Drive B run test I have about a dozen drives in trays some of the SSD's One contains an M6.1 up-to-date Plasma x86_64 install and has been working very nicely thank you with no problems at all. But it is running a Legacy boot where as all of my testing with M7 is UEFI. So I have to change the BIOS setting between tests. I don't think that would effect this testing. I have a UEFI M6.1 x86_64 Plasma install on one of my HD trays and it works just fine on this platform.
Sorry to belabor this but since an M7 update a couple days ago I am starting to get sporadic error messages on screen indicating that the "filesystem is not responding". Of course DRAM and Swap are maxed out and the HD is running at 1000mph.
Install htop. Run it as root with "htop -d 100" (the -d 100 sets it's update freq to 10 seconds, so there's time to copy/paste). Press the letter K (note uppercase) to toggle showing kernel threads. Press f6 and select M_RESIDENT to sort by the RES field. Wait for the next update, then copy/paste the output. I find this easier than getting ps to show which process is grabbing all of the ram.
(In reply to Dave Hodgins from comment #15) > Install htop. Run it as root with "htop -d 100" (the -d 100 sets it's update > freq to 10 seconds, so there's time to copy/paste). > > Press the letter K (note uppercase) to toggle showing kernel threads. Press > f6 > and select M_RESIDENT to sort by the RES field. Wait for the next update, > then > copy/paste the output. > > I find this easier than getting ps to show which process is grabbing all of > the ram. Thanks Dave, working on it today.
Created attachment 10757 [details] htop_before_1
Created attachment 10758 [details] htop_before_2
Created attachment 10759 [details] htop_before_3
Created attachment 10760 [details] htop_before_4
Created attachment 10761 [details] htop_before_5
Created attachment 10762 [details] journalctl_before_1
Created attachment 10763 [details] sysmon_before_1
Created attachment 10764 [details] htop_after_1
Created attachment 10765 [details] htop_after_2
Created attachment 10766 [details] htop_after_3
Created attachment 10767 [details] htop_after_4
Created attachment 10768 [details] journalctl_after_1
Created attachment 10769 [details] sysmon_after_1
I started all over again with a blank drive and did a netinstall with a repo that was up-to-date. The install went smoothly and the DRAM and Swap were normal and low. I then using the tips from all above I captured as much of Htop, ps, journalctl and sysmon screenshots that made sense. Those shots are attached. I then set up my Plasma desktop my normal way and did a ctrl-alt-del out of the user and then logged back in. DRAM and Swap were maxed out and the usability of the system had degraded. I was able to capture the same set of screenshots and logs and they are attached to this bug. The login was just after 13:00 and you can see that in the after journalctl log. Hopefully there's something here that will tell us what is going on. Feel free to ask for any other screenshots or lots and I'll do my best to capture them.
Sounds like it's one of the things you change when configuring your desktop that's triggering this bug. If you create a new user, then do your configuration in small steps, logging out and back in again at each step, that ought to pin down which change is responsible.
Created attachment 10770 [details] journalctl after reboot I rebooted the system then captured the journalctl log from the time that the reboot started ( 11:51 ). When the system got back to the working desktop, took some time, DRAM and Swap were max'd out.
Well how bout that. Good tip Martin. I created a 2nd user: test1 Now there are two users on the system wilcal & test1 Without changing anything in test1 its usage of DRAM and Swap are normal. wilcal remains max'd out when I log back into that. And I can go back and froth between the two of them and they remain the same. Wilcal is always maxed out and test1 is normal.
Done for today. I'll continue on tomorrow and see if I can narrow it down.
(In reply to William Kenney from comment #30) > I started all over again with a blank drive and did a netinstall with > a repo that was up-to-date. The install went smoothly and the DRAM > and Swap were normal and low. I then using the tips from all above > I captured as much of Htop, ps, journalctl and sysmon screenshots that > made sense. Those shots are attached. > > I then set up my Plasma desktop my normal way and did a > > ctrl-alt-del Why? That can kill processes leaving config files partially written. Use logout, then login, not ctrl+alt+del.
(In reply to Dave Hodgins from comment #35) > Why? That can kill processes leaving config files partially written. > > Use logout, then login, not ctrl+alt+del. Yup, it's making me crazy. Back at it for awhile tomorrow.
Wow, what a find Menu bar -> System Settings -> Workspace Theme -> there are four selections Breeze, Breeze Dark, Oxygen and Mageia Select Breeze, Breeze Dark or Mageia and I'm fine. Select Oxygen and that's fine till you get out of the user space. When you come back in DRAM and Swap are max'd out. When your max'd out if you select and apply another Workspace Theme DRAM and Swap almost immediately return to normal. I can repeat this at will. So I'm gonna rest for a day and try it again tomorrow to make sure this is what's going on. I'm pretty sure the Oxygen Theme has been the source of this problem and many other wonky Plasma things I've seen but can't put my finger on. I bet the the Intel platform and QT thingys are part of this. Also the "filesystem is not responding" errors are gone. Thanks again for the tips folks.
Using the Breeze theme here, in general and for the desktop theme, but using Oxygen White for the cursor theme, and Oxygen for the icon theme. I'm not seeing the problem, so it would seem that the Oxygen icon and cursor themes are cleared.
CC: (none) => andrewsfarm
I believe this is platform specific as it does not show up in a Vbox client or one of my other Intel ( nvidia ) platforms. But, the platform it does show up on is an extremely common generic Intel platform chosen just for testing purposes. Gotta talk about this at today's QA meeting.
(In reply to William Kenney from comment #37) > Wow, what a find > > Menu bar -> System Settings -> Workspace Theme -> there are four selections > Breeze, Breeze Dark, Oxygen and Mageia > Select Breeze, Breeze Dark or Mageia and I'm fine. > Select Oxygen and that's fine till you get out of the > user space. When you come back in DRAM and Swap > are max'd out. When your max'd out if you select > and apply another Workspace Theme DRAM and Swap almost > immediately return to normal. I can repeat this at will. > So assigning to the KDE maintainers.
Summary: M7 is hogging all of available memory and swap and won't let it go => M7 is hogging all of available memory and swap when using breeze theme and won't let it goAssignee: bugsquad => kde
Keywords: NEEDINFO => (none)
I have placed an entry into: https://wiki.mageia.org/en/Mageia_7_Errata Describing this situation and how to avoid it.
(In reply to William Kenney from comment #41) > I have placed an entry into: > https://wiki.mageia.org/en/Mageia_7_Errata > Describing this situation and how to avoid it. Entry reworded.
Summary: M7 is hogging all of available memory and swap when using breeze theme and won't let it go => M7 Plasma memory leak when using oxygen theme with some intel video cards leading to oom.
Lets change this to "Resolved" for now.
Status: NEW => RESOLVEDResolution: (none) => FIXED