Mantis - Resin
Viewing Issue Advanced Details
3465 major always 04-29-09 08:32 11-30-09 11:21
diximedia  
ferg  
high  
closed 3.2.1  
fixed  
none    
none 4.0.2  
0003465: Resin does not use more than 1 CPU
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?
We are using:
* Resin Professional 3.2.1
* Quercus PHP/JAVA servlet
* Ubuntu Server 8.10
* Linux Kernel 2.6.24-19-server

Notes
(0003978)
kvirkki   
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?
(0003979)
diximedia   
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:
  <customer>Diximedia</customer>
  <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
(0003980)
kvirkki   
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.
(0003982)
ferg   
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.
(0003986)
diximedia   
05-07-09 03:11   
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.

(0004053)
diximedia   
06-04-09 08:57   
hello??? is there any body out there???

:)
(0004054)
ferg   
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.
(0004063)
mate   
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.
(0004071)
diximedia   
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)
(0004072)
mate   
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.
(0004105)
diximedia   
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!!!
(0004222)
ferg   
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.
(0004223)
mate   
09-08-09 21:40   
ferg, what is the environment where you've got this working? OS and JVM should be most interesting.
(0004224)
ferg   
09-09-09 09:50   
ubuntu/jdk 1.6. I can check with some other systems.
(0004302)
diximedia   
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! :)
(0004304)
mate   
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.
http://store.caucho.com/items.jsp?category=259128 [^]
(0004315)
ferg   
11-30-09 11:21   
Thanks for the updates.