Beluga Posted February 28, 2016 Share Posted February 28, 2016 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 More sharing options...
LostKobrakai Posted February 28, 2016 Share Posted February 28, 2016 Any reason, why you need a server to run this site? ProcessWire should normally run fine on most shared hostings as well. Link to comment Share on other sites More sharing options...
Beluga Posted February 28, 2016 Author Share Posted February 28, 2016 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 More sharing options...
LostKobrakai Posted February 28, 2016 Share Posted February 28, 2016 Can you define "not much visitors" a bit more detailed. If there are only a handful of people on the site these errors would rather suggest there's something not right on your website instead of an issue with your host. Link to comment Share on other sites More sharing options...
dragan Posted February 28, 2016 Share Posted February 28, 2016 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 More sharing options...
Beluga Posted February 28, 2016 Author Share Posted February 28, 2016 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 More sharing options...
Pierre-Luc Posted February 28, 2016 Share Posted February 28, 2016 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 More sharing options...
Beluga Posted February 28, 2016 Author Share Posted February 28, 2016 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 More sharing options...
Pierre-Luc Posted February 28, 2016 Share Posted February 28, 2016 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 will unless the permissions are broken and it's not reading/writing correctly. Link to comment Share on other sites More sharing options...
cstevensjr Posted February 28, 2016 Share Posted February 28, 2016 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 More sharing options...
Beluga Posted February 28, 2016 Author Share Posted February 28, 2016 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 More sharing options...
Pierre-Luc Posted February 28, 2016 Share Posted February 28, 2016 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 More sharing options...
Beluga Posted February 29, 2016 Author Share Posted February 29, 2016 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 More sharing options...
LostKobrakai Posted February 29, 2016 Share Posted February 29, 2016 You could use https://github.com/blueimp/jQuery-File-Upload to upload the original file only for storage purposes (File field, otherwise the admin thumb will be generated) and an additional client side resized version, from which you then generate your needed thumbnails on a much lower overhead. Link to comment Share on other sites More sharing options...
Beluga Posted February 29, 2016 Author Share Posted February 29, 2016 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 More sharing options...
Pierre-Luc Posted February 29, 2016 Share Posted February 29, 2016 Next time you get this error, do "service mysql status" on the server terminal and see that it says. Link to comment Share on other sites More sharing options...
Beluga Posted February 29, 2016 Author Share Posted February 29, 2016 Next time you get this error, do "service mysql status" on the server terminal and see that it says. Unfortunately, the shared hosting does not support SSH access Another minus.. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now