Update3: The problem never stayed away, and got worse. I tried upgrading to Drupal 6.x, but our hosting has such an old version of MySQL that we can’t run Drupal 6.x. I then tried a fresh installation of Drupal 5.x, fetching the current version of every module we need, and enabling things gradually. So far, things are pointing at the search module again, but I only stopped the problems by deleting the search module and emptying all the search tables. Disabling the module didn’t stop lots of locked processes updating the search_index table. We’ll see how things go from here, then.
Update2: Running without the Image module didn’t fix it – it happened again. We now have the Image module enabled again, and a few other modules disabled. PathAuto is included in this lot, as I’ve heard it can have performance issues with a lot of paths (we have over 1,000). If things stay stable this way, I’ll probably try updating PathAuto to the latest version and enabling it again.
Update: This turned out not to be the case at all. The next batch of images I uploaded were ok, but the next after that caused the same locking problems without the search module running. I’m just going to abandon the image module for now, and maybe have another go when we upgrade to Drupal 6.x.
A GoogleFood post – there’s probably nothing of interest here, unless Google has brought you to this page when you’re trying to work out why Drupal keeps making your server crash, run very slowly, etc, after you’ve added a batch of images.
I think I’ve got to the bottom of this problem now, so I’ll post this in case it’s any help to anyone later.
I was using Drupal 5.x, with the Image module. I was importing images by uploading them using FTP, then using Image Import to grab them from there and add them to the site. When doing that, the first time you view the images after adding them, Drupal has to generate the various sized versions. I always went through viewing each image to let this happen, because it took a while, so I didn’t want visitors wondering why their browser was hanging if they happened to be the first to view an image.
At some point while doing this, the site would stop responding, and I found I couldn’t even stop/start MySQL through my host’s control panel. I had to log a call with them to get things going again. The first time, the database wasn’t working properly afterwards, and some repair was needed.
After a few more tries, I found that what was happening was that MySQL had a number of locked processes. The number of locked processes seemed to grow until it was too much for the server, and MySQL would stop responding. After a while, Apache usually died too.
From the look of it, it’s actually the Search module causing the problem when it tries to index the images. Generating the different sizes is a slow process, and can make things look like they’ve hung for a while, but nothing is locked, so it gets there eventually. Once I disabled the Search module, though, I could set lots of images off to generate sizes, without locking any tables. phpMyAdmin was good for troubleshooting – use Show Processes to see what’s going on. Try disabling the Search module, and see if the problem goes away.
We now have to decide if we can do without the Search module or the Image module. I think Search will probably be the one to go, replaced with a Google search box.