Celso Magalhães Dantas Neto wrote:
Thanks everyone for the reply!
My problem is not to argue how the application is consuming RAM, but to
show that 150MB is not too much memory. But for that I'd like to use
trusted information such as an article, or official info. The client
doesn't understand anything about technologies but has opened the Windows
Task Manager and saw that Tomcat is on top 3 in memory consumption. I just
need to argue with him that 150MB is normal for a Java web app.
Celso,
your client, as you describe, knows nothing about technology or programming.
And in this case, you are his expert.
So if he knows nothing about the subject, but he does not accept the opinion of an expert,
then the problem with your customer is bigger than about a few MB of RAM, and you are
probably wasting your time.
As mentioned previously, the current cost of 150 MB of RAM is about US$ 2.00.
So why are you (both) wasting your time about this ?
I know that "normal" really depends on how your/my application
Exactly. And nobody here knows your application, so nobody can tell you if 150 MB total
is justified or not in this case.
> And yes I could start Tomcat with no app, and create a 1 CRUD application,
but I would prefer to argue with some trusted article or official
information.
This user list is the official Apache Tomcat project's users list, where Tomcat users from
the whole world come to report problems and get advice and help.
Many of the people here answering questions are members of the official Tomcat development
team. "MarkT" and "Pid" who answered before, /are/ Tomcat developers. How much more
"official" do you need ? Would some article on Google written by some unknown "expert" be
better ?
And what these real experts have been telling you so far is that 150 MB of total memory
shown in the Windows Task Manager, to run a Java JVM + Tomcat + an application is nothing
that makes anybody wonder. It looks perfectly "normal" for an application which does
something useful, as we assume yours does.
If it may help :
Following are some snapshots taken tonight on different production Linux systems, using
the Linux "ps" utility, and sorting the processes by memory usage (more memory first).
In each case, Tomcat runs basically the same simple application, consisting of a single
servlet.
As you can see, in most cases the top slots are occupied by java processes, with Tomcat
among them. And they all use much more than 150 MB, despite the fact that all these
systems are in Europe, and not doing very much right now.
system # 1 :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26076 root 20 0 2386m 1.1g 9232 S 0 9.5 13:41.97 java
21875 tomcat55 20 0 698m 209m 9.8m S 0 1.7 54:02.10 jsvc
3862 star 20 0 418m 176m 8936 S 0 1.5 20:24.53 java
system # 2 :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3053 tomcat55 20 0 320m 120m 12m S 0 6.0 462:27.13 jsvc
2916 star 20 0 353m 93m 11m S 0 4.7 376:03.26 java
21871 star 20 0 285m 79m 7648 S 0 4.0 2:49.06 java
system # 3 :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
32116 www-data 20 0 717m 198m 6044 S 0 9.9 0:57.12 apache2
2958 tomcat55 20 0 456m 195m 9368 S 0 9.7 2120:42 java
32065 star 20 0 411m 142m 8996 S 0 7.1 12:34.17 java
32126 www-data 20 0 667m 138m 6056 S 0 6.9 0:37.78 apache2
system # 4 :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3189 tomcat55 20 0 435m 296m 12m S 89.1 14.6 3049:49 jsvc
2744 root 20 0 3276 1348 1108 R 9.6 0.1 3658:11 vmware-guestd
17156 mira 20 0 40488 36m 2340 S 0.7 1.8 104:18.14 MiraLoader.pl
3234 star 20 0 214m 38m 11m S 0.3 1.9 46:10.17 java
The "RES" column is the "resident" memory, "VIRT" is the virtual memory.
Compare that with the equivalent columns in your customer's Windows Task
Manager.
Note : the "jsvc" program is also java, running Tomcat.
Unfortunately, I do not have an equivalent system running Windows, but the figures would
be much the same.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
