From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-user+bounces-172627-garchives=archives.gentoo.org@lists.gentoo.org> 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 70F2B13832E for <garchives@archives.gentoo.org>; Tue, 9 Aug 2016 17:15:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6F897E0BCC; Tue, 9 Aug 2016 17:15:41 +0000 (UTC) Received: from omr-a001e.mx.aol.com (omr-a001e.mx.aol.com [204.29.186.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id F2AC7E0B2C for <gentoo-user@lists.gentoo.org>; Tue, 9 Aug 2016 17:15:39 +0000 (UTC) Received: from mtaout-aan01.mx.aol.com (mtaout-aan01.mx.aol.com [172.27.19.77]) by omr-a001e.mx.aol.com (Outbound Mail Relay) with ESMTP id D30063800083 for <gentoo-user@lists.gentoo.org>; Tue, 9 Aug 2016 13:15:38 -0400 (EDT) Received: from [192.168.1.52] (0x5b3139322e3136382e312e35325d [71.122.242.106]) by mtaout-aan01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPA id 77A5F38000120; Tue, 9 Aug 2016 13:15:37 -0400 (EDT) Subject: Re: [gentoo-user] kde-apps/kde-l10n-16.04.3:5/5::gentoo conflicting with kde-apps/kdepim-l10n-15.12.3:5/5::gentoo To: gentoo-user@lists.gentoo.org References: <4722389.KL1Hxsu66Q@serenity> <8225169.MTUamjykAl@serenity> <39dd6e07-2209-5180-4f55-3fd0d1d208f1@verizon.net> <1712940.8Y8JX9hDih@serenity> From: james <garftd@verizon.net> Message-ID: <c80d2a84-259a-c936-9fb1-6122f4c06e0e@verizon.net> Date: Tue, 9 Aug 2016 13:23:57 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 Precedence: bulk List-Post: <mailto:gentoo-user@lists.gentoo.org> List-Help: <mailto:gentoo-user+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-user.gentoo.org> X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <1712940.8Y8JX9hDih@serenity> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit x-aol-global-disposition: G x-aol-sid: 3039ac1b134d57aa0fb914f1 X-AOL-IP: 71.122.242.106 X-Archives-Salt: 7ed3f9ca-7f02-4c15-b76a-85270431ddf2 X-Archives-Hash: 5455afbc56e9b4b880be6548bacadc86 On 08/09/2016 09:17 AM, Michael Mol wrote: > On Tuesday, August 09, 2016 09:13:31 AM james wrote: > >> On 08/09/2016 07:42 AM, Michael Mol wrote: > >> > On Monday, August 08, 2016 10:45:09 PM Alan McKinnon wrote: > >> >> On 08/08/2016 19:20, Michael Mol wrote: > >> >>> On Monday, August 08, 2016 06:52:15 PM Alan McKinnon wrote: > >> >>>> On 08/08/2016 17:02, Michael Mol wrote: > >> >>> snip <<< > >> >> > >> >> KMail is the lost child of KDE for many months now, I reckon this > >> >> situation is just going to get worse and worse. I know for myself my > >> >> mail problems ceased the day I dumped KMail4 for claws and/or > thunderbird > >> > > >> > That's really, really sad. > >> > > >> > I used Thunderbird for years, but I eventually had to stop when it > would, > >> > averaging once a month (though sometimes not for a couple months, > >> > sometimes a couple times a week) explode in memory consumption and drive > >> > the entire system unresponsively into swap. > >> > > >> > I've tried claws from time to time due to other annoyances with > >> > Thunderbird, but I kept switching back. Not because I liked Tbird, but > >> > (IIRC) because of stability issues I had with claws. > >> > > >> > Even with the bugs it has, Kontact and Akonadi has been the most > reliable > >> > mail client I've used in the last year. When it gives me problems, I > know > >> > why, and I can address it. (Running a heavily tuned MySQLd instance > >> > behind Akonadi, for example...) > >> > > >> > I wish someone would pay me to fix this stuff; I'd be able to spend the > >> > time on it. > >> > >> Perhaps an experiment. Locate some folks that know about how to promote > >> 'crowd funding'. The propose a project like this, targeted at business > >> and user, to all pitch in. In fact, quite a few beloved open source > >> projects could benefit, if the idea of crowd funding took hold > >> on open source soft. Perhaps one of the foundations deeply involved in > >> the open source movement would get behind the idea? > >> > >> KDE is very popular, so the concept or something similar might just have > >> legs, even if it only funds a series of grad-students or young > >> programmers to maintain good FOSS projects? > > > > A wonderful thought. I rather expect KDE is already doing this, but if > not, they ought to. (I'm sure someone who commits code to KDE reads this > list...) > > > > Certainly wouldn't cover someone like me who has a family to support, > but still. > > > >> > >> AS a side note, I put 32G of ram on my system and still at times it is > >> laggy with little processor load and htop shows little <30% ram usage. > >> What tools do you use to track down mem. management issues? > > > > I use Zabbix extensively at work, and have the Zabbix agent on my > workstation reporting back various supported metrics. There's a great > deal you can use (and--my favorite--abuse) Zabbix for, especially once > you understand how it thinks. Congradualtions! Of the net-analyzer crowd, you've manage to find one I have not spent time with........ > > > >> > >> Any specific kernel tweaks? > > > > Most of my tweaks for KDE revolved around tuning mysqld itself. But for > sysctls improving workstation responsiveness as it relates to memory > interactions with I/O, these are my go-tos: > > > > vm.dirty_background_bytes = 1048576 > vm.dirty_bytes = 10485760 > vm.swappiness = 0 Mine are:: cat dirty_bytes 0 cat dirty_background_bytes 0 cat swappiness 60 > > vm.dirty_background_bytes ensures that any data (i.e. from mmap or > fwrite, not from swapping) waiting to be written to disk *starts* > getting written to disk once you've got at least the configured amount > (1MB) of data waiting. (If you've got a disk controller with > battery-backed or flash-backed write cache, you might consider > increasing this to some significant fraction of your write cache. I.e. > if you've got a 1GB FBWC with 768MB of that dedicated to write cache, > you might set this to 512MB or so. Depending on your workload. I/O > tuning is for those of us who enjoy the dark arts.) > > > > vm.dirty_bytes says that once you've got the configured amount (10MB) of > data waiting to be disk, then no more asynchronous I/O is permitted > until you have no more data waiting; all outstanding writes must be > finished first. (My rule of thumb is to have this between 2-10 times the > value of vm.dirty_background_bytes. Though I'm really trying to avoid it > being high enough that it could take more than 50ms to transfer to disk; > that way, any stalls that do happen are almost imperceptible.) > > > > You want vm.dirty_background_bytes to be high enough that your hardware > doesn't spend its time powered on if it doesn't have to be, and so that > your hardware can transfer data in large, efficient, streamable chunks. > > > > You want vm.dirty_bytes enough higher than your first number so that > your hardware has enough time to spin up and transfer data before you > put the hammer down and say, "all right, nobody else gets to queue > writes until all the waiting data has reached disk." > > > > You want vm.dirty_bytes *low* enough that when you *do* have to put that > hammer down, it doesn't interfere with your perceptions of a responsive > system. (And in a server context, you want it low enough that things > can't time out--or be pushed into timing out--waiting for it. Call your > user attention a matter of timing out expecting things to respond to > you, and the same principle applies...) > > > > Now, vm.swappiness? That's a weighting factor for how quickly the kernel > should try moving memory to swap to be able to speedily respond to new > allocations. Me, I prefer the kernel to not preemptively move > lesser-used data to swap, because that's going to be a few hundred > megabytes worth of data all associated with one application, and it'll > be a real drag when I switch back to the application I haven't used for > half an hour. So I set vm.swappiness to 0, to tell the kernel to only > move data to swap if it has no other alternative while trying to satisfy > a new memory allocation request. OK, OK, OK. I need to read a bit about these. Any references or docs or is the result of parsing out what is the least painful for a workstation? I do not run any heavy databases on my workstation; they are only there to hack on them. I test db centric stuff on domain servers, sometimes with limited resources. I run lxde and I'm moving to lxqt for workstations and humanoid (terminal) IO. Do you set these differently for servers? Nodes in a cluster? I use OpenRC, just so you know. I also have a motherboard with IOMMU that is currently has questionable settings in the kernel config file. I cannot find consensus if/how IOMMU that affects IO with the Sata HD devices versus mm mapped peripherals.... in the context of 4.x kernel options. I'm trying very hard here to avoid a deep dive on these issues, so trendy strategies are most welcome, as workstation and cluster node optimizations are all I'm really working on atm. THANKS (as always)! James