0003465: Resin does not use more than 1 CPU

(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> 

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
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.

(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.

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 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.

(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.

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

Relationships