> [email protected] 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 >> >> --------------------------- >> >> [r...@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. > > -- > Stan > > > _______________________________________________ > List info: http://lists.roundcube.net/users/ > BT/ee2c3396 >
Thank you! I'm analyzing my software stack at this moment. I will update you the last result later. BRs/ Hoan. _______________________________________________ List info: http://lists.roundcube.net/users/ BT/8f4f07cd
