Help me have a productive dialog with support


#1

Not sure if this belongs in “third party” or “general troubleshooting”…

I have two expressionengine installs - one each in two different accounts, on one server fud, one on bitters. They are both at the same version level (1.6.4). Both have been running for years; both were updated to the most recent version a month ago (roughly). Other than posting entries to each, I have not done any system-level maintenance.

Within the last few days, one has started throwing page-render times of 150 - 250 seconds; the admin control panel renders in around 35-45 seconds. Long enough that the proxy at my work just gives up. Likewise my phone browser. The other site renders normally.

The render times on the slow one was so long I thought it had gone off-line. However I noted that a static html file loads quickly. I opened a help ticket and suggested it might be a MySQL or PHP problem. Support responded that they renamed my .htaccess file and the site loaded, so it was a coding problem on my end. I asked how an htaccess file that has worked for years could be the problem and if something had changed. They said nothing has changed and troubleshooting my code was out of scope. Of course it is - I agree.

As a side note, I notice no performance difference with or without the htaccess file. The site is so slow for me as to be effectively offline.

I’ve repaired and optimized all database tables (MySQL server grunt:mcadams).

I am asking here, what can I do to either troubleshoot an install that just fell over one day, or appropriately communicate the problem to support? I’m not sure how to politely and effectively respond to “it’s your code - sucks to be you.” I’ve been happily hosted here since 2002. I know a little, but not a lot. The problematic site is the members-only section of a dog club, but you should be able to at least load the “please log in” page:

http://members.ctca.us

For comparison, a similar but more normal site using the same EE version (but a different MySQL server):

http://www.crctc.org

Not sure how to proceed. Advice and suggestions welcome.

I’m in and out this weekend, so slow responses are not due to lack of appreciation! Thanks for any thoughts.


#2

Have you looked at the load of the server? You might want to log in via ssh ( http://wiki.dreamhost.com/Ssh ) and type the command “uptime”. And then post the results here.

Another thing you might want to do is get the number of requests the MySQL server is getting. You can also do that via ssh:
“mysqladmin -u YOURUSER -p -h YOURMYSQLHOST version” - that will give you some output, please also post that. You could also get that info via phpMyAdmin by logging in and clicking on “Show MySQL runtime information”. Then paste the query statistics part from that page, with queries total queries and queries per second and so.

Jan

Promo-Code: [color=#CC0000]SAVEMONEY97[/color] - Save [color=#CC0000]$50[/color] on your first year of hosting.
Get more promo codes here


#3

Nice tip on the SQL load. Out of curiosity, I ran it and got this:
Uptime: 9 days 15 hours 7 min 9 sec
Threads: 1 Questions: 85781308 Slow queries: 5632068 Opens: 1047870 Flush tables: 11 Open tables: 350 Queries per second avg: 103.099

This must be the total load on the SQL server, right? Not just my usage, but everybody’s?

-Scott


#4

Yes, it is the total number of queries by all users.

This interesting part: Queries per second avg: 103.099

Here is the MySQL server I’m on: Queries per second avg: 11.389

But this also depends on the hardware, I have seen servers running 200 queries a second without problems. But on all three MySQL servers I’ve been on here at DH had around 10-20 queries/second.

I might think that you MySQL server is overloaded. Maybe you can ask DH to move you to a new MySQL server.

EDIT: Oh, you’re not the original poster. But anyway, the number of queries on the server is relatively high.

Jan

Promo-Code: [color=#CC0000]SAVEMONEY97[/color] - Save [color=#CC0000]$50[/color] on your first year of hosting.
Get more promo codes here


#5

Thanks zylox. Here’s what I get from mysql:

Threads: 4 Questions: 15420031
Slow queries: 2087701
Opens: 178308
Flush tables: 38
Open tables: 350
Queries per second avg: 4.833

When I run top on ‘fud’, the load is around 1.5 and holding.


#6

Hm. The load on the web server and the queries on MySQL Database appear completely fine to me. I don’t you have a problem on that end but I can confirm the slowness of you site however.

Can you please check the values of the “max connections” and “max user connections” settings in phpMyAdmin? You can find the link “Show MySQL system variables” at the same place you found the “Show MySQL runtime information” link. And then check “Show MySQL runtime information” again and look for the “max. concurrent connections” on that page (at the top). If that value is lower than both of the “max connections” setting it’s fine and the problem is something different.

In the past I had problems with slow websites when the max connections where set to a low value. Then the server resources where fine, but the MySQL server was blocking incoming connections because of a low value setting in the configuration. That way all new incoming connections have to wait for connections to become free again which can cause a significant delay in page load time.

Jan

Promo-Code: [color=#CC0000]SAVEMONEY97[/color] - Save [color=#CC0000]$50[/color] on your first year of hosting.
Get more promo codes here


#7

Thanks. Max User = 300. Max Concurrent = 84.

If it matters, the previously mentioned load value (1.5) was for the webserver - not sure exactly how to get the equivalent value for the MySQL server. None of the login combos I’ve tried let me log onto ‘grunt.’


#8

If you’re absolutely positive it’s not your code causing the sluggishness, I’d be inclined to install something else alongside the troublesome site that uses the same database to see if that software performs just as poorly. If it does, that would be indication of a server > SQL connection issue.

You might create a fresh database on the other SQL server (that’s performing well), dump your tables into it, and have the troublesome site use the new SQL location. If performance returns to normal you will be able to tell Support that it is definitely a problem with that particular SQL connection. If there is no performance difference then you’ll need to go back and recheck your code - possibly doing a compare with your ‘good’ site, assuming they’re using the same core software and updates/plugins.

Maximum Cash Discount on any plan with MAXCASH


#9

Those are very good ideas. I’m not exactly sure how I’ll go about trying it without busting something, but I may have to figure it out if this continues.

I’m reasonably sure it’s not my code - the back end control panel takes like 35 seconds to load every time, and that’s nothing I had or have anything to do with. I know everyone says this, but … it was working fine last week, etc., etc. Posting two short articles (ironically, death notices) through the standard application interface in the usual way should not be taking down both the site and it’s admin panel.


#10

as sXi said, dump the db and load it up to the other server and switch the site over to use that sql server. it’s the only way i can see you being able to test it to clearly say that the mysql is the issue and having DH figure it out without it becoming a “3rd party script” response.

–John V

As a Side note, my sql sql server is showing 56 queries a second.


#11

I will try that. Hopefully one mysql hostname is as good as another. The other site is a different account and domain - I guess I’ll find out if anything chokes on that arrangement.


#12

Created a new subdomain. Added a new empty database to the MySQL hostname. Did a fresh install of EE into the subdomain using the new db on grunt. 35 seconds to load the control panel. The index page never loads.

I get errors like these in the apache logs on both the fresh install and the one that has been up for about five years (or for a month, since the newest update). Yes, I know everyone swears they haven’t changed a thing…

[Sat Aug 23 20:44:06 2008] [error] mod_gzip: TRANSMIT_ERROR:104
[Sat Aug 23 20:44:34 2008] [error] mod_gzip: TRANSMIT_ERROR:104
[Sat Aug 23 20:44:34 2008] [error] mod_gzip: TRANSMIT_ERROR:104
[Sat Aug 23 20:45:19 2008] [error] [client 69.181.99.174] Premature end of script headers: /dh/cgi-system/php5.cgi
[Sat Aug 23 20:45:19 2008] [error] [client ***] File does not exist: /home/user/members.ctca.us/internal_error.html
[Sat Aug 23 20:45:20 2008] [error] [client ***] File does not exist: /home/user/members.ctca.us/missing.html
[Sat Aug 23 21:40:09 2008] [error] mod_gzip: TRANSMIT_ERROR:104

(I have the gzip turned off for this site and every other site hosted on DH, for fear of the CPU police.)

One major difference that I notice - ‘fud’ site runs PHP5 as CGI. My fast site on ‘bitters’ runs PHP4 as mod_php. I had to switch the “fud” site to PHP5 after it began throwing PHP errors galore a year or so ago (again, out of the blue). It has been fine ALL THIS TIME, up until the middle of last week.


#13

I’d be inclined to setup your own custom php.

http://php526.dreamhosters.com

Maximum Cash Discount on any plan with MAXCASH


#14

He could try that, but that is not the best solution.

If it was a PHP problem, meaning the php install, then other customers would also have the problem and DH would need to fix the install.

I would send those error messages to DH and tell them that you are running a fresh install and already it isn’t working.

You could also create a subdomain on bitters using PHP5 and just see if EE runs fine on bitters with PHP5. I don’t know why EE wouldn’t run on PHP5.

Jan

Promo-Code: [color=#CC0000]SAVEMONEY97[/color] - Save [color=#CC0000]$50[/color] on your first year of hosting.
Get more promo codes here


#15

What peeves me is that the site has been running normally on PHP5 since September 19, 2007 ( I checked).

When I have time later today I will repeat a fresh install on bitters.


#16

Do you have the commercial version or are you using the Core version? If you have the paid-for version of EE they should give you support.

Jan

Promo-Code: [color=#CC0000]SAVEMONEY97[/color] - Save [color=#CC0000]$50[/color] on your first year of hosting.
Get more promo codes here


#17

I would be inclined to customise php first due to the fact that the php environment appears to have been the source of trouble in previous hiccups. Leaving dependancies on others to control is not a good idea imho. Some software sets itself up after testing what is allowed within the environment. If that environment changes things can, and do, go wrong.

That would be correct if every customer was running that exact same script.

Support have already indicated there are no known issues and haggis has maintained the core hasn’t changed. It’s up to haggis to now put everything possible in his own control. Obviously the server is turned on, Apache is running, and the database is connected (or users, as you noted, would be screaming). PHP is apparently giving errors particular to this software on one server and in my mind it would be prudent to setup a local environment that you’re 100% positive meets the software’s requirements before continuing with troubleshooting.

Maximum Cash Discount on any plan with MAXCASH


#18

I have the commercial version and EE is as usual giving me good effort in trying to figure out what’s going on.

I’m not up for maintaining my own php - that’s what paid hosting is for.

EE is not some sketchy script and it bloody worked last week. DH support wants or needs a more specific complaint than page render times are through the roof. I’m trying to work my way through some of the possibilities while trying not to accidentally bork the site which still works correctly, albeit agonizingly, absurdly slowly.


#19

PHP requires zero maintenance unless a major security hole is discovered.

Maximum Cash Discount on any plan with MAXCASH


#20

Some progress is being made thanks to EE. Processing hangs during page caching. Caching was obviously possible previously, but seems suboptimal now (unless waiting 250 seconds for a page to come up seems reasonable).