SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : All About Sun Microsystems

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Ali Chen who wrote (48890)5/10/2002 7:57:53 AM
From: rudedog  Read Replies (1) of 64865
 
Ali - no, I meant 20 times. This is not smoking dope at all. Database engines are very sensitive to the working set which can be maintained in RAM. The way they work is that every SQL query launches a thread which assumes the data is in RAM. If it is not, the thread suspends and a background process fetches the data. The cost to fetch the data from disk is over 1000 times the cost to get it from RAM, so the gains are not surprising. An 8GB flat address space allows twice as many threads to run unimpeded as 4GB.

This works only when there is enough CPQ horsepower to launch enough threads to fill the RAM, but in a big database app that is usually not the bottleneck.

We did tests on a CPQ Alpha machine running Oracle - the performance at 16GB was 10 times the performance at 4GB, and at 32 GB was more than 25 times. All other hardware identical.

Intel 32 bit machines with extended memory do not show the same gains since they do not have a flat memory model and require a task switch just as if the data was not in RAM. The same test on a Xeon-based box showed only a 30% gain going from 4GB to 16 GB.
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext