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
Quoted 32 lines · 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_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Signature · 7 lines
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
Hi :)
Quoted 7 lines · Daniel Hilst Selli
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...
Signature · 7 lines
regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Quoted 11 lines · Mulyadi Santosa
Hi :)
Quoted 1 line · Daniel Hilst Selli
AFAIK, major page faults are generated when data that is not yet
present
Quoted 5 lines
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, ... !?
Quoted 4 lines
Quoted 1 line
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
Signature · 1 line
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Em 22/04/2013 10:20, Greg Freemyer escreveu:
Quoted 17 lines
Quoted 6 lines · Mulyadi Santosa
Hi :)
Quoted 1 line · Daniel Hilst Selli
AFAIK, major page faults are generated when data that is not yet
present
Quoted 8 lines
Quoted 6 lines
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"
Quoted 10 lines
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!
A message that is not in the archive (sent off-list or not yet received): [email protected]
Em 20/04/2013 09:09, Tobi Oetiker escreveu:
Quoted 12 lines
hi daniel
Quoted 6 lines · Daniel Hilst Selli
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
Quoted 8 lines
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