Jump to content

OVH shared hosting inadequate for ProcessWire


Beluga
 Share

Recommended Posts

So my site is completely unusable now for 4 days straight. Intermittent crashes have happened all the time since January.
 
I might get nearly 300 error emails in one go.
 

Page: http://sitename.fi/?/
User: ?

Error:
Exception: SQLSTATE[42000] [1203] User sitename already has more than 'max_user_connections' active connections (in /home/sitename/www/wire/core/ProcessWire.php line 216)

#0 /home/sitename/www/wire/core/ProcessWire.php(94): ProcessWire->load(Object(Config))
#1 /home/sitename/www/index.php(232): ProcessWire->__construct(Object(Config))
#2 {main}

OVH told me max_user_connections cannot be raised.

I also got these related to Page Image Manipulator module:

Error:
Maximum execution time of 1200 seconds exceeded (line 157 of /home/sitename/www/wire/core/Pageimage.php)

and
 

SQLSTATE[HY000]: General error: 2006 MySQL server has gone away (in
/wire/core/Pages.php line 2103)

 
One tip on the PW forum was to raise the MySQL max_allowed_packet value, even up to 32M, but OVH told me it is 1M and cannot be changed.

No OVH shared plan helps with these limits.

I've been trying to get a hold of the cheapest dedicated Kimsufi servers: https://www.kimsufi.com/

They are very hard to get as supply does not meet demand. Hopefully this will improve my chances: https://github.com/MA3STR0/kimsufi-crawler

I read some have even written bots to automate the purchase. I'm afraid I can't beat that..

Link to comment
Share on other sites

Any reason, why you need a server to run this site? ProcessWire should normally run fine on most shared hostings as well.

The reason is those errors and how it is crashing all the time.

It is a very normal site and not much visitors, as it is restricted to (genealogical) family members.

I have a menu done with this technique: https://processwire.com/talk/topic/10448-css-only-responsive-multi-level-menu/

It has 4 levels maximum.

The menu and page image manipulator are the most demanding tasks I guess.. but the host falls on its face.

Link to comment
Share on other sites

Do you have the basic hosting account for just €2 ? Sorry, but I really don't know how these companies even make money anymore with such prices...

Only allowing 30 max_user_connections and 1M max_allowed_packet is really low.

But you certainly don't need dedicated hosting to run PW smoothly.

Link to comment
Share on other sites

Do you have the basic hosting account for just €2 ? Sorry, but I really don't know how these companies even make money anymore with such prices...

Only allowing 30 max_user_connections and 1M max_allowed_packet is really low.

But you certainly don't need dedicated hosting to run PW smoothly.

For 3 euros, yes, but the limits are the same in ALL of their shared hosting offerings.

Visitors are only a handful of people maximum at the same time. But now it has been completely inaccessible for me for 4 days. Even the webtrees install (genealogical db)! So something is wrong with their system.

OVH is fine otherwise and I would like to stay with them, but their shared hosting limits obviously do not mesh with PW.

I ran the command

show status like '%onn%';

in phpMyAdmin and got this:

Aborted_connects     66404
Connections     49920995
Max_used_connections     286
Ssl_client_connects     0
Ssl_connect_renegotiates     0
Ssl_finished_connects     0
Threads_connected     7
Link to comment
Share on other sites

MySQL "gone away" often happens when you hit your memory cap (ram and swap combined), mysql will crash, that can happen when you are being crawled which appears to be the case. 

Do you have caching enabled on your pages? 1200s queries are not normal, I would make sure all your files permissions are ok first then investigate further. It seems to me like you are resizing/rendering a lot of stuff on the fly and maxing out your cpu allowance. 

Link to comment
Share on other sites

MySQL "gone away" often happens when you hit your memory cap (ram and swap combined), mysql will crash, that can happen when you are being crawled which appears to be the case. 

Do you have caching enabled on your pages? 1200s queries are not normal, I would make sure all your files permissions are ok first then investigate further. It seems to me like you are resizing/rendering a lot of stuff on the fly and maxing out your cpu allowance. 

It can't be crawled as there is a .htaccess password protection in place.

I can't check the caching currently as I cannot enter the site or admin at all (since Feb 25th).

Image resizing happens with Page Image Manipulator, but if copies have been rendered to disk, it will skip those, right? This is how it seems to have worked based on the file creation dates.

It can't be all because of PIM, as even direct admin access has failed many times since January. Front page does not have images to resize and same phenomenon has happened with it. New image uploads are rare.

Link to comment
Share on other sites

It can't be crawled as there is a .htaccess password protection in place.

There is the possibility that the website can still be hit with many requests, which would keep you from even accessing the site or admin (if known).  The .htaccess is good to have, however it will not keep someone from flooding your site with many requests (bogus or otherwise).

Link to comment
Share on other sites

It will unless the permissions are broken and it's not reading/writing correctly.

Now I checked with FTP and to my dismay, there are freshly generated -pim2 versions in the assets!

What should I be looking for regarding permissions? Images are 0644 and asset folders 0755.

Thanks for the insight. As you can guess, this has been a major pain in the butt for weeks.

That said, when I started using PIM and generated the files for a gallery, it already choked on the first run. So I think I have to get the Kimsufi in any case. It will also enable users to upload files larger than 60M without me having to do a workaround with PW API every time.

Link to comment
Share on other sites

What should I be looking for regarding permissions?

It's highly dependent on the server, if you're unsure, check with your sysadmin. On some systems, the user:group settings will also have big impact, on some not so much. Also in site/config.php, make sure your default permissions are correct, once you find the right settings. 

If your images are too big for the amount of memory you have available, the resize might die through the process.

Link to comment
Share on other sites

It's highly dependent on the server, if you're unsure, check with your sysadmin. On some systems, the user:group settings will also have big impact, on some not so much. Also in site/config.php, make sure your default permissions are correct, once you find the right settings. 

If your images are too big for the amount of memory you have available, the resize might die through the process.

So what is the mechanism that wrong permissions cause files to not be skipped?

The files that seemed to be in a processing loop were huge pngs (two files, 14.3M and 9.5M). It had done processing on them at 05:40 in the morning. I replaced them with jpgs. Now the problem seems to be gone.

However, images these days are big. I need the memory headroom so I will continue to try to get the Kimsufi server.

Link to comment
Share on other sites

Ok, it seems the images were not the only problem after all. Still crashing and with this:

Error:
Exception: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away (in /home/sitename/www/wire/core/Pages.php line 2103)

#0 /home/sitename/www/wire/core/Pages.php(2103): PDOStatement->execute()
#1 /home/sitename/www/wire/core/Pages.php(546): Pages->executeQuery(Object(PDOStatement))
#2 /home/sitename/www/wire/core/PagesType.php(260): Pages->getById(Array, Object(Template))
#3 /home/sitename/www/wire/core/Users.php(33): PagesType->get(1122)
#4 /home/sitename/www/wire/core/Session.php(102): Users->get(1122)
#5 /home/sitename/www/wire/core/ProcessWire.php(279): Session->__construct()
#6 /home/sitename/www/wire/core/ProcessWire.php(94): ProcessWire->load(Object(Config))
#7 /home/sitename/www/index.php(232): ProcessWire->__construct(Object(Config))
#8 {main}

and also the max_user_connections error.

I think the user was in the admin trying to expand some pages for editing, at least he said so to me.

Yet the big choking seems to be gone. I personally did not encounter any problems with quick testing.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...