How to make a good case to purchase more memory

[Jason Berendsen]

I have an N class server with 4 gig of physical memory and the same size configured swap. My dynamic buffer cache is set to 5-10%. As of today I have 340 Oracle sessions logged into an 8.1.7 database set with a 1 gig SGA. I am finding at about 310 sessions the system starts paging. But, on average about 290 of these sessions are idle. My DBA's are screaming for more memory along with others that see an ongoing 99% utilization on the memory, but I am seeing very little in application or system performance. I agree we need more memory before we get to the point of deactivation, but what do you tell management that doesn't see the system degrading? Any recommendations as to what adverse effect paging can have on a system would help.

[Jeff Machols]

Paging does slow things down. Whenever you read a page back into memory, you are accessing the disk, the access time is much greater (usually at least 5 times). Also, if you are 99% utilization, you will eventually see a performace issue or worse system errors. Do you wait until you run out of gas to fill your car back up?

[Sridhar Bhaskarla]

Hi Jason,

The best way to find this out is looking at different snapshots of glance.

1. Look at glance and see the memory bar. You will see three indicators. S-Memory by the system processes U-by the user processes and B-buffer cache usage. Note U if the total memory usage is at 99%. It will not become 100% as it has to keep the "minfree" always. But it will page/swap out the processes to keep this limit.

2. Look at the CPU. If there is a lot of "S"mode utilization, it means system may be thrashing. Typical ratio between U and S should be 85:15. CPU in System mode should be less than 20% for 70-80% user mode utilization. Please note that you will get higher system mode utilization even if there is a lot of IO. Make sure you are not stuck with disk I/O problems.

3. Go to memory window in glance. Look at pageouts and KB pagedout. A smaller number of pageouts are common for memory mapped files. But if you see a constant but large number of pageouts with KBpagedouts, then your system is actually running short of memory.

4. You do not want to see anything under Deactivations/KB Deactivated heading. If so, then your system is constrained on memory.

5. Also look at your "swapinfo -t" section. Look at the reserve. You get it by adding KB used in reserve row and kb used in memory row.
It shouldnt' be more than the Physical memory size of your system. Also look at the KB used in your device swaps.. A small amounts may be ok but still indicate that you are running short of memory. High amounts indicate you are starving on memory.

5. I don't believe in increasing swap etc to give more "virtual memory". I prefer to buy memory than living with most of my processes going to and fro from the swap area.

-Sri

[John Bolene]

Sounds like you have swapmem_on set to 1 and have done a great job at managing the server.

Since you have started to page, it depends on how bad the paging is. If not bad, or it gets worse at times, and the users are not complaining about response time, and the cpu's and disks are not overloaded also...

Then you are probably right at the threshold of things starting to go downhill.

If you get more users or users that are not idle, your response will get ugly quickly.

So, it more depends on what the future holds, as the present looks like it is just holding on.

[fg_1]

Jason

Paging will have a dramatic affect on your overall system performance. If you are planning any further growth on this system, then it will be time to go to 8GB of memory with the same swap size configured.

Also are you sure that you do not have any memory leaks on the database side of the house. Oracle has some very specific issues with memory leaks especially at 8.16 and higher.

I would check that issue out as a last stand before going to mgmt. This will ensure that you have dotted all the I's and crossed the T's.

Good luck.

FG.

[harry d brown jr · Accepted solution]

Raise the dynamic buffer cache, min and max, to 30%, then when the users complain, expalin to management that additional memory of at least 4GB is necessary to enhance performance, then when the memory arrives, change the dynamic buffer cache min to 5% and max to 10%.

live free or die
harry

[Christopher Caldwell]

In my experience, HPs tend to run really really well, then they fall over. I imagine that's because when you cross that "invisible boundry" you get into a lot of overhead.

You can monitor utilization with tools to plot things like buffer hits and misses for the SGA. This plot will show you that more resources are getting consumed over time, though performance may still "feel" okay.

Buy capacity early, not when you have a problem.

Memory is cheap, CPUs/software licenses are expensive.

Oracle 8.1.7 CPU based licenses list for 40K per processor.

2G of Dataram 3rd party memory less than $1000, street price.

When dealing with Oracle on an adequately sized box, memory and IO channel separation/disk and file system distribution had the most marked effect on improved performance.

[A. Clay Stephenson]

Hi Jason,

Rather than addressing the technical issues, I think I will answer your specific question. Use Perfview to print memory utilization graphs. Management understands: RED BAD; GREEN GOOD. A color printer is essential. In the few cases where I have had to make this pitch the graphs make all the difference. Nowadays, I simply say I need memory and that's that but many admins don't have that luxury. The other thing that makes this an easier sell is to look at 3rd-party memory. You need some HP memory in the box to keep your CE's happy but you can easily keep unused memory modules as spares (that typically have lifetime warranties) and still save a ton of money.

[Tim D Fulford]

I would verbally explain that memory is 10,000 times faster than disk. As time goes on you apps will slow down to 10,000th of there design speed. Unless you invent a time machine or kick people off the machine it will run like a dog.

At the end of the day Management only see
* cach (theirs)
* responsibility (shifting it)

I would mail your manager a document with some pritty pictures. You can justify it like so:

The machines are starting to reach their capacity as far as memory is concerned. Consequentially, we are currently breaching our SLA's to our customers and experiencing an increase in helpdesk traffic due to this application. There are two options available
1 - Buy a new server & split services over two machines, application server & database server.
2 - Buy more memory for existing server extending its life.

They will soon realisse that option 1 is too expensive and perhaps option 2 is viable. If you can weedle in targets, SLA's and bonuses so much the better.

good luck

Tim

PS I would use MeasureWare to get your graphs (If you have it) & extract GLOBAL stats
GBL_MEM_PAGE_REQUEST_RATE
GBL_MEM_SWAP_1_HR_RATE
GBL_MEM_PAGEOUT_RATE
GBL_MEM_SWAPOUT_RATE

Also you can lok at the activity of the swap disks

BYDSK_PHYS_READ_RATE
BYDSK_PHYS_WRITE_RATE
BYDSK_SYSTEM_IO_RATE
BYDSK_PHYS_IO_RATE
BYDSK_UTIL
BYDSK_REQUEST_QUEUE

If you do disk_util*10/IO rate == IO_Time
IO_time > 15-20ms means you are starting to thrash (depending on the disks)