From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bob Proulx Newsgroups: gmane.emacs.devel Subject: Re: Move to git is imminent - awaiting Stefan's approval Date: Sun, 12 Jan 2014 14:29:31 -0700 Message-ID: <20140112212931.GB23558@hysteria.proulx.com> References: <83d2k3sqqz.fsf@gnu.org> <52CC2D45.1000908@alice.it> <83a9f7sosr.fsf@gnu.org> <52CC5ED3.2000903@alice.it> <83d2k2fkg1.fsf@gnu.org> <87txdenwz3.fsf@igel.home> <20140112062722.GA15615@hysteria.proulx.com> <87k3e5xzl5.fsf@Rainer.invalid> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1389562184 25079 80.91.229.3 (12 Jan 2014 21:29:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Jan 2014 21:29:44 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 12 22:29:50 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W2SbO-0008AF-EC for ged-emacs-devel@m.gmane.org; Sun, 12 Jan 2014 22:29:50 +0100 Original-Received: from localhost ([::1]:39527 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2SbN-0004PS-Vh for ged-emacs-devel@m.gmane.org; Sun, 12 Jan 2014 16:29:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2SbE-0004PA-Vv for emacs-devel@gnu.org; Sun, 12 Jan 2014 16:29:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2Sb7-0004es-Al for emacs-devel@gnu.org; Sun, 12 Jan 2014 16:29:40 -0500 Original-Received: from joseki.proulx.com ([216.17.153.58]:57755) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2Sb7-0004e1-2o for emacs-devel@gnu.org; Sun, 12 Jan 2014 16:29:33 -0500 Original-Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 216BE21227 for ; Sun, 12 Jan 2014 14:29:32 -0700 (MST) Original-Received: by hysteria.proulx.com (Postfix, from userid 1000) id 089B72DCD2; Sun, 12 Jan 2014 14:29:31 -0700 (MST) Mail-Followup-To: emacs-devel@gnu.org Content-Disposition: inline In-Reply-To: <87k3e5xzl5.fsf@Rainer.invalid> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 216.17.153.58 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:168250 Archived-At: Achim Gratz wrote: > Bob Proulx writes: > >(Wondering if we can periodically run 'git gc --agressive' on the > >larger git repositories at a niced background task priority but not too > >often and still achieve a good benefit for the time between agressive > >repacks.) > > Just a manual "git gc --aggressive" once in a while should be enough. > If you are going to do it as a cron-job, I'm not sure if it's a good > idea to nice it. Due to the performance issues some of the Savannah admins have started nicing background tasks as to hint to the scheduler. Hoping that interactive tasks get more priority. Because at some times of day there has been a problem with the server being slow enough to cause timeouts. Especially the web frontend to vcs. Therefore if it isn't a time critical task then running it niced is a hint to the scheduler. The problem is that as a VM all of the system performance information is fake data and can't show the actual system state. And since we are currently I/O limited at times the system is often blocked waiting for I/O in which case the cpu priority doesn't matter. There is more cpu resource to go around than backplane disk I/O. But from the VM itself there isn't any useful performance data. Only the FSF admins have access to the dom0 and we count on them for real performance information from it. Unfortunately the FSF admin time to work on server performance problems has been limited. > I think you'd rather want to limit the number of threads it uses, > which also limits the memory footprint, which is probably the bigger > problem anyway and should probably be tuned further depending on how > beefy the server is. The dom0 server is an 8-core AMD Opteron running Xen for virtualization. It has sufficient RAM. But IMNHO too much I/O from all of the VMs running on it. The vcs VM is allocated seven xen cores. The hint about threads is a good one and I will keep an eye on it. Bob