Debian box slowing down

oscarBravo

Strange problem with my home server. It very frequently responds sluggishly to client requests, whether it's imapd, apache or leafnode. I kinda sorta suspect an imminent disk failure, but I don't know how to check it.

For example, every so often when I request a web page from it (almost all of which are PHP, and generated from a MySQL database), it takes several seconds before the page starts to load (the browser says "waiting for debby..."). When reading mail in Evolution, it can sometimes take 10 seconds or more for the body of a message to be shown. This is especially true when fetchmail is simultaneously attempting to deliver mail, but it happens in between as well.

I've watched top on the server while these delays are happening. With the Evolution example, imapd will take up to 75% CPU for the duration of the delay.

Syslog tells me nothing. Any thoughts?

Typedef

That's what you get for using Debian.

*grin*


Try doing a top and see if any process is eating ram.

Maybe, it's a case of your SQL Server or Webserver hitting into swap space.

If in doubt, give the box more RAM or install a 'real' OS, like Gentoo.

oscarBravo

Originally posted by Typedef
That's what you get for using Debian.

*grin*

Yeah, yeah...

Try doing a top and see if any process is eating ram.

Maybe, it's a case of your SQL Server or Webserver hitting into swap space.

Nothing specific eating RAM as such, but definitely well into swap space to the tune of 40MB. I've killed off a few non-essential processes - I'll see how it affects performance.

If in doubt, give the box more RAM or install a 'real' OS, like Gentoo.

The RAM option is the more tempting - I don't fancy waiting until I grow old for a K6-2/450 to compile Gentoo.

dredg

Originally posted by Typedef
That's what you get for using Debian.

*grin*


Try doing a top and see if any process is eating ram.

Maybe, it's a case of your SQL Server or Webserver hitting into swap space.

If in doubt, give the box more RAM or install a 'real' OS, like Gentoo.

helpful. not bad, idiot.

dredg

Originally posted by oscarBravo
I've watched top on the server while these delays are happening. With the Evolution example, imapd will take up to 75% CPU for the duration of the delay.
[/B]

Is this while evolution is doing anything, or is imapd doing this anyway?
try tail'ing /var/log/mail.* while the delay is there. if imapd is eating cpu, i would imaging its doing something.
any pattern in the times? could it be a cron job or something (i dunno uw-imap tbh, it could be setup to do anything)

oscarBravo

imapd only uses CPU when it's doin' stuff, so that seems OK. Besides, it wasn't just imap - I've seen leafnode doing the same thing when downloading news headers.

It seems to have been a swap issue. I've killed a few servers I didn't need, and it's improved a lot. I'll try to figure out what kind of RAM it needs and bung another 128 in there.

leeroybrown

Keep an eye on the load averages. If your load averages are high when you are experiencing these problems then identify the cause of the load. If the load isn't high then it's obviously a problem with that specific activity. Perhaps try changing the relevant config files to log at debug level.

If you think that your drives may be failing then run badblocks (non-destructive) on them to check them and mark possible bad sectors. You could also try one of the manufacturers drive test tools to check for problems with the drive.

Check that DMA si enambled with hdparm (hdparm -i /dev/device). You could also test the throughput with hdparm (hdparm -tT /dev/device).

Typedef

Originally posted by dredg
(i dunno uw-imap tbh, it could be setup to do anything)

Case and point.

Debian trolls can't even spell.


cat /proc/dreg/clue
cat: /proc/dregd/clue: No such file or directory

*grin*

Meanwhile :

If it's a Server, you probably shoudlnt' be running things like X, Gnome/KDE, Evolution and friends, basically because they eat RAM.

oscarBravo

Originally posted by leeroybrown
If you think that your drives may be failing then run badblocks (non-destructive) on them to check them and mark possible bad sectors.

Thanks for that - running "badblocks -nvs" as we speak (so far so good).

You could also try one of the manufacturers drive test tools to check for problems with the drive.

Um, what manufacturer? This is an old K6-2 with 128MB RAM and a 4GB disk - not a Dell PowerEdge or anything.

Check that DMA si enambled with hdparm (hdparm -i /dev/device). You could also test the throughput with hdparm (hdparm -tT /dev/device).

I've explicitly disabled DMA, as when it's enabled I get continuous errors being logged:

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

These repeat dozens of times, with an occasional

ide0: reset: success

until I disable DMA. I've never been able to find out exactly what it means.

oscarBravo

Originally posted by Typedef
Case and point.

Debian trolls can't even spell.

Case in point. Gentoo trolls have bad grammar

If it's a Server, you probably shoudlnt' be running things like X, Gnome/KDE, Evolution and friends, basically because they eat RAM.

I'm not - Evolution is running on my desktop. The server has X libraries installed, but it's not running X. No process is using more than 4MB of virtual memory, according to top.

leeroybrown

Um, what manufacturer?

The HDD Manufacturer! Most hard disk manufacturers have tools that support their products. I'd be surprised if they didn't include support for Legacy products there too.

UltimateBootCD has a lot of them on it. There are also links to most HDD manufacturers support tools on the page too if you fancy a smaller download. I've used IBM's DFT before and it's quite good (unlike the drive in question ).

Also, have you looked into the reason why your particular Chipset has problems with DMA.? If you havn't looked into it, then it might be worth the hassle considering the considerable improvement DMA would bring about.

Typedef

Whatever man

hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

That'd be it then.

A hard disk which isn't running with dma turned on, when 'swapping' will be really slow.

Swapping is bad enough, when it's done on a proper server, with real hardware, forget about performance if you're hitting swap on a non-dma disk.

<insert place where oscarBravo's server comes to a grinding halt>

More RAM, fixes this problem.
Lots more.

leeroybrown

I've seen a single large file transfer onto the system disk of a lightly loaded (~ 1) server take the load average past 15. That was with DMA running poorly. Factor in a disk running PIO and things would be much much worse.

Fix DMA and you fix the problem. If you're running a stock Debian kernel maybe theres a setting or bugfix that isn't enabled for your particular chipset.

oscarBravo

Originally posted by leeroybrown
The HDD Manufacturer! Most hard disk manufacturers have tools that support their products. I'd be surprised if they didn't include support for Legacy products there too.

OK - it's a cheap-ass Seagate Medalist 4.3G disk - downloading Seagate's diagnostic tools now.

Also, have you looked into the reason why your particular Chipset has problems with DMA.? If you havn't looked into it, then it might be worth the hassle considering the considerable improvement DMA would bring about.

I've googled, but I can't turn up anything that seems particularly relevant. The driver is ALI15X3, which seems to have had its share of problems, but none seem to be the same as mine. I've been thinking about building a new server - maybe it's time to up the priority on that project.

leeroybrown

In 2.4.x:

ATA/IDE/MFM/RLL support --->
IDE, ATA and ATAPI Block devices --->
ALI M15x3 chipset support

Compile a kernel with that enabled. There probably isn't any precompiled kernel package with that option enabled.

Taken from the help for that config option (for 2.4.25)

---

CONFIG_BLK_DEV_ALI15X3:

This driver ensures (U)DMA support for ALI 1533, 1543 and 1543C onboard chipsets. It also tests for Simplex mode and enables normal dual channel support.

If you say Y here, you also need to say Y to "Use DMA by default when available", above. Please read the comments at the top of drivers/ide/pci/alim15x3.c.

---