From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26003 invoked by alias); 4 Mar 2010 16:43:56 -0000 Received: (qmail 25977 invoked by uid 22791); 4 Mar 2010 16:43:53 -0000 X-SWARE-Spam-Status: No, hits=3.6 required=5.0 tests=AWL,BAYES_50,BOTNET X-Spam-Check-By: sourceware.org Received: from vms173009pub.verizon.net (HELO vms173009pub.verizon.net) (206.46.173.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 04 Mar 2010 16:43:48 +0000 Received: from [10.10.1.168] ([unknown] [209.190.166.162]) by vms173009.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0KYR00B9LNSOB380@vms173009.mailsrvcs.net> for gcc-help@gcc.gnu.org; Thu, 04 Mar 2010 10:43:37 -0600 (CST) Message-id: <4B8FE338.90902@verizon.net> Date: Thu, 04 Mar 2010 16:43:00 -0000 From: "John S. Fine" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-version: 1.0 To: Anna Sidera Cc: gcc-help@gcc.gnu.org Subject: Re: cannot run many programs simultaneously References: <4B8E9DCA.7080808@verizon.net> In-reply-to: Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2010-03/txt/msg00070.txt.bz2 Anna Sidera wrote: > If increasing the swap space makes them vrey slow this will not help me. The reason I run 6 programms simultaneously is to save time. > We don't know that increasing swap space would change it from failing to crawling. It might do that. But it might change it from failing to working just fine. That depends on details of the memory access pattern that you really can't know until you try. > Can you explain 'hit either the system over commit limit or actual exhaustion of memory'? > In your later email you showed one process whose total virtual memory was 8809MB and resident memory was 1.5GB and the system wide swap use was 35404KB. Not all of the 8809MB is committed memory, but probably nearly all of it. Not all of the 1.5GB of resident memory is used committed memory, but probably almost all of it, plus all of the 35404KB swap usage is used committed memory by some task, probably some of it is for this task. Should I assume you ran top when that process was at or near its maximum memory use? If so, I can estimate the used committed memory for six of those as around 9GB. That is likely to be OK (not exhaust memory) with 10GB of physical ram and nearly 3GB of swap. But that doesn't leave much margin. So I can't say with confidence that memory isn't exhausted. I think you should significantly increase the 3GB swap space. We can estimate about 52GB of committed memory for the six processes. I forget the exact parameters and formula that control over commit. Roughly, Linux adds most of the memory size to all off the swap size and then multiplies that by some over commit factor to get the maximum it will commit. With just 3GB swap and 10GB ram and default settings for those parameters, I doubt that it would let you commit 52GB. Since the ratio of commit to used in this process seems to be higher than typical, you might fix the problem by only changing the over commit parameters. You really should be asking in a Linux forum, not a GCC mailing list to learn how to do that. Increasing the swap space, even if that swap space ends up not being used, will affect the result of the over commit computation, so you might fix the problem just by increasing swap space and not tweaking the over commit parameters. But that might need swap space that is a significant fraction of the 52GB you seem to want to commit. If you have new large disks, that much swap space might be trivial and allocating it might be the simplest and most robust solution to your problem. If you have older smaller disks, many GB of swap space might be a serious cost. > I will ask about this problem at the linux forum also. > > You should have. Maybe post the URL of your question in that forum as a message to close the topic from further discussion here.