[collectd] Can small writes generate a lot of faults?

[Gaurav Jain]

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 at 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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 
Gaurav Jain
Associate Software Engineer
VxVM Escalations Team, SAMG
Symantec Software India Pvt. Ltd.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.verplant.org/pipermail/collectd/attachments/20130421/082766fc/attachment.html>