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.