hoannt@mail.ciid.cz.cc put forth on 9/30/2010 1:29 AM:
hoannt@mail.ciid.cz.cc put forth on 9/29/2010 11:22 PM:
Here's my out put when running TOP or FREE:
top - 11:16:52 up 2 days, 53 min, 2 users, load average: 0.00, 0.00, 0.00 Tasks: 144 total, 1 running, 143 sleeping, 0 stopped, 0 zombie Cpu(s): 2.0%us, 0.3%sy, 0.0%ni, 97.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 904020k total, 754172k used, 149848k free, 105632k buffers Swap: 2097144k total, 72k used, 2097072k free, 390776k cached
[root@localhost ~]# free total used free shared buffers cached Mem: 904020 753852 150168 0 105784 390820 -/+ buffers/cache: 257248 646772 Swap: 2097144 72 2097072
The Linux kernel heavily caches disk blocks. The bulk of your memory usage is in buffers/cache as with most Linux systems. Execute the following commands and look at the top row of the 'free' column.
$ echo 3 > /proc/sys/vm/drop_caches $ free -m
Your system is not low on memory at this point. The kernel will drop memory from the cache and free it for processes when the need arises. If you add 100 concurrent users to RC, far more of your memory will be consumed by processes and less by cache.
Again, your current slow RC response is due to something in the software stack on the server, or more likely, the client PC. What are the specs of the client PC hardware and software? This is relevant due to the java processing on the client. If your client PC/OS/Browser is slow, it won't matter how fast the server is responding.
Thank you! I'm analyzing my software stack at this moment. I will update you the last result later. BRs/ Hoan.
It may speed this process up tremendously if you'd create a test account and post the credentials on the RC list, along with the URL of the server. With a few of us logging in and seeing first hand how it performs, we may be able to narrow down the problem pretty quickly, saving all of us a bit of time with all the back/forth emails.