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 -- Ignore unavailable to you. Want to Upgrade?


To: Charles Tutt who wrote (48951)5/12/2002 2:19:06 PM
From: TGPTNDR  Read Replies (2) | Respond to of 64865
 
Charles, Re: <I think you'd do better running Solaris -- no "ram disks" to spend hours loading.>

I may have used the wrong terminology. I'm not a hardware guy and the problem wasn't mine but was associated with database servers for an application built in the same software organization as I was working at the time.

Heavily used tables were loaded into ram before the database was started.

The ram was not an internal part of the computers but was directly connected. It was my opinion that it was configured to look like SCSI. I could certainly be wrong about that.

The OS was HP/UX.

tgptndr



To: Charles Tutt who wrote (48951)5/13/2002 10:21:16 AM
From: rudedog  Respond to of 64865
 
Charles - you are correct - the best performance is when the database itself operates out of a flat memory model at the application as I have already mentioned in (probably boring) detail.

But the cache takes a while to fill too... so when a big database app starts, it runs almost at disk speed for a while, then gradually improves performance as more and more information is found in the database cache. Peak performance on a large system may take hours to achieve. But the "80%" level is reached fairly quickly, as the most common indexes and hot data are quickly cached.