[support] slow site: db problems

Bruno De Bondt bruno at indymedia.be
Fri Apr 6 15:12:45 UTC 2007


Hello,

> What does your php log contain?  I'm thinking a memory overflow issue.
>
> Earnie -- http://for-my-kids.com
>   

The php log doesn't contain anything about memory overflow. In case it
did, what would this mean? That php isn't allowed to use the memory it
needs?

I'm getting closer to a solution though.

Yesterday evening I 'rebuilt' our database on a test machine: installed
a fresh Drupal db, added the tables from the contrib modules we're
using, and imported our site's data. All seemed fine, i/o seemed ok.

This morning however, iowait was showing numbers of 70%, 80% again (*).
When I restarted mysql, it would drop to 0,0%. Wondering what might be
causing this, I disabled the modules to see the possible effect, but got
no result.

Then I thought of the other problem we're having: our search indexing is
broken. The search's settings page says it indexed 100% of the site,
while in fact it always stops somewhere for no apparent reason. When we
rebuild the index, search builds the index up to the point when it was
asked to re-index, and then it stops again. So we have to re-index
regularly to keep our index up to date.

Anyway, thinking furher about the indexing problem, I manually launched
cron.php when iowait was 0,...%. When I did this, iowait went up to 70%,
80% and stayed very high (+50%). Restarting mysql brought it down to
0,...% again.

So I'm thinking both problems may be connected: the broken search
indexing and cron.php that causes iowait to go way up - and causing it
to stay very high. We also see that there is a high load on mysql.

Could you think of a reason why this is happening? Or how I could look
for reasons? I disabled cron for now.

thanks,
-- bruno


(*) We recently moved our test site to a seperate machine, but there was
still a crontab on the live server pointing to the test domain, which is
why cron.php was called on the test site.



More information about the support mailing list