From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id DAEE51382C5 for ; Wed, 20 May 2020 13:17:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C50EFE096B; Wed, 20 May 2020 13:17:37 +0000 (UTC) Received: from gw2.antarean.org (gw2.antarean.org [141.105.125.208]) by pigeon.gentoo.org (Postfix) with ESMTP id 67E43E0924 for ; Wed, 20 May 2020 13:17:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gw2.antarean.org (Postfix) with ESMTP id 49Rtb54sSyz8w3C for ; Wed, 20 May 2020 15:17:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at antarean.org Received: from gw2.antarean.org ([127.0.0.1]) by localhost (gw2.antarean.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUFyrWojGxtR for ; Wed, 20 May 2020 15:17:37 +0200 (CEST) Received: from mailstore1.antarean.org (localhost [127.0.0.1]) by gw2.antarean.org (Postfix) with ESMTP id 49Rtb51jjNz8vxV for ; Wed, 20 May 2020 15:17:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mailstore1.antarean.org (Postfix) with ESMTP id 49Rtb35p0sz17 for ; Wed, 20 May 2020 15:17:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at antarean.org Received: from mailstore1.antarean.org ([127.0.0.1]) by localhost (mailstore1.antarean.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_eGskAj_4oK for ; Wed, 20 May 2020 15:17:35 +0200 (CEST) Received: from eve.localnet (eve.adm.antarean.org [10.55.16.44]) by mailstore1.antarean.org (Postfix) with ESMTP id 49Rtb335L6z15 for ; Wed, 20 May 2020 15:17:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=antarean.org; s=default; t=1589980655; bh=6btfFMkmbZjNQ6Ps031HXubrXq99dHycvKGSUmpplow=; h=From:To:Subject:Date:In-Reply-To:References; b=YAOAnB/UZI+Rh/A5wRYLwyDXWM4HhCvqNs6IRL1t9A8xjkpZkdUpztHJonIoCWsAx fE6ZY6JobgbXpWwKLiYQAbIUZKWdMofLfvUNT9eEPKmBC8Sd29rXUziTdfbSKBpbvn n1s7VWipd4SI+bEdyFoUesyTRDOdCHVvKGoV4Sss= From: "J. Roeleveld" To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] sddm-helper and high memory usage Date: Wed, 20 May 2020 15:17:35 +0200 Message-ID: <21809910.6Emhk5qWAg@eve> Organization: Antarean In-Reply-To: References: <706b68ae-a6d7-db97-33e2-98838682befc@gmail.com> <7759979.T7Z3S40VBb@dell_xps> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Archives-Salt: e62eb429-b539-4029-b3b0-7c280e05ec20 X-Archives-Hash: 980bab41452342980ae37e43639849df On Sunday, May 17, 2020 12:09:19 AM CEST Dale wrote: > Michael wrote: > > On Saturday, 16 May 2020 13:32:32 BST Dale wrote: > >> Dale wrote: > >>> I guess the bug was caught and fixed. Thanks to all that read and > >>> Michael for trying to help. > >>> > >>> Dale > >>> > >>> :-) :-) > >> > >> I have some more info and some doesn't make much sense. I thought this > >> might be fixed but guess not. While it is somewhat slower to take up a > >> lot of memory after a recent plasma update, it does still get there. It > >> takes a day or so now where before it was just a few hours. Logging out > >> and back in does reset it to normal tho. > >> > >> One thing that seems to stand out, Firefox and one profile in > >> particular. I have two profiles that I use a lot nowadays. One is for > >> ebay, Amazon, tracking shipments etc etc. The other is where I do > >> youtube and other video type sites. It has a video download helper > >> add-on installed but the rest is mostly the same. When I have the first > >> profile open, it is slow to consume memory. When I open the one I use > >> for videos, it starts building up faster. While I can logout and back > >> in daily, it still gets to around 5% or so. I usually start planning to > >> logout and back in when it hits 4% or so. It's at 5 by the time I get > >> everything to where I can. Thing is, closing Firefox doesn't seem to > >> have any effect on it. It slows down some but doesn't get back to > >> normal memory usage. I can't quite figure out how Firefox can have a > >> effect on it tho. I realize it is running within the GUI and all but > >> still, it doesn't make much sense. > >> > >> I do a emerge -e system and world the other day in my chroot. Once > >> done, I did a complete re-emerge on my running system. All was done > >> with the same gcc, 9.3. I'm not sure it did any good but at least it > >> rules out some sort of mismatch with different packages running with > >> different gcc versions. It also rules out and sort of broken linkages > >> and other mismatches as well. I've also updated kernels and video > >> drivers with no change. I also disabled my background slideshow to see > >> if it was causing this, no change. When I was doing my emerge system > >> and world, I had Firefox and at times Seamonkey closed and it stayed > >> within reason at least. It would get up to around 2% but seemed to stay > >> there. I'm not sure what to look for or even for sure what is exactly > >> the trigger for this problem. It seems Firefox affects it but not sure > >> why that is exactly. > >> > >> If anyone has ideas, I'm open to them. I can't think of anything else > >> to try at the moment. > >> > >> Dale > >> > >> :-) :-) > > > > Just an idea: > > > > Log out/in, check memory usage is normal. If not log out, restart /etc/ > > init.d/xdm and login again. Start FF without any addons. Use a new > > profile if necessary. Check memory usage. If after a while under normal > > use you still have reasonable levels of memory usage, then you can start > > adding one add-on at a time and see where that gets you. > > > > You may also want to give youtube-dl a spin. I know, it's not a FF-GUI > > video download tool, but it works without getting in the way or eating up > > RAM unnecessarily. > > I have a test Firefox profile that has very few if any add-ons > installed. I sometimes use it to test problems. Anyway, I suspect the > video download add-on myself. Ever since the big change with add-ons > and multi-process support, the video add-on has had issues. I've had > crashes, excessive memory usage by Firefox itself etc etc. For the most > part, the video add-on works but it is not like it was with the older > versions of Firefox. While sddm-helper does use more memory even > without Firefox, it just gets much worse with it. > > I have and use youtube-dl. I use it for youtube and a couple other > sites that it works with. Thing is, some sites don't work with > youtube-dl. It tries but it reports some sort of error, error varies > from site to site, and then stops. I wish it would work because it is > drop dead easy to use once you get it configured. I've got mine set up > pretty well. It will try to get 1280x720 but no larger if available. > For what I do 99% of the time, that works very well. File size is > manageable but has a good resolution. Of course some older videos are > 480 or something but still, I like the tool. > > I see another KDE upgrade being released. It is a plasma update so > hopefully it will hit the tree by Sunday. Maybe it will have a fix or > something. In the meantime, I'll keep observing and trying things to > see if I can figure out what is going on. It's confusing tho. > > Thanks. Will try to the test profile shortly. I'm at 6% or so right > now. Time for a reset anyway. Dale, The few times I have issues with "sddm-helper" is when I resume my laptop from hibernate. (Not always, but occasionally) The issue I see is 100% CPU-usage and a black X-display. I can switch to console (CTRL+ALT+F1), login as root and kill the offending sddm-helper. It gets restarted automatically and I see no issue. Do you tend to lock your screen a lot? As it might be related to screensavers. (I have a simple static lock-screen, nothing remotely fancy) Also, you can try killing "kill -9 sddm-helper" when it goes up and see what happens next. Is there anything in the sddm-logs? Mine, for some reason, writes to /var/log/sddm.log Do you have anything special in your Xsession files and/or profiles (incl. bash_profile and bashrc) that is non-default? Which login-theme do you use? -- Joost