Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0003465 [Resin] major always 04-29-09 08:32 11-30-09 11:21
Reporter diximedia View Status public  
Assigned To ferg
Priority high Resolution fixed  
Status closed   Product Version 3.2.1
Summary 0003465: Resin does not use more than 1 CPU
Description We've been doing performace's tests and have noticed that Resin Professional is not using our multi-processor boxes properly. As we needed to confirm our suspicions, we did compare 1 CPU box Vs. 2 CPU box, and the performace tests just gave the same figures. JVM is clearly using just 1 processor. Is there any configuration trick for SMP kernels?
Additional Information We are using:
* Resin Professional 3.2.1
* Quercus PHP/JAVA servlet
* Ubuntu Server 8.10
* Linux Kernel 2.6.24-19-server
Attached Files

- Relationships

- Notes
05-05-09 00:17

I've heard similar complaints from some of our customers... Does it also happen if you have multicore processors or just if you have physically separate CPUs? I don't know how Resin could really prevent using multiple processors.

BTW, do you have license for more than 1 CPU?
05-05-09 02:31

Hi kvirkki,

We're using vmware, so the core are into virtual technology, and vmware provide it. We cannot test it into physical boxes at the moment.

of course, we have licenses for two cpu:
  <server-count>2</server-count> <!-- CPU count -->

We have made some changes in java args with the same results, one cpu gives the same performance that two cpu box. meanwhile we can continue adding more 1 cpu to the load-balancer.. but that not solve the problem.

Thank you
05-05-09 03:02

Hi diximedia,

So, if you monitor CPU usage, you don't see any significant usage of the other CPU when running Resin? Do you have enough concurrent HTTP requests coming in to see if thread processing really is occurring in both CPUs or not?

I haven't ever experienced this myself, but I haven't checked it in a vmware image.
05-06-09 11:27

We haven't been able to reproduce this here either. Resin doesn't do any CPU-limiting deliberately.

There have been a few weird threading/locking issues that we're trying to avoid (something about creating lots of threads or Thread.yield() or something similar causes odd behavior in synchronized blocks.) That weirdness it the closest we've come to reproducing that behavior.
05-07-09 03:11
edited on: 05-07-09 03:21

Hi kvirkki, we have generated tons of work load against 2CPU and 1CPU boxes, while monitoring the CPU and memory usage and load average. The generated workload against the application (an http-servlet built on Quercus JAVA-Php technology) was just a set of random HTTP requests which returned some data.

We started warming-up the servers and made several tests with different work loads: 1 request/second, 10 requests/second, 20 requests/second...and so on.

While we were shooting to a 2CPU box, we realized that the server's capacity reached the top because the application's performace (the time needed to process each request) started to fall, and it just didn't make sense because the load average was just 2.0 and the total CPU usage arround 40 and 60% (notice that we are talking about a 2CPU machine). We were wondering why the application's performaced decreased while the load average was just a half of the theoretical server capacity (~ 4.0). We confirmed our suspicions when we did the same test again a 1CPU box and the results were just the same.

To sum up, the same performace tests, against 1CPU and 2CPU box gave just the same figures.

Do you know if it could be a JVM's issue? any missing parameters?

What would we do? We are just thiking about using another servlet container.

06-04-09 08:57

hello??? is there any body out there???

06-04-09 09:33

We haven't been able to reproduce the issue here, and Resin itself doesn't have any CPU-throttling code. We did clean up locking/threading for the 4.0.0 release, but because we've never been able to reproduce the problem, we can't mark it closed.
06-08-09 10:22

We have noticed the same problem. According to Caucho there should be no need to enable this explicitly. In our case it is Red Hat Enterprice Linux and Resin 3.1.8.
06-09-09 11:26

Hi mate,
Have you tested it in a physical environment or virtualized environment?
i'm happy to know we aren't alone in that issue.. :-)
For caucho's team, is easy to reproduce. Try it (1 cpu box heavy load vs 2 cpu box heavy load)
06-09-09 12:19

We have been testing with Resin 3.1.8 in an environment with 4 different dual-core CPUs (I think). We requested an evaluation license for multiple CPUs.

Inspired by JavaSpecialists newsletter we create a simple test class to test concurrency. When run standalone the test shows both by output and system monitoring that multiple CPUs are in use, when running the test under Resin, only one CPU is used.
07-29-09 03:48

hi all caucho team,
I think this is a TRUE HISTORY. We already done some tests..and ONLY CPU IS USED.

Please, help us!! We have paid a licence for your product and we need your help..if you see the first POST, we have sending to you notices FROM MAY..three months!!!
09-08-09 14:09

We still haven't been able to reproduce it here.

Checked with 4.0.1 and verified that multiple CPUs are being used properly.
09-08-09 21:40

ferg, what is the environment where you've got this working? OS and JVM should be most interesting.
09-09-09 09:50

ubuntu/jdk 1.6. I can check with some other systems.
11-18-09 09:45

Freg is right, we have tested Resin 4.0 and the SMP problem is solved.

We have to upgrade to 4.0

By the way, we have v3.0 licenses. Does anybody know if we have to order new licenses? I hope not! :)
11-18-09 22:55

Yes, with 4.0 it works for us too, so issue could probably be closed.

About licenses: You may use any Resin version released within a year from the license issue date. [^]
11-30-09 11:21

Thanks for the updates.

- Issue History
Date Modified Username Field Change
04-29-09 08:32 diximedia New Issue
05-05-09 00:15 kvirkki Issue Monitored: kvirkki
05-05-09 00:17 kvirkki Note Added: 0003978
05-05-09 02:31 diximedia Note Added: 0003979
05-05-09 03:02 kvirkki Note Added: 0003980
05-06-09 11:27 ferg Note Added: 0003982
05-07-09 03:11 diximedia Note Added: 0003986
05-07-09 03:12 diximedia Note Edited: 0003986
05-07-09 03:20 diximedia Issue Monitored: diximedia
05-07-09 03:21 diximedia Note Edited: 0003986
06-04-09 08:57 diximedia Note Added: 0004053
06-04-09 09:33 ferg Note Added: 0004054
06-08-09 10:20 mate Issue Monitored: mate
06-08-09 10:22 mate Note Added: 0004063
06-09-09 11:26 diximedia Note Added: 0004071
06-09-09 12:19 mate Note Added: 0004072
07-29-09 03:48 diximedia Note Added: 0004105
07-29-09 08:57 nam Priority normal => high
09-08-09 14:09 ferg Note Added: 0004222
09-08-09 21:40 mate Note Added: 0004223
09-09-09 09:50 ferg Note Added: 0004224
09-24-09 10:35 mzach Issue Monitored: mzach
11-18-09 09:45 diximedia Note Added: 0004302
11-18-09 22:55 mate Note Added: 0004304
11-30-09 11:21 ferg Note Added: 0004315
11-30-09 11:21 ferg Assigned To  => ferg
11-30-09 11:21 ferg Status new => closed
11-30-09 11:21 ferg Resolution open => fixed
11-30-09 11:21 ferg Fixed in Version  => 4.0.2

Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
71 total queries executed.
46 unique queries executed.
Powered by Mantis Bugtracker