Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
From: "Robinson, Eric" <eric.robinson@psmnv.com>
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Free Memory vs. Total Memory vs. Max Memory
Date: Fri, 17 Feb 2012 20:41:00 -0800
Message-ID: <768FEA3F936926468F594E3CA7741FE803BD611F@ipa-vault.nvipa.com>
Thread-Topic: Free Memory vs. Total Memory vs. Max Memory
thread-index: AcztwAUouuJlIGTJRQyCZIaXax6u9gANUT/Q
References: <768FEA3F936926468F594E3CA7741FE803BD6031@ipa-vault.nvipa.com>
 <4F3E0FAF.60309@ice-sa.com> <4F3E6C52.5030001@christopherschultz.net>
 <768FEA3F936926468F594E3CA7741FE803BD60C1@ipa-vault.nvipa.com>
 <4F3ECEB9.3070107@ice-sa.com>
To: "Tomcat Users List" <users@tomcat.apache.org>

> >> I can see the lure of "only taking what you need" and allowing the=20
> >> JVM to automatically re-size the memory space:
> >> that way, you only take up a huge chunk of memory during peak load=20
> >> and not all the time.
> >>
> >> But why?
> >>
> >> If you are going to need, say, 512MiB at peak load, you're=20
> going to=20
> >> need that memory available whether or not it is allocated=20
> to the JVM=20
> >> itself at any given time. If that's the case, why not let the JVM=20
> >> have that memory all the time?
> >=20
> >=20
> > Because the server has about 100 instances of tomcat. They=20
> do not all=20
> > need the memory at the same time.
> >=20
>=20
> Famous last words..
>=20
> But if they ever do, you are going to experience random=20
> failures of your Tomcat instances, or at the very least a=20
> dramatic drop in performance, when this starts to swap to disk.
>=20
> We don't know what your precise circumstances are, and maybe=20
> your case is special.
> But in general, I would not recommend this as a way to run a=20
> production server.
>=20
> Technically, you can do what you described.  What results it=20
> will have in the practice, you will find out.
>=20

Okay, full disclosure time.

We have many servers that have been running 100-200 instances of tomcat
each for years without any performance problems. Most of our servers are
Linux 8-core machines with 32GB RAM, with the tomcat instances
configured with -Xms16M -Xmx192M. We also have some Windows servers with
100-150 instances of tomcat each, most of which are configured with
-Xms16M -Xmx64M.=20

Recently, we had someone tell us that a particular thread of one
particular Windows tomcat instance was freezing up due  to lack of
memory. They insisted that we set that instance to -Xms512M -Xmx512M. I
felt that they were wrong because there were no OOM or GC messages in
the logs, but I wanted to make them happy, so I set it to -Xms16M
-Xmx512M because I felt that this would give them the max memory they
were requesting while also ensuring that the instance did not use more
memory than it really needed. It seemed like a win-win. However, they
were not happy. They insisted that we set the minimum to 512M as well. I
did it but I am annoyed. I don't think my approach is dangerous at all
becaise the time involved in allocating memory and doing GC does not
have a significant impact on performance. My plan was to come onto the
tomcat list and see if I could drum up support for my thoughts, but I
realize that I also risk being told that I'm wrong. :-)

--Eric


Disclaimer - February 17, 2012=20
This email and any files transmitted with it are confidential and =
intended solely for Tomcat Users List. If you are not the named =
addressee you should not disseminate, distribute, copy or alter this =
email. Any views or opinions presented in this email are solely those of =
the author and might not represent those of Physicians' Managed Care or =
Physician Select Management. Warning: Although Physicians' Managed Care =
or Physician Select Management has taken reasonable precautions to =
ensure no viruses are present in this email, the company cannot accept =
responsibility for any loss or damage arising from the use of this email =
or attachments.=20
This disclaimer was added by Policy Patrol: http://www.policypatrol.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org