My wordpress sites are loading quite slow : Normal page , betw 15-30 secs , do you think its acceptable . Below is the stats using iwebtool : Domain name Size Load time (secs) Average Speed per kb 01 mysite.com/wp-admin/ 1.42 KB 10.35 seconds 7.27 seconds 02 miste.com 29.54 KB 27.77 seconds 0.94 seconds 03 mysite2.com/wp-admin/ 1.83 KB 11.49 seconds 6.26 seconds 04 mysite2.com 26.86 KB 14.69 seconds 0.55 seconds Any advice ?
yeah you can do it. or if you are using cpanel then you can simply logon to whm and check out the apache , cpu/mysql usage and you will also come to know which script or file is creating such problems.
I'm using a budget vps (64m ram) , no control panel (got webmin , and basic apache, php, mysql only!) from top: top - 00:48:39 up 4 days, 5:50, 1 user, load average: 0.00, 0.00, 0.00 Tasks: 34 total, 1 running, 33 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 6159736k total, 6124608k used, 35128k free, 198928k buffers Swap: 31455260k total, 578456k used, 30876804k free, 2617508k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 16 0 1856 608 520 S 0 0.0 0:00.09 init 31814 root 16 0 2220 544 456 S 0 0.0 0:00.08 syslogd 31831 root 16 0 5416 1140 840 S 0 0.0 0:01.35 sshd 31865 root 18 0 2524 792 660 S 0 0.0 0:00.00 xinetd 31949 root 18 0 3616 1136 972 S 0 0.0 0:00.00 mysqld_safe 32005 mysql 16 0 125m 21m 4516 S 0 0.4 10:11.08 mysqld 32049 root 16 0 8344 2160 1100 S 0 0.0 0:01.56 sendmail 32072 smmsp 16 0 7268 1656 840 S 0 0.0 0:00.01 sendmail 32112 root 16 0 16556 5896 3864 S 0 0.1 0:00.42 httpd 32121 root 16 0 4092 932 536 S 0 0.0 0:00.04 crond 32174 root 16 0 8744 5184 1704 S 0 0.1 0:00.21 miniserv.pl 32069 apache 16 0 27560 16m 4032 S 0 0.3 1:13.75 httpd 32070 apache 16 0 27548 16m 3852 S 0 0.3 1:10.36 httpd 32073 apache 16 0 28308 17m 4012 S 0 0.3 1:11.86 httpd 1604 apache 16 0 28320 17m 4016 S 0 0.3 1:09.41 httpd 22159 apache 16 0 26272 15m 4000 S 0 0.3 0:47.03 httpd 22189 apache 16 0 26568 15m 3988 S 0 0.3 0:47.35 httpd How can you tell which the culprit ?
aldy moved most of the sites, webhost not responsive. Seems like free memory < 1% Anything else wrong ?
Linux caches memory. You need to run free -m and see how much of that memory is buffered to really know. A lot of memory usage is just linux efficiently using it, caching code that is run often, a lot of the time. And your CPU load is basically at 0, so I don't think that's the problem. Just ping and traceroute the network from various places. See if you can pin down where the slowness is, and try more than one speed tool. Is it that slow from your house? If so, ping/traceroute from there. To me, it doesn't look like the server itself is having problems, maybe the network. Make sure to stay in the box for a while and monitor what happens when you get traffic (i.e. mysql spikes, apache children die suddenly... etc). Hope that helps some. Also, if you sign up for google webmaster sitemaps, it will tell you on average how long google took to access pages during it's crawl, which is pretty useful for determining speed, i think, since googlebot tends to come from all over. Later!
The server can't make it with that amount of memory. You can notice that it makes use of swap file too, which means you have to upgrade.
I really don't think memory is the issue, as I said, linux caches memory. It also looks like top is showing your box's CPU at 100% IDLE. ALSO, look at your load averages for the last 1,5,15 minutes (and remember load is a calculation based on CPU usage over that time as sampled by top) : load average: 0.00, 0.00, 0.00 Code (markup): top is saying all your apps are idle, nothing is waiting on the CPU, this box is basically doing nothing. This is not a load problem, or a memory problem. --- Look, here is the mem on a dedicate box running almost nothing. Like 2 websites that get a small amount of traffic : Mem: 1030956k av, 1017464k used, 13492k free, But, if you run free -m : # free -m total used free shared buffers cached Mem: 1006 993 12 0 134 488 -/+ buffers/cache: 370 636 Swap: 1027 187 840 Code (markup): You see that most of it is in the cache, and the swap will always have some in it, generally, not a big deal. Now, if you run "vmstat 1" it will show you how much is going in and out of the swap : #vmstat 1 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 0 191704 13260 138216 500492 0 1 0 1 0 1 0 1 0 0 0 0 191704 13260 138216 500492 0 0 0 0 105 19 0 0 100 0 0 0 191704 13260 138216 500492 0 0 0 0 103 32 0 0 100 0 0 0 191704 13056 138216 500492 0 0 0 0 105 54 2 1 97 0 0 0 191704 13064 138216 500492 0 0 0 0 103 18 0 0 100 0 0 0 191704 13064 138216 500492 0 0 0 448 151 42 0 0 100 0 0 0 191704 13064 138216 500492 0 0 0 0 105 20 0 4 96 0 0 0 191704 13064 138216 500492 0 0 0 0 105 17 0 0 100 0 0 0 191704 13064 138216 500492 0 0 0 0 106 15 0 0 100 0 0 0 191704 13064 138216 500492 0 0 0 0 104 17 0 0 100 0 0 0 191704 13064 138216 500492 0 0 0 12 105 21 0 0 100 0 0 0 191704 13064 138216 500492 0 0 0 0 104 19 0 0 100 0 0 0 191704 13064 138216 500492 0 0 0 0 107 35 0 0 100 0 0 0 191704 13064 138216 500492 0 0 0 0 104 32 1 1 98 0 0 0 191704 13064 138216 500492 0 0 0 0 104 17 0 0 100 0 0 0 191704 13108 138216 500492 0 0 0 440 166 80 0 1 99 Code (markup): As you can see the "so" "si" columns have almost no activity, i.e. nothing going in or out of swap space on the disk. So in summary, if you have a dedicated server, it's not loaded at all. Suggesting an upgrade is pretty over the top for a server that is 100% idle. On a virtual server, it might show more load, but I'm not sure if you'd be able to see mem and swap usage of the other "virtual systems." That could be an issue. But top reporting low free memory really means nothing at all. So, test the network thoroughly before you think about upgrading the box, any slowness is prolly due to a network problem. Like I said, test from multiple sources, and if it's bad all over, run traceroutes and pings and talk to your host about it. They need to resolve network issues. (Or if this is a virtual box, have them make sure nothing else is killing your virtual system, outside of your virtual system, because the stats you have provided really show no problem at all.)