- Timestamp:
-
Jun 14, 2007, 10:59:31 PM (15 years ago)
- Author:
-
oetiker
- Comment:
-
wording improved
Legend:
- Unmodified
- Added
- Removed
- Modified
-
v15
|
v16
|
|
15 | 15 | |
16 | 16 | The net effect is that in-memory updates are about twice as fast as before. |
17 | | My coreduo thnkpad was able todo 12k updates per second (in memory) with the |
| 17 | My CoreDuo Thinkpad was able to do 12k updates per second (in memory) with the |
18 | 18 | 1.2 code base while it is able to do 22k updates per second (in memory). |
19 | 19 | |
20 | 20 | Obviously RRD data has to go to disk eventually, there has not been all that much change, |
21 | | since the OS still has to write the blocks. My 5400 RPM Thinkpad HD continues to get about250 Updates |
22 | | to disk per second. |
| 21 | since the OS still has to write the blocks. My 5400 RPM Thinkpad HD continues to run at |
| 22 | about 250 RRD updates per second. |
23 | 23 | |
24 | | The interesting thing here is that we are telling the kernel that we will not read the whole RRDfile |
25 | | but just some blocks of it (random access). This helps optimize cache access and reduces disk IO. |
26 | | The main advantage of this is that the cache usage gets optimized. The number of RRDfiles |
| 24 | Since we are now telling the kernel that we will not read/write the whole RRD file |
| 25 | but just some blocks of it (random access) the disk access could be optimized and cache usage generally reduced. The number of RRD files |
27 | 26 | that can be kept in cache at any one time is 3 to 5 times as large in 1.3 as in 1.2. |
28 | 27 | |
|