Excessive PHP Load with 4.5.1

rez · 21.02.2005, 19:36

hi

I have been a very happy user of mambo for well over a year. I recently upgraded from 4.5_109 to 4.5.1a and then to the b patch.

The other week I got an email from my ISP (Lunarpages) that my server had an "excessive load" and my site was moved to another box to prevent it impacting other servers.

Short version:

apparently php load % was around 99% which is very high. There is no way to get info on the specific script that was running.

I took down one of my 2 mambo sites, I also took down both menalto gallery php sites. This left my main mambo site running. The load remained high.

I shut down as many components as possible. Profiled the database. The load remained high.

I shut down my main mambo site. The load went down.

I disabled as many components as I could and brought the site back up, but now the load is 38% which is not good.

I have just uninstalled RSgallery, akobook, akocomment, awesome, docman, simpleboard, pms, recommend and sitemap. disabled relevent modules and mambots. I now cross my fingers.

I changed as many perms as possible to 755 and 644 as needed (except config), and I hope for the best.

Has anyone seen this before? Any tips on diagnosing it? Is it possible for a "runaway" php script? Could a CGI runaway somehow affect php load?

Oh yes, and I checked the raw IP logs. Nothing really stands out. I cut the log so you only see IPs, sorted it and used uniq to get a count of IPs. I'm the second highest IP. The first is google, but the number for that has not gone up for 2 days so it is not the culprit.

Oddly, the overall site traffic has not changed, while the LOAD on php has.

I did a "check table" in phpadmin and after all the OKs, I got this:

Problems with indexes of table `mos_categories`
Warning More than one INDEX key was created for column `section`
Problems with indexes of table `mos_core_acl_aro`
Warning More than one UNIQUE key was created for column `section_value`
Warning More than one INDEX key was created for column `hidden`
Problems with indexes of table `mos_core_acl_aro_groups`
Warning More than one INDEX key was created for column `parent_id`
Problems with indexes of table `mos_core_acl_aro_sections`
Warning More than one UNIQUE key was created for column `value`
Warning More than one INDEX key was created for column `hidden`
Problems with indexes of table `mos_help`
Warning PRIMARY and INDEX keys should not both be set for column `id`
Warning More than one UNIQUE key was created for column `id`
Problems with indexes of table `mos_preferences`
Warning PRIMARY and INDEX keys should not both be set for column `preference_id`
Problems with indexes of table `mos_rsgallery`
Warning PRIMARY and INDEX keys should not both be set for column `id`
Problems with indexes of table `mos_rsgallery_comments`
Warning PRIMARY and INDEX keys should not both be set for column `id`
Problems with indexes of table `mos_rsgalleryfiles`
Warning PRIMARY and INDEX keys should not both be set for column `id`
Problems with indexes of table `mos_sb_attachments`
Warning More than one INDEX key was created for column `mesid`
Problems with indexes of table `mos_sb_messages`
Warning PRIMARY and INDEX keys should not both be set for column `id`
Problems with indexes of table `mos_sb_moderation`
Warning PRIMARY and INDEX keys should not both be set for column `catid`
Problems with indexes of table `mos_user_groups`
Warning PRIMARY and INDEX keys should not both be set for column `group_id`
Problems with indexes of table `mos_user_list`
Warning PRIMARY and INDEX keys should not both be set for column `user_id`

This can't be good. I'm useless at SQL. Could this be the cause? If so, how can I fix it?

My site is tvcentury21.com

thanks

Simon

colin99 · 21.02.2005, 19:51

All I have ever changed with vanilla mambo (out of the box)
is the way the poll functions. There is some (or was some)
needless overhead with the polls and how MySQL deals
with some of the mathematical tasks if the site is
really busy. I cannot remember what we did but it
is on mambers.com somewhere.

Other than that, we have over a dozen mambo sites
going full out on a BSD Unix ISP w/o any troubles.

Granted their servers are clustered and MySQL has
its own box.

walb · 21.02.2005, 19:59

Hmm.
Try a repair on the indicated tables with phpmyadmin? There seems to be something wrong with your indexes.
Are you using 404sef? There something with it. I did shut it off and use te standard one with all its pain.

rez · 21.02.2005, 20:22

I ran the repair and it says OK.

I also ran the analyse tool and same.

I run the check and I get these errors again. Are the tables supposed to be like that, or should I fix them? If so, how?

walb · 21.02.2005, 21:48

I've no clue! Plse someone else, join in.

jimhnet · 22.02.2005, 02:08

Has your ISP recently upgraded php to 5.0?

If not what version of php are you running?
Jim

rez · 22.02.2005, 03:29

PHP is 4.3.10 and I upgraded to mambo 4.5.2 today.

I just got a nastygram from the host telling me the load is getting higher...

totally perplexed...

jimhnet · 22.02.2005, 03:47

The problem seems to be that the index's are screwed up somehow, which would make the thing take forever(if it worked at all).

Did you optimize the tables in question?

If so I might be tempted to dump the database and do a restore.
That would probably reindex everything.

The other thing I would do is create a new site from scratch and compare the table keys and index's on a table by table basis, its obvious it doesn't like the index's or their definitions. Normally, I didn't think mysql would allow you create tables with index and key conflicts.

Jim

rez · 22.02.2005, 04:24

I ran both the repair and optimize commands, but get the same result.

I have 1900 users, which might have an impact.

I really don't know what I'm doing with sql, so should I backup the database and then create a new one and load up the back up? Or do I need to do something else?

...clueless in AZ.

jimhnet · 22.02.2005, 06:21

I hope the size is not an issue I'm about to put up site with 17,000+ members and a potential of 100,000 +(not for profit site)

If I were doing it I would go back to the other suggestion and do a clean install on another domain or a subdomain with no traffic. Then I would run the phpmyadmin checks after each section. Then do the addons you did in the same order, checking the mysql after each step. My guess is that one of the addons has played games with the db.

The other thing I would look to is my backups and find out from the ISP when the overload started.

Jim