Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 6E10C200C56 for ; Fri, 14 Apr 2017 12:06:16 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 6CA9A160B8C; Fri, 14 Apr 2017 10:06:16 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id B46E5160B80 for ; Fri, 14 Apr 2017 12:06:15 +0200 (CEST) Received: (qmail 9361 invoked by uid 500); 14 Apr 2017 10:06:10 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 9288 invoked by uid 99); 14 Apr 2017 10:06:10 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Apr 2017 10:06:10 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 3745AC142D for ; Fri, 14 Apr 2017 10:06:10 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=6.31 tests=[SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id uySsokyjZzOy for ; Fri, 14 Apr 2017 10:06:06 +0000 (UTC) Received: from thor.wissensbank.com (thor.wissensbank.com [81.169.250.120]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 2B7065FAD8 for ; Fri, 14 Apr 2017 10:06:06 +0000 (UTC) Received: from thor.wissensbank.com (localhost [127.0.0.1]) by thor.wissensbank.com (Postfix) with ESMTP id 833EC15A60C4E for ; Fri, 14 Apr 2017 12:05:59 +0200 (CEST) Received: by thor.wissensbank.com (Postfix, from userid 500) id 6A53515A60DE5; Fri, 14 Apr 2017 12:05:59 +0200 (CEST) Received: from [192.168.245.129] (unknown [185.177.75.189]) (Authenticated sender: andre.warnier@ice-sa.com) by thor.wissensbank.com (Postfix) with ESMTPA id 5A39B15A60C4E for ; Fri, 14 Apr 2017 12:05:58 +0200 (CEST) Subject: Re: Memory usage increased form 500MB to 4 GB after changing the tomcat process from 32 bit to 64 bit execution To: users@tomcat.apache.org References: From: =?UTF-8?Q?Andr=c3=a9_Warnier_=28tomcat=29?= Message-ID: <58F09F24.1010109@ice-sa.com> Date: Fri, 14 Apr 2017 12:06:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP archived-at: Fri, 14 Apr 2017 10:06:16 -0000 On 14.04.2017 10:36, nagendra.raju@wipro.com wrote: > Hi All, > Problem statement: Memory usage increased form 500MB to 4 GB after changing the tomcat process from 32 bit to 64 bit execution > As tomcat memory has increased it is impacting available memory for other applications on server > > o Is this a bug ? > > o Earlier with 32bit it was running around 400MG, If we restrict the tomcat memory to 500GB for 64bit application will it any impact on tomcat operations > > Tomcat Version : Tomcat 7.0.73 on Solaris 11 > Maybe as a very first observation : it is not Tomcat that you changed. The Tomcat code has remained exactly the same. It is the Java JVM that was changed, from a 32-bit to a 64-bit version. So /that/ is the underlying reason for the memory usage increase, not Tomcat. Read more on the topic : http://lmgtfy.com/?q=java+32-bit+vs+64-bit (I recommend this one as a starter : http://howtodoinjava.com/for-fun-only/difference-between-32-bit-java-vs-64-bit-java/) Thus, to respond to your first question : no, it is no a bug; or at least not a Tomcat bug. About your second question : there is no such thing as a 64-bit application under Tomcat. All Tomcat applications are written in Java, and are ultimately run by the Java JVM. It is the JVM which determines if this uses, for example, 32-bit or 64-bit memory pointers, 4-byte or 8-byte object references etc. If you reduce the available memory for the Tomcat Heap, then, depending on the way the applications are written, this may cause more Memory Garbage Collections to occur in any given period of time. Whether this really impacts your applications or not, is something which only you can measure and determine. Try it, and look at the results. Or add more memory to your server. If you went from a 32-bit JVM to a 64-bit JVM, presumably you had a reason for doing that. Wat was the reason ? (And if there was no good reason, you can always go back). --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org