Silicon Investor (SI) -- The First Internet Community

STOCKTALK

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 : Intel Corporation (INTC) -- Ignore unavailable to you. Want to Upgrade?

To: Tenchusatsu who wrote (135163)	5/15/2001 6:29:03 PM
From: d[-_-]b	Respond to of 186894

Tenchusatsu, re: up to 64 GB in 4-way server mode. That's the one, the difference between the current 32GB and 64GB is really pretty dramatic. The more data in memory the lower the latency, no waiting on the disk. As you said that FSB bandwidth is also a big deal.

To: Tenchusatsu who wrote (135163)	5/15/2001 10:58:05 PM
From: rudedog	Read Replies (1) \| Respond to of 186894

Ten - to really understand the database performance issue you need to know a little about how the databases work. I did a fair amount of work on 36 bit Xeon database access on a Compaq 8500 which is a profusion machine, running Windows2000 and SQL Server. First, the extra memory does nothing to change the base 2GB application data space. The other 2GB is OS. There is a kludge to shift that to 1GB Kernel and 3GB data but it doesn't work well for extended memory since the OS then needs more than 1GB for housekeeping, and the scheme has other drawbacks. So we start off with a big drawback - keeping enough of the application data in the 2GB that can be directly addressed. Modern database engines assume that the data required to satisfy a query is ALWAYS in memory. Of course it is not always there, and in that case the query thread suspends and waits for a background process to drop LRU pages and get the needed information. Unfortunately, if the data is not in the base 2GB currently mapped, the effect is the same - the query thread suspends while some remapping occurs. The result is that performance on 32 bit machines with large memory is not anything like the almost linear performance improvements in a flat address space machine. This was easily demonstrated comparing a beta version of Win2K for Alpha versus the 32 bit version. Performance on an 8GB Alpha machine was nearly double the performance of a 4GB rig. The Xeon showed only a 15% improvement going from 4GB to 8GB. So a flat addressable 64GB space would make a huge difference in database performance - both by removing any constraints on the amount of memory the OS can use, and by removing the thread suspend overhead due to what amount to page faults.