[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