[plug] R52 ThinkPad - pdflush on large disk operations

Carl Gherardi carl.gherardi at gmail.com
Wed Sep 14 17:37:19 WST 2005


> 
> 
> split -b600m latte.tar.bz2 latte.tar.part-
> 
> And the file latte.tar.bz2 is the 8.6Gb file.
> 
> 
> The behaviour I saw was that cron was forking all over the place, the
> machine getting slower and slower. At one stage I had 86 cron processes
> running which couldn't be killed. (You should know that I have two cron 
> jobs that run each minute to log traffic and current active window -
> part of my client billing process.)
> 
> The other set of processes running was a whole bunch of pdflush instances.


Sounds like you are running out of disk.

Is the cron job running at a lower priority than split? If so you are 
possibly starving the write process in cron

> 
> Several hours later I tried the split again and within a minute a whole
> lot of pdflush processes, killing the split removed the pdflush.
> 
> What I think is happening is that the cron jobs are trying to write to 
> disk, they get blocked and the pdflush is really what is blocking the
> whole lot.




Actual questions:
> 
> What is really happening? What can I do to address this? What google
> terms should I use? Has anyone else seen this type of behaviour?


pdflush is a kernel write operation, the only times i've heard of it 
misbehaving were
- corrupt/hardware faulting disks, repeatedly attempting to sync data to dud 
areas (usually in combination with OOM and the dead part being in swap)
- network file systems - streaming transfers to nfs or samba
- OOM type thrashing.

The only time its happened to me was a dying disk.

Hope that helps.

Carl G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plug.org.au/pipermail/plug/attachments/20050914/7259bb18/attachment.html>


More information about the plug mailing list