I have a shared server account with Lunarpages that I have been using for the past three years to host a fan wiki for a tv show. Everything was running smoothly until about a month or so ago. It was a couple of weeks after I had updated to Mediawiki 1.15 (I had been using 1.13 previously). I got a message from Lunarpages that index.php was using too much of the server's processor power (spiking from 1.3% - 2.5% cpu, the allowable limit on the shared server is 1% ).
They disabled the script until I could find a solution. There was a fatal error that I noticed in my php error log:
[20-Jul-2009 16:57:40] PHP Fatal error: require() [<a href='function.require'>function.require</a>]: Failed opening required '{EDIT}//w/includes/parser/LinkHolderArray.php' (include_path='/{EDIT}/w:/{EDIT}/w/includes:/{EDIT}/w/languages:.:/usr/lib/php:/usr/local/lib/php') in /{EDIT}//w/includes/AutoLoader.php on line 582
Shortly before the incident, 1.15.1 had come out and it did have some bugfixes so I upgraded, figuring the error may have been the cause of the spike. After the upgrade, I noticed no more fatal errors. The issue seemed to go away for a bit, until I got a notice a couple of days later of another spike:
Average %CPU usage - 1.35 Average %Memory usage - 0.82 Average %MySQL usage - 0.1
{EDIT} 1.35 0.82 0.1 Top Process %CPU 50.0 [php-cgi] Top Process %CPU 43.0 [php-cgi] Top Process %CPU 34.0 /usr/local/php5/bin/php-cgi /{EDIT}/public_html/w/index.php
Is my wiki just outgrowing the shared host? In the past 6 months my daily averages have been ~15-31k hits amongst 500-1000 visitors. Any ideas what I can reasonably expect Mediawiki to support while staying under my host's 1% load (I'm not sure of their hardware....) Are there certain questions I should be asking the tech support people to try to narrow down where the issue lies?
Are there any configuration settings I should know about that could minimize the load? I've already turned off all the ajax functions.
I really can't afford a dedicated server just for a hobby site, but I'd hate to have to bring the wiki down. It'd also be a pain to find a new host since I just this month paid for the next year of hosting. Thanks for all the help you can offer.
-F.t. Petracca
Hi!Just a few ideas. Maybe you could - enable the file caching for non logged visitors $wgMainCacheType = CACHE_NONE; $wgMemCachedServers = array(); $wgUseFileCache = true; $wgFileCacheDirectory = "{$wgUploadDirectory}/cache"; $wgShowIPinHeader = false;//because html result of page is cached - disable TeX if you don't need it ($wgUseTeX=false) - disable ImageMagick? not sure about this, which of php GD or ImageMagick use more CPU? Maybe im is not accessible on shared host : $wgUseImageMagick = false - disable MimeMagick (don't know exactly what it does, I disabled it because it caused me errors) : $wgMimeTypeFile= NULL; $wgMimeInfoFile= NULL; $wgMimeDetectorCommand = NULL; $wgVerifyMimeType= false; - disable category browser : wgUseCategoryBrowser=false; - disable hint counter : $wgDisableCounters = true; - make sure you didn't activate some debug features : $wgDebugDumpSql = false; $wgShowSQLErrors = false; ...
which extensions and hooks do you use ?
My 2 cents,
Sylvain (on holidays for 10 days)
2009/8/20 Francesco Petracca ftpetracca@gmail.com
I have a shared server account with Lunarpages that I have been using for the past three years to host a fan wiki for a tv show. Everything was running smoothly until about a month or so ago. It was a couple of weeks after I had updated to Mediawiki 1.15 (I had been using 1.13 previously). I got a message from Lunarpages that index.php was using too much of the server's processor power (spiking from 1.3% - 2.5% cpu, the allowable limit on the shared server is 1% ).
They disabled the script until I could find a solution. There was a fatal error that I noticed in my php error log:
[20-Jul-2009 16:57:40] PHP Fatal error: require() [<a href='function.require'> function.require</a>]: Failed opening required '{EDIT}//w/includes/parser/LinkHolderArray.php' (include_path='/{EDIT}/w:/{EDIT}/w/includes:/{EDIT}/w/ languages:.:/usr/lib/php:/usr/local/lib/php') in /{EDIT}//w/includes/AutoLoader.php on line 582
Shortly before the incident, 1.15.1 had come out and it did have some bugfixes so I upgraded, figuring the error may have been the cause of the spike. After the upgrade, I noticed no more fatal errors. The issue seemed to go away for a bit, until I got a notice a couple of days later of another spike:
Average %CPU usage - 1.35 Average %Memory usage - 0.82 Average %MySQL usage - 0.1
{EDIT} 1.35 0.82 0.1 Top Process %CPU 50.0 [php-cgi] Top Process %CPU 43.0 [php-cgi] Top Process %CPU 34.0 /usr/local/php5/bin/php-cgi /{EDIT}/public_html/w/index. php
Is my wiki just outgrowing the shared host? In the past 6 months my daily averages have been ~15-31k hits amongst 500-1000 visitors. Any ideas what I can reasonably expect Mediawiki to support while staying under my host's 1% load (I'm not sure of their hardware....) Are there certain questions I should be asking the tech support people to try to narrow down where the issue lies?
Are there any configuration settings I should know about that could minimize the load? I've already turned off all the ajax functions.
I really can't afford a dedicated server just for a hobby site, but I'd hate to have to bring the wiki down. It'd also be a pain to find a new host since I just this month paid for the next year of hosting. Thanks for all the help you can offer.
-F.t. Petracca
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Sylvain Machefert escribió:
Hi!Just a few ideas. Maybe you could
- enable the file caching for non logged visitors $wgMainCacheType = CACHE_NONE; $wgMemCachedServers = array(); $wgUseFileCache = true; $wgFileCacheDirectory = "{$wgUploadDirectory}/cache"; $wgShowIPinHeader = false;//because html result of page is cached
It doesn't need to be *file* caching. Using memcached could work pretty much as well. Use a bytecode cache.
On Thu, Aug 20, 2009 at 7:11 PM, Platonides Platonides@gmail.com wrote:
Sylvain Machefert escribió:
Hi!Just a few ideas. Maybe you could
- enable the file caching for non logged visitors $wgMainCacheType = CACHE_NONE; $wgMemCachedServers = array(); $wgUseFileCache = true; $wgFileCacheDirectory = "{$wgUploadDirectory}/cache"; $wgShowIPinHeader = false;//because html result of page is cached
It doesn't need to be *file* caching. Using memcached could work pretty much as well. Use a bytecode cache.
Memcached is entirely out of the question in most shared hosting
environments. Setting up eAccelerator or APC may be possible if you can get uncrippled shell access. http://www.mediawiki.org/wiki/User:Aaron_Schulz/How_to_make_MediaWiki_fastis a good guide to improving MediaWiki's performance, though the most important part (the bytecode cache) depends on your host offering the right tools. Keep in mind that your options aren't just shared hosting and dedicated hosting; there are reasonable VPSes available for $15-20 (though not through Lunarpages).
I've implemented the file caching for now. Being that I have a lot more browsing visitors than editors, I think that should make a noticeable difference. I'm going to keep an eye on the situation and see if that makes a dent. If not I'll have to look into the other solutions and see which I could carry out in the shared host environment. Shell access is available but costs a little extra, and the list of functions disabled are located here http://wiki.lunarpages.com/Disabled_JailShell_Commands
FYI, the extensions I'm using are Cite (Version r47190) , ParserFunctions (Version 1.1.1), ConfirmEdit (Version r36959) w/ FancyCaptcha.
Thanks for all the suggestions so far, I've learned a lot.
Francesco Petracca wrote:
I've implemented the file caching for now. Being that I have a lot more browsing visitors than editors, I think that should make a noticeable difference. I'm going to keep an eye on the situation and see if that makes a dent. If not I'll have to look into the other solutions and see which I could carry out in the shared host environment. Shell access is available but costs a little extra, and the list of functions disabled are located here http://wiki.lunarpages.com/Disabled_JailShell_Commands
The only command you may miss from that list is 'make', in case you need to compile something. In that case you may have more luck compiling on a system similar enough and copying the binary. And if you're going to be copying binaries, you may not need shell.
Hi Francesco Petracca, you are indeed lucky to have Lunarpages as your webhost. They didn't kick you out like what Maiahost did to me when they claimed that I exceeded their 1.5% CPU usage limit for my Maiahost Multiple Plan.
I was in the midst of writing an article when my website was suddenly suspended. I immediately contacted Online Chat Help and was told that I touched 2.6% CPU limit. I then contacted Technical Support and they said I touched 10%! When I asked for proof because of the discrepancy (2.6% vs 10%), they said they will give me in a few days time. Maybe they need to adjust something or discuss how to explain away the discrepancy, LOL.
I disabled Dummipedia.org, my biggest website, and offered to disable some smaller ones, too, but they insisted that I MUST upgrade to VDS or get lost. I asked them whether it is true that once you touch 1.5%, there is no turning back, even if I disabled some of my websites and they just said: "We don't want you here."
And the big joke is I don't even have a total of 500 visitors a day for all my websites added together. Remember I bought a Maiahost Multiple Plan, not a Single Plan. My monthly bandwidth transfer was only 5% of the advertised allocation of 50G (ie. 2,352MB) and I was using Mediawiki Version 1.14, not 1.15.
So Mediawiki users, beware who you choose to host for your websites. Lunarpages does indeed sound like a very good webhost.
PM Poon
On Mon, Aug 24, 2009 at 9:50 PM, Platonides Platonides@gmail.com wrote:
Francesco Petracca wrote:
I've implemented the file caching for now. Being that I have a lot more browsing visitors than editors, I think that should make a noticeable difference. I'm going to keep an eye on the situation and see if that makes a dent. If not I'll have to look into the other solutions and see which I could carry out in the shared host environment. Shell access is available but costs a little extra, and the list of functions disabled are located here http://wiki.lunarpages.com/Disabled_JailShell_Commands
The only command you may miss from that list is 'make', in case you need to compile something. In that case you may have more luck compiling on a system similar enough and copying the binary. And if you're going to be copying binaries, you may not need shell.
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Hi Francesco, you don't have to go for VDS yet. Just go for GoDaddy's Unlimited Plan for US$14.99 (see if you can get a discount coupon somewhere but don't go through resellers). I forgot to look for discount coupon and I paid the full sum, LOL. You can also try Hostgator but I keep hearing about hitting the inode limit or something. GoDaddy is not the perfect host, but at least you don't have to close down your website. Not much technical support (including no help in transferring your website) but they have a lot of reference materials so I hardly contact them. In any case, with Mediawiki, most webhosts do not provide any technical support, always telling the same old story... "this is third-party software and we don't provide any technical support".
PM Poon
On Tue, Aug 25, 2009 at 1:59 AM, Ekompute .info ekompute@gmail.com wrote:
Hi Francesco Petracca, you are indeed lucky to have Lunarpages as your webhost. They didn't kick you out like what Maiahost did to me when they claimed that I exceeded their 1.5% CPU usage limit for my Maiahost Multiple Plan.
I was in the midst of writing an article when my website was suddenly suspended. I immediately contacted Online Chat Help and was told that I touched 2.6% CPU limit. I then contacted Technical Support and they said I touched 10%! When I asked for proof because of the discrepancy (2.6% vs 10%), they said they will give me in a few days time. Maybe they need to adjust something or discuss how to explain away the discrepancy, LOL.
I disabled Dummipedia.org, my biggest website, and offered to disable some smaller ones, too, but they insisted that I MUST upgrade to VDS or get lost. I asked them whether it is true that once you touch 1.5%, there is no turning back, even if I disabled some of my websites and they just said: "We don't want you here."
And the big joke is I don't even have a total of 500 visitors a day for all my websites added together. Remember I bought a Maiahost Multiple Plan, not a Single Plan. My monthly bandwidth transfer was only 5% of the advertised allocation of 50G (ie. 2,352MB) and I was using Mediawiki Version 1.14, not 1.15.
So Mediawiki users, beware who you choose to host for your websites. Lunarpages does indeed sound like a very good webhost.
PM Poon
On Mon, Aug 24, 2009 at 9:50 PM, Platonides Platonides@gmail.com wrote:
Francesco Petracca wrote:
I've implemented the file caching for now. Being that I have a lot more browsing visitors than editors, I think that should make a noticeable difference. I'm going to keep an eye on the situation and see if that makes a dent. If not I'll have to look into the other solutions and see which I could carry out in the shared host environment. Shell access is available but costs a little extra, and the list of functions disabled are located here http://wiki.lunarpages.com/Disabled_JailShell_Commands
The only command you may miss from that list is 'make', in case you need to compile something. In that case you may have more luck compiling on a system similar enough and copying the binary. And if you're going to be copying binaries, you may not need shell.
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
-- PM Poon
- http://dummipedia.org The 5-Minute Concise Encyclopedia
- http://dummipedia.com The Dummipedia Amazon Online Store
mediawiki-l@lists.wikimedia.org