Can small writes generate a lot of faults?

Can small writes generate a lot of faults?

[Daniel Hilst Selli]

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

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@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://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130421/082766fc/attachment.html 

Can small writes generate a lot of faults?

[Mulyadi Santosa]

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

Can small writes generate a lot of faults?

[Greg Freemyer]

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.

Can small writes generate a lot of faults?

[Daniel Hilst Selli]

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!

[rrd-users] Can small writes generate a lot of faults?

[Daniel Hilst Selli]

Em 20/04/2013 09:09, Tobi Oetiker escreveu:
> hi daniel
>
> On 19.04.2013, at 16:42, 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, ... !?
>>
> rrdtool changes just few bytes in the rrf file with each update
>
> the OS though can only write a complete block of data to disk.
>
> so when you write a byte to a file, the OS has to first fetch the block, modify the byte and write the block back
>
> that is why rrdtool benefits greatly from more RAM as it can hold mor blocks in RAM and does not have to read them first.
>
> cheers tobi
>
Thanks Tobi, I had no idea about this read/update/write process, Now I 
know how to improve the performance of my
collectd+rrdtool stuff,

Cheers