From: Rick L. <ric...@us...> - 2003-01-20 21:27:35
|
Rick was probably referring to the CPU caches. Right -- for scheduling purposes probably the disk caches aren't that important. We use a tool called "eatmem" to allocate all free memory a page at a time. This also has the effect of trashing the cache. I'll dig it up. Ok, thanks. I don't know if cold or warm cpu caches will make a difference either but would be interested in hearing if people have determined if they matter for this. Rick |
From: Cliff W. <cl...@os...> - 2003-01-20 21:47:49
|
> Rick was probably referring to the CPU caches. > > Right -- for scheduling purposes probably the disk caches aren't that > important. > > We use a tool called "eatmem" to allocate all free memory a page at a time. > This also has the effect of trashing the cache. > I'll dig it up. > > Ok, thanks. I don't know if cold or warm cpu caches will make a difference > either but would be interested in hearing if people have determined if > they matter for this. > > Rick > We always reboot - that's one of the primary advantages of STP for running tests. However, when we do performance numbers, we always keep the run going long enough to warm the cache. We take numbers only from the last 20 minutes of the run, so we know we have a consistent cache state. We don't re-run on a already-warm cache, 'cause that leads to inconsistent results. cliffw > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > Lse-tech mailing list > Lse...@li... > https://lists.sourceforge.net/lists/listinfo/lse-tech > |
From: Craig T. <cr...@os...> - 2003-01-20 22:00:23
|
I think the important thing to do is to make sure your cache is put into a known state before the run of each test. We found that our database runs have different results whether we reboot and run or whether we run a database test run without rebooting. For the safety of knowing the state of our entire system, we elected to use a reboot then run method. On Mon, 2003-01-20 at 13:47, Cliff White wrote: > > Rick was probably referring to the CPU caches. > > > > Right -- for scheduling purposes probably the disk caches aren't that > > important. > > > > We use a tool called "eatmem" to allocate all free memory a page at a time. > > This also has the effect of trashing the cache. > > I'll dig it up. > > > > Ok, thanks. I don't know if cold or warm cpu caches will make a difference > > either but would be interested in hearing if people have determined if > > they matter for this. > > > > Rick > > > We always reboot - that's one of the primary advantages of STP for running > tests. > However, when we do performance numbers, we always keep the run going long > enough to > warm the cache. We take numbers only from the last 20 minutes of the run, so > we know > we have a consistent cache state. > > We don't re-run on a already-warm cache, 'cause that leads to inconsistent > results. > > > cliffw > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > > are you planning your Web Server Security? Click here to get a FREE > > Thawte SSL guide and find the answers to all your SSL security issues. > > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > > _______________________________________________ > > Lse-tech mailing list > > Lse...@li... > > https://lists.sourceforge.net/lists/listinfo/lse-tech > > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > Lse-tech mailing list > Lse...@li... > https://lists.sourceforge.net/lists/listinfo/lse-tech -- Craig Thomas <cr...@os...> OSDL |