Can small writes generate a lot of faults?
My case is this, I'm using collectd [1] with rrdtool [2] to monitor some server. a) When I enable rrdtool plugin I can grab collectd process as top page fault process on top command. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ nFLT COMMAND 20128 root 18 0 4105m 35m 17m S 7.9 0.3 0:09.62 22k /opt/collectd/sbin/collectd b) Disabling rrdtool plugin dramastically decrease the number of page faults of collectd. c) I know that rrdtool plugin is known to generate a lot of small writes, as stated in [3]. Also I know the parameters to improving collectd's cache usage to save I/O, but this is not the question here.. AFAIK, major page faults are generated when data that is not yet present on RAM is loaded from disk, but in this case data is being write do disk, I can't see how writes can generate faults, but still, it seems that is happening, ... !? Is that possible? Cheers, [1] http://www.collectd.org [2] http://oss.oetiker.ch/rrdtool/ [3] https://collectd.org/wiki/index.php/Inside_the_RRDtool_plugin
Page-faults by a process on writing OR reading are really not that different. In both cases, an attempt is made to read the physical address (corresponding to the virtual address) from the page-table BEFORE the *read *or *write *machine level instructions are executed. So, if the address to which writes (or reads) are being performed, does not have a valid page-table entry ie. a valid virtual address, a page-fault will be triggered. Best Regards Gaurav Jain On Fri, Apr 19, 2013 at 11:42 PM, Daniel Hilst Selli <danielhilst@gmail.com>wrote:
My case is this, I'm using collectd [1] with rrdtool [2] to monitor some server. a) When I enable rrdtool plugin I can grab collectd process as top page fault process on top command. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ nFLT COMMAND 20128 root 18 0 4105m 35m 17m S 7.9 0.3 0:09.62 22k /opt/collectd/sbin/collectd b) Disabling rrdtool plugin dramastically decrease the number of page faults of collectd. c) I know that rrdtool plugin is known to generate a lot of small writes, as stated in [3]. Also I know the parameters to improving collectd's cache usage to save I/O, but this is not the question here..
AFAIK, major page faults are generated when data that is not yet present on RAM is loaded from disk, but in this case data is being write do disk, I can't see how writes can generate faults, but still, it seems that is happening, ... !?
Is that possible?
Cheers,
[1] http://www.collectd.org [2] http://oss.oetiker.ch/rrdtool/ [3] https://collectd.org/wiki/index.php/Inside_the_RRDtool_plugin
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Gaurav Jain Associate Software Engineer VxVM Escalations Team, SAMG Symantec Software India Pvt. Ltd.
Hi :) On Sat, Apr 20, 2013 at 4:42 AM, Daniel Hilst Selli <danielhilst@gmail.com> wrote:
AFAIK, major page faults are generated when data that is not yet present on RAM is loaded from disk, but in this case data is being write do disk, I can't see how writes can generate faults, but still, it seems that is happening, ... !?
Is that possible?
I never pay close attention on these kind of stuffs, but IMHO there is a chance that this "write" is actually "update". So it is kind of "read data- update data - flush data" cycle. Close enough to graph generation behaviour, don't you think... CMIIW... -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
Hi :)
On Sat, Apr 20, 2013 at 4:42 AM, Daniel Hilst Selli <danielhilst@gmail.com> wrote:
AFAIK, major page faults are generated when data that is not yet present on RAM is loaded from disk, but in this case data is being write do disk, I can't see how writes can generate faults, but still, it seems that is happening, ... !?
Is that possible?
I never pay close attention on these kind of stuffs, but IMHO there is a chance that this "write" is actually "update"
I missed the original email, but the kernel filesystem logic typically works with 4 KB pages. If a write lands on page boundaries then the file system will do pure writes, but if it doesn't then the filesystem will typically read the original page from disk then update it and write it back out. Small writes of 4 kb as an example that are not page aligned will cause 2 pages to read, both to be updated and both to be written. Adding raid 5/6 below the file system layer greatly accelerates the problem. Now you need to ensure your writes are the full size of a stripe and stripe aligned to avoid the read/update/write sequence. Some filesystems build knowledge of stripes into them to try and optimize this process, some don't. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Em 22/04/2013 10:20, Greg Freemyer escreveu:
Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
Hi :)
On Sat, Apr 20, 2013 at 4:42 AM, Daniel Hilst Selli <danielhilst@gmail.com> wrote:
AFAIK, major page faults are generated when data that is not yet present on RAM is loaded from disk, but in this case data is being write do disk, I can't see how writes can generate faults, but still, it seems that is happening, ... !?
Is that possible? I never pay close attention on these kind of stuffs, but IMHO there is a chance that this "write" is actually "update" I missed the original email, but the kernel filesystem logic typically works with 4 KB pages. If a write lands on page boundaries then the file system will do pure writes, but if it doesn't then the filesystem will typically read the original page from disk then update it and write it back out.
Small writes of 4 kb as an example that are not page aligned will cause 2 pages to read, both to be updated and both to be written.
Adding raid 5/6 below the file system layer greatly accelerates the problem. Now you need to ensure your writes are the full size of a stripe and stripe aligned to avoid the read/update/write sequence. Some filesystems build knowledge of stripes into them to try and optimize this process, some don't.
Greg
Thanks for your answer Greg, I have never been presented to this "read/update/write" logic, now makes a lot of sens, Thanks!
participants (4)
-
Daniel Hilst Selli -
Gaurav Jain -
Greg Freemyer -
Mulyadi Santosa