Re: FSI TX200 S2 and main memory > 4 GB

15% on 16 GB looks reasonable difference (because of hugetlb). But of course
it all depends of the usage profile - difference is more
if more parallel access happen (more users at  the same time) and less if
memory is used by a spots (as when we have 2 -3 usres with a huge requests).

I knew about this numbers (15 - 20%) but could not find any test results (on
the web). My own approach was:
- dont use them on 4 GB systems with 2 CPU
- use (if we have it) on 32 GB systems with >= 4 CPU
- case by case option between (more flexibility required - dont use; more
perfromance - use them).

May be, this 20% sloweness of 64 bit Oracle can be explained by this _used
hugetlb in 32 bits, because of a need in
indirect buffers, and did not use in 64 bit system_ difference, too. Through
I compared oracle in 32 and 64 bit modes without hugetlb and saw some (10 -
20%) slowness of 64 bit version (on Intel CPU).

> On Wed, 2007-06-20 at 12:27 -0700, Alexei_Roudnev wrote:
> > I have a strong impression, that benefits from HugeTLB-s on a small (<=
4GB)
> > and medium size (<= 16 GB) servers are strongly overestimated, while
> > problems with them (no automated memory allocation, implementation
> > instability and so on) are underestimated.
> >
> > Can't find exact numbers, but few charts which I find show 1 - 3 %
benefits
> > from using hugetlb in few particular cases.
> > My own experiments (with Oracle cluster and 4 GB servers) was not clean
but
> > show, that it's pretty simple to broke OS or slow it down by inproper
> > hugetlb configuration.
> >
> > So I'd better be very careful with them, and they definitely are not
> > mandatory required on 64 bit Linux.
>
> I didn't say they were mandatory requirement, and you are correct that
> improper hugetlb configuration can actually slow down a system, but they
> are not that difficult to deal with properly if you take the time to
> understand the requirements.
>
> I've been running a production Apps 11i environment with 500
> manufacturing users for years (since 2001), initially on 32-bit 8GB
> system and now on 64-bit 16GB systems, and the difference with hugetbl
> is a measurable 15-20%.  Actually, just two weeks ago we upgraded to 10G
> and the DBA failed to properly size the new SGA to fit within the
> allocated hugepages.  Even though we freed the hugepages to give the
> system the memory back, performance was demonstrably slower until we
> found time to reboot and properly allocate the memory via hugetbl.
>
> I can send you the sar output from last week showing the 10-25% system
> time being used because of the extra overhead of tracking several millon
> vma allocs rather than a few thousand.
>
> I'll admit, if your system has tons of free time on it's hands, it's
> probably not that noticable, but when it is under stress from tens of
> thousands of open cursors from hundreds of users, it can have quite an
> impact.
>
> Later,
> Tom
>
>
> -- 
> To unsubscribe, email: [email protected]
> For additional commands, email: [email protected]
> Please see http://www.suse.com/oracle/ before posting
>
>


-- 
To unsubscribe, email: [email protected]
For additional commands, email: [email protected]
Please see http://www.suse.com/oracle/ before posting