Invision Community 4: SEO, prepare for v5 and dormant account notifications Matt November 11, 2024Nov 11
Posted July 10, 201113 yr We moved to a VPS and the index.php file in the root directory of the board is always causing a high CPU usage. Is there anything that can help bring that down?
July 10, 201113 yr Note that PHP is a server side scripting language, which means that every time a page with PHP is requested (e.g. the homepage of your forums), another PHP process is started and ran. If you have a lot of traffic, the load on your server will increase as each PHP script is requested. Firstly, I advise that you restart your HTTP server. This usually helps "runaway" PHP processes. If that doesn't help, you should tweak your HTTP and PHP configurations to limit traffic or load. There are also options in IPB server environment to do similar things. It's also possible that another VPS user on the same physical server as you is using a lot of CPU which would also affect you because the resources are shared to some degree. You can also use something called htop that you run in commandline (have to download it from repos) that'll give you details on what your processes are doing. Are you using a hosting panel like cpanel or straight Apache + PHP + MySql or similar?
July 11, 201113 yr Index.php is generally almost the entire forum so that's going to be quite difficult, I suggest changing some settings to minimize queries and scripts running, remove any optional blocks from your forum and possibly even putting it in performance mode. Also, turn off GZip and load Javascript from Google in the optimization settings.
July 11, 201113 yr Author Already turned the gzip off earlier today and the JS has been from google. One thing I did that has seemed to help so far is limiting the frequency of the bots. Prior to reducing them, we had 16k hits in 11 hours. The 500 errors have stopped.
July 11, 201113 yr If you have not already, disable as many hooks as you can, most importantly any 3rd party hooks which may be poorly optimized.
July 11, 201113 yr In the "CPU Saving & Optimization" section, I toggled: • Cache calendar and birthdays? • Kill long running search queries. • Show Board Totals? • Disable Profile Statistics?
July 11, 201113 yr • Cache calendar and birthdays? • Kill long running search queries. • Show Board Totals? • Disable Profile Statistics? If you go to Support in your IPB ACP and go to SQL Toolbox and check all and hit Optimize Selected Tables and hit Go that might help you some
July 11, 201113 yr Author If you have not already, disable as many hooks as you can, most importantly any 3rd party hooks which may be poorly optimized. First thing that I tried with no success. I did find one that was sometimes producing bad sql errors and it's still disabled. • Cache calendar and birthdays? • Kill long running search queries. • Show Board Totals? • Disable Profile Statistics? Tried those too. If you go to Support in your IPB ACP and go to SQL Toolbox and check all and hit Optimize Selected Tables and hit Go that might help you some Tried that too. Thanks for the replies. This all started after going from shared to a VPS. I'm just wondering now if the Apache/PHP/MYSQL need proper tweaking. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1216 linc2 19 0 159m 36m 19m R 24.6 2.7 0:00.74 php 1209 linc2 20 0 158m 35m 19m R 19.6 2.6 0:00.83 php 1215 linc2 17 0 157m 32m 17m R 18.0 2.4 0:00.54 php 1213 linc2 19 0 0 0 0 Z 14.3 0.0 0:00.53 php <defunct> 1202 linc2 21 0 0 0 0 Z 0.0 0.0 0:00.64 php <defunct>
July 11, 201113 yr First thing that I tried with no success. I did find one that was sometimes producing bad sql errors and it's still disabled. Tried those too. Tried that too. Thanks for the replies. This all started after going from shared to a VPS. I'm just wondering now if the Apache/PHP/MYSQL need proper tweaking. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1216 linc2 19 0 159m 36m 19m R 24.6 2.7 0:00.74 php 1209 linc2 20 0 158m 35m 19m R 19.6 2.6 0:00.83 php 1215 linc2 17 0 157m 32m 17m R 18.0 2.4 0:00.54 php 1213 linc2 19 0 0 0 0 Z 14.3 0.0 0:00.53 php <defunct> 1202 linc2 21 0 0 0 0 Z 0.0 0.0 0:00.64 php <defunct> What hosting control panel are you using (e.g. cPanel, Kloxo, etc)?
July 11, 201113 yr Author What hosting control panel are you using (e.g. cPanel, Kloxo, etc)? cPanel and Virtuozzo
July 11, 201113 yr Author System CENTOS 5.6 x86_64 MYSQL 5.1.56 PHP Version 5.2.17 (cgi-fcgi) Apache/2.2.19 Total processors: 1 Processor #1 Intel® Xeon® CPU E5620 @ 2.40GHz Speed 2394.069 MHz Cache 12288 KB Memory 1.3GB memcached is installed Usually the memory usage is less than 50%. just the server load and CPU % are high
July 11, 201113 yr cPanel and Virtuozzo Try this: https://support.amhosting.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=80&nav=0,18
July 12, 201113 yr Author Well, after adjusting apache/php/sql, my friend ended up upgrading to the next level of vps, so far so good though.
July 12, 201113 yr It happens a lot going from shared hosting to vps. WIth shared hosting you have access to all of the server resources and if they are not tied up by other accounts then it is like having a really nice dedicated server. The problem with shared though is if you get a couple of accounts on it that are using a lot of resources then everyone suffers. Shared servers are usually fairly stout as far as hardware goes. Once you make the switch to vps you are restricted to your allotment of resources which explains the high loads depending how much traffic you have.
July 12, 201113 yr Author It happens a lot going from shared hosting to vps. WIth shared hosting you have access to all of the server resources and if they are not tied up by other accounts then it is like having a really nice dedicated server. The problem with shared though is if you get a couple of accounts on it that are using a lot of resources then everyone suffers. Shared servers are usually fairly stout as far as hardware goes. Once you make the switch to vps you are restricted to your allotment of resources which explains the high loads depending how much traffic you have. Yeah, I agree. The thing was, everything was fine on the site with shared, then all of a sudden the host blocked it and said that it was spiking too much of a server load. I still blame the bots a little. I should start a topic to see how many bots visit a site within a 24 hour period.
July 12, 201113 yr Yeah, I agree. The thing was, everything was fine on the site with shared, then all of a sudden the host blocked it and said that it was spiking too much of a server load. I still blame the bots a little. I should start a topic to see how many bots visit a site within a 24 hour period. You can use analytical software in your control panel or external (e.g. Google Analytics) to accomplish the same task.
July 12, 201113 yr Author Got both running. I think before I had made changes to the robots.txt and to analytic s, we had 18,000 visits in 12 hours. Not sure if that's high, low, or normal for indexing visits. Never really compare it to a comparable busy site.
July 12, 201113 yr Got both running. I think before I had made changes to the robots.txt and to analytic s, we had 18,000 visits in 12 hours. Not sure if that's high, low, or normal for indexing visits. Never really compare it to a comparable busy site. There are plenty of optimization tweaks within the IP.Board ACP to decrease your server load. You can use the "htop" package in console to get detailed information about each process that is running.
July 12, 201113 yr Author have memcache installed. So far with the upgrade, it's been fine. Will see in a few days.
July 12, 201113 yr Got both running. I think before I had made changes to the robots.txt and to analytic s, we had 18,000 visits in 12 hours. Not sure if that's high, low, or normal for indexing visits. Never really compare it to a comparable busy site. Ban some bad robots.. I had to ban few on my forums..
July 12, 201113 yr Author Ban some bad robots.. I had to ban few on my forums.. I'm thinking of only allowing the major players
Archived
This topic is now archived and is closed to further replies.