Which process is writing to disk?
in [Linux Help]
|
Prev: sshd failure
Next: Bad superblock
From: Sybren Stuvel on 12 Mar 2007 16:40 Snowbat enlightened us with: > I don't see a 'wait around for more input' option but there's always > script (writing to a different partition): > > #!/bin/bash > touch lsofdump1.txt > while true > do > lsof /dev/sda7 > lsofdump2.txt > diff lsofdump1.txt lsofdump2.txt > mv lsofdump2.txt lsofdump1.txt > done > exit 0 You might want to put a "sleep 5" in there, otherwise the data will be displayed for a fraction of a second. Sybren -- Sybren Stüvel Stüvel IT - http://www.stuvel.eu/
From: Rehceb Rotkiv on 12 Mar 2007 21:06 Thanks for your ideas! I didn't find anything significant with lsof and find, so I suspected it must be something "low level" that is causing the writes, and indeed it is, namely pdflush. I found that the value in /proc/ sys/vm/dirty_writeback_centisecs determines how often pdflush writes dirty data to the disk. Surprise, surprise: The default value was 500. Do you think it is safe to put a much higher value in here, like maybe 90000, so that the writes occur every 15 minutes?
From: Tommy Reynolds on 13 Mar 2007 21:37 On Mon, 12 Mar 2007 20:06:13 -0500, Rehceb Rotkiv wrote: > Thanks for your ideas! I didn't find anything significant with lsof and > find, so I suspected it must be something "low level" that is causing > the writes, and indeed it is, namely pdflush. Perhaps it would be safer to turn off the need for this periodic disk writing. You probably are seeing the kernel update the access time for every open file. See the "man 2 stat" documentation about the "st_atime" file statistic. Unless you have a burning desire to know that you last typed a keystroke 27 seconds ago (sorta like the "stat /dev/tty" command), you can safely turn this overhead off. In the "/etc/fstab", find the line that mounts each of your filesystems. Change the options from "default" to "noatime"; or add "noatime" to the options already there. Find out more about "/etc/fstab" using the "man 5 fstab" command. Now, remount each filesystem to whose line you added "noatime": # mount -o remount / for example. You can do this without rebooting. In fact, you can prove to yourself this is what's happening by remounting the filesystem without changing "/etc/fstab". It's will not be permanent until you change "/etc/fstab", so you can experiment by just doing: # mount -o remount,noatime / for each partition you have mounted. Adding the "noatime" option is common practice on many large servers. On a system with thousands of users each having hundreds of files open, this traffic to maintain the last access time can amount to a significant amount of disk traffic, all to maintain a statistic most users will never need. HTH
From: Rehceb Rotkiv on 14 Mar 2007 15:46 > You probably are seeing the kernel update the access time for every open > file. See the "man 2 stat" documentation about the "st_atime" file > statistic. > > Unless you have a burning desire to know that you last typed a keystroke > 27 seconds ago (sorta like the "stat /dev/tty" command), you can safely > turn this overhead off. In the "/etc/fstab", find the line that mounts > each of your filesystems. Change the options from "default" to > "noatime"; or add "noatime" to the options already there. Great, that's exactly what I needed, thanks! The atime update was indeed responsible for most cache writebacks, as they occur _much_ less frequently now that I use the noatime option for my filesystems. I couldn't find out how to mount /dev with noatime, though, as it is handled by udev and not in my fstab. "mount -o remount, noatime /dev" works according to /etc/mtab, but doesn't seem to have any effect, as atimes of the terminals are still updated. I tested it with /dev/pts/n. Any idea? Many thanks, Rehceb
From: Tommy Reynolds on 14 Mar 2007 21:53
On Wed, 14 Mar 2007 14:46:19 -0500, Rehceb Rotkiv wrote: > I > couldn't find out how to mount /dev with noatime, though, as it is > handled by udev and not in my fstab. "mount -o remount, noatime /dev" > works according to /etc/mtab, but doesn't seem to have any effect, as > atimes of the terminals are still updated. I tested it with /dev/pts/n. > Any idea? How do you have "/dev" mounted? (I haven't really looked.) UDEV may be treating it as a virtual filesystem, in memory only. HTH |