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 : All About Sun Microsystems -- Ignore unavailable to you. Want to Upgrade?

To: Ali Chen who wrote (48933)	5/11/2002 10:30:14 AM
From: rudedog	Read Replies (1) \| Respond to of 64865

Ali - the proof is in the pudding - results speak for themselves. but it is not the task switch (thread switch actually) which imposes the overhead, since that happens in either a 32 bit or 64 bit environment. Rather it is access to a flat memory space versus a segmented one. The difference to fill a data page request in Oracle, for example, is 2500 instructions for a flat memory operation versus more than 20,000 in a segmented model. The memory access itself at the hardware level is 16 times longer assuming the data is in L2. The IA32 TPC-whatever results you mention look good for Intel only for distributed data in a cluster, not for single machine performance. Take a look at tpc.org You will see that there is NO Intel-based volume server in the top ten, let alone "leading the pack". Those are some pretty absolute numbers. But if you need more, look at TPC-H. tpc.org In the small database section, Intel servers do well. But in the more enterprise-oriented sizes, 300GB and 1000GB - there are again NO intel based servers in the list.

To: Ali Chen who wrote (48933)	5/12/2002 6:58:19 AM
From: TGPTNDR	Read Replies (2) \| Respond to of 64865

Ali, Re: < "Where and when have you seen even 2x performance gain when replacing a piece of hardware?"> You should know that I'm not a hardware guy. I'm not buying all of the task switch stuff, but I'm buying that some FANTASTIC large database performance improvements can be made using big ram. To the point where we have machines that spend 4 hours initializing their cache && ram drives when we bring up the database(s). If the ram isn't big enough to hold the whole working set of a query it's got to be written to disk. Once that starts performance ends. System I/O goes to the moon. The local network bogs.(You know all that.) And once you've bogged the local network EVERYTHING slows -- including stuff that's not even logically related. Including stuff that's on the distributed network not associated with the write.( Frustrated users hitting keys? Unanswered heartbeats? Who knows? ) When you look at the machine(s) all the numbers are near zero except disk I/O for a specific process which is sitting at 100%. ALL of the processors on that machine are near zero. We've had some pretty smart folks working on it. ( CSCO, HWP, ORCL.) By buying ram you can cut the numbers of times it happens. (And you can verify that the ram made the difference and calculate why.) By looking at the questions being asked you can physicalize the db to minimize the sets. By careful design you can maximize the networks. By policy you can change who can ask questions and when big questions are asked. In the end, however, the difference between a 2 hour retrieve and a 30(or 1) second one can be the quantity of ram. And when that happens frequently enough the $ cost is irrelevant. tgptndr