This content has been marked as final. Show 11 replies
986844 wrote:I have a simple view of this in the first place.
I have a E6900 running solaris 10 with 96 GB physical mem. This server is a Database server and, running very slow. If I change the values of stack size and, file descriptor what would I gain? BTW system paging very heavily. Here is my memstat during the peak time.
echo ::memstat | mdb -k
Page Summary Pages MB %Tot
------------ ---------------- ---------------- ----
Kernel 4266128 33329 35% ----> what does this mean in plain english
Anon 7601664 59388 62%
Exec and libs 40137 313 0%
Page cache 252118 1969 2%
Free (cachelist) 173538 1355 1%
Free (freelist) 25175 196 0%
Total 12358760 96552
Physical 12349425 96479
If the system is paging then you have insufficent physical ram for your current configured workload.
- One option is to add RAM.
- The other option is reduce the size of the active virtual memory.
- Assuming there are no extra processes going silly, including monitoring tools, and perhaps including database agents, it may be worth considering:
--- Reducing the number of databases running on the machine.
--- Reducing the SGA/PGA size of those databases running on the machine.
If memory structures required by database are swapped out paging will be steady as the database will be assuming these are in memory to run quickly.
Check this with your DBA.
Edited by: bigdelboy on Feb 7, 2013 1:23 PM typos
thanks for your input. You are very correct that I am lacking RAM but, I am not in a position to add/increase (production issues). Here is a snippet of my prstat
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/LWPID
2419 odb10g 49G 25G cpu10 0 0 23:45:18 1.8% oracle/1
4943 odb10g 7928K 5216K cpu19 0 0 1:02:37 1.8% sshd/1
22712 odb10g 49G 5012M sleep 0 0 141:37:41 1.4% oracle/1
27141 root 17M 16M cpu533 39 0 0:04:15 0.8% prstat/1
21725 odb10g 49G 41G sleep 59 0 0:10:01 0.8% oracle/1
9832 odb10g 49G 41G cpu527 0 0 0:01:43 0.7% oracle/1
11195 odb10g 49G 41G cpu14 0 0 0:00:25 0.7% oracle/1
23071 odb10g 49G 41G cpu513 9 0 0:01:23 0.6% oracle/1
23452 odb10g 49G 41G sleep 49 0 0:06:19 0.6% oracle/1
13047 odb10g 49G 41G sleep 49 0 0:00:16 0.5% oracle/1
28068 odb10g 49G 18G sleep 59 0 24:38:45 0.4% oracle/1
14969 odb10g 49G 41G cpu15 0 0 0:00:23 0.4% oracle/1
8322 odb10g 49G 41G sleep 59 0 0:02:18 0.4% oracle/1
26774 odb10g 49G 41G sleep 59 0 6:46:58 0.4% oracle/1
as you can see oracle is using 50 G sga. incidentally my DBA has SGA=50G and, PGA=40GB. I have to convince him that adjusting this would make system faster. One other question if, I reduce PGA only would that help?
as you can see oracle is using 50 G sga. incidentally my DBA has SGA=50G and, PGA=40GB. I have to convince him that adjusting this would make system faster. One other question if, I reduce PGA only would that help?I can only answer possibly/probably. Your DBA has tools that should help him diagnose impact of this :: memorypga advisors :: see e.g.:
root # vmstat 1 5
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr m3 m1 m1 s0 in sy cs us sy id
0 0 0 22640808 6429120 450 356 1614 60 55 0 0 32 0 -0 0 1859 4463 3224 4 4 92
1 0 0 22289688 6012928 0 14 0 0 0 0 0 0 0 0 0 591 389 569 0 0 100
Check the values for sr. If the value is not zero then add the following line to /etc/system and reboot your server.
set maxfastscan = 0x2000
Thank you all for you inputs. have run the vmstat and, sr column is high. I will modify /etc/system as you suggested.
To answer your original question, stacksize and file descriptor are process parameters. Increasing them will just allow the processes to allocate more memory. So that's not the answer to your dilemma.
Nor is setting maxfastscan. That will instruct to speed up the freepage scan but your situation will not be solved by doing this.
There is no silver bullet/low hanging fruit that's going to fix this. You need to work with your DBA and reduce the SGA/PGA footprint (more likely PGA in this instance) to reduce the system memory usage.
Thanks bobthegeek76 for your input. I can see myself fighting with DBA for SGA/PGA adjustment.
The server is swapping. Too much memory is being used. If your DBA is that pigheaded:
projadd -U oracle -K "project.max-shm-memory=(priv,40960MB,deny)" user.oracle
See "man projadd" and "man resource_controls".
Actually I, am paging not swapping. Shared memory looks good. Thanks
986844 wrote:A distinction without a difference when you're complaining about performance.
Actually I, am paging not swapping.
Shared memory looks good. ThanksWhere do you think the SGA goes?
It goes into shared memory:
A system global area (SGA) is a group of shared memory structures...
We knew we were short of memory so, we added memory (almost 100GB). Now when we reboot the server and, monitor the server right after the reboot system shows 95GB used. 70 GB for Oracle and, 12GB for root and, others. My question is where are the rest of the memory? How can I quantify the rest of the used memory?