Oracle Solaris Server VMSTAT

Oracle Solaris Server VMSTAT

Memory management in UNIX

Most operating systems today possess what is commonly called virtual memory.  In a virtual memory configuration it is possible to extend the existing RAM memory with the use of special swap disk areas.  Memory management in UNIX is critical to the performance of any Oracle database.  As we may know from out Oracle DBA 101 training, the RAM regions of Oracle are designed to improve the speed of data access by several orders of magnitude. 

In other words, RAM is more than 10,000 times faster to access that going to a disk device for the data.  Hence, we are very concerned that our RAM memory always stays within the actual RAM cache, and is not swapped out to the swap dis. Let’s take a close look at how this works.

Virtual memory in UNIX

Virtual memory is an internal “trick” that relies on the fact that not every executing task is always referencing it’s RAM memory region.  Since all RAM regions are not constantly in-use, UNIX has developed a paging algorithm that move RAM memory pages to the swap disk when it appears that they will not be needed in the immediate future (Figure 2-5)

Figure 5: RAM demand paging in UNIX

As memory regions are created, UNIX will not refuse a new task whose RAM requests exceeds the amount of RAM. Rather, UNIX will page out the least recently referenced RAM memory page to the swap disk to make room for the incoming request. When the physical limit of the RAM is exceeded UNIX can wipe-out RAM regions because they have already been written to the swap disk. 

When the RAM region is been removed to swap, any subsequent references by the originating program require UNIX copy page in the RAM region to make the memory accessible.  UNIX page in operations involve disk I/O and are a source of slow performance. Hence, avoiding UNIX page in operations is an important concern for the Oracle DBA.

The page out operation

UNIX will commonly page out RAM pages in anticipation of additional demands on the RAM memory region.  This asynchronous writing of RAM pages is generally done for all memory regions that are marked as swappable.  For details on making the Oracle SGA non-swappable, please see the special init.ora parameters described later in this chapter.

In sum, a page-out does not cause the RAM memory region to be physically moved out of the RAM, and it is only a preparatory phase.  In case UNIX decides to flush the region from RAM, he will have already copied the RAM contents to the swap disk.

Now let’s look at what happens when a RAM memory page is purged from physical RAM.

The page-in operation

As we noted a page out is no cause for concern because UNIX has not yet decided to actually remove the region from RAM.  However, then UNIX performs a page in, disk I/O is involved, and the requesting tasks will have to wait a long time (milliseconds) while UNIX fetches the region from the swap disk and re-loads it into the RAM region.

Hence, RAM page in operations can be disastrous to the performance of Oracle tasks, and the Oracle DBA must constantly be on the lookout for page in’s and take appropriate action to remedy the problem.

A following section in this chapter on the vmstat utility will show you how to detect page in operations, and we can remedy page in operations in several ways:

1 – Add additional RAM to the UNIX server.

2 – Reduce the SGA size for our database by lowering the size of the data block buffers.

3 – Mark the critical RAM regions (such as the Oracle SGA) as non-swappable

Now that we understand the basics of RAM management in Oracle, let’s take a close look at UNIX commands to manage processes in UNIX.

 

#	vmstat	2	5
	kthr			memory					page				disk
r	b	w	swap	free	re	mf	pi	po	fr	de	sr	m0	m1	m3	m4	in
																	faults			cpu
2	2	30	12759232	1902464	2203	0:00	20455	129	205	117560	1576	1	11	1	2	2528	sy	cs	us	sy	id
23	25	223	4884328	75992	1665	0:00	17973	4010	9051	85712	212978	11	604	0	9	3136
27	23	223	4883448	70648	2214	0:00	22224	5143	6510	69432	176826	19	570	4	8	3163	7014	4062	48	18	34
18	29	222	4878968	59776	1757	0:00	28272	3672	15563	56336	206942	13	622	6	5	3458	4214	3625	40	60	0
11	24	221	4881464	71944	2363	0:00	30116	3383	10990	115448	213999	12	587	0	10	3745	5148	4037	40	60	0
	kthr			memory					page				disk					3970	41	59	0
r	b	w	swap	free	re	mf	pi	po	fr	de	sr	m0	m1	m3	m4	in		4845	44	55	1
2	2	30	12751752	1900488	2206	0:00	20486	133	213	84168	1643	1	11	1	2	2530	faults
12	2	127	7822184	131800	821	0:00	9608	893	1275	115448	375	0	11	0	0	3355	sy
14	4	127	7804656	131480	424	0:00	7591	3954	8754	93520	7083	0	96	0	0	2888	7022
11	7	127	7802064	132408	762	0:00	11248	2947	4190	115448	2423	0	44	0	0	3667	9791
12	5	127	7795632	130320	813	0:00	11777	2742	3338	93520	10067	2	32	0	0	3507	8016			cpu
17	5	127	7797128	135440	770	0:00	11624	436	436	75752	0	7	56	0	0	2978	7323	cs	us	sy	id
12	6	127	7796952	134544	1013	0:00	14234	614	614	61368	0	0	0	0	0	3390	7290	4064	48	18	34
8	6	127	7797448	146864	2270	0:00	26125	16	16	128272	0	0	0	0	0	2937	6163	5776	74	26	0
11	4	127	7780816	137976	997	0:00	13167	16	16	103904	0	0	0	0	2	3312	6677	5134	65	35	0
8	10	127	7770608	131104	278	0:00	4002	2925	6580	115448	43077	0	24	0	0	3760	6032	5095	67	33	0

 Page-ins are common, normal and are not a cause for concern. For example, when an application first starts up, its executable image and data are paged-in. This is normal behavior.

Page-outs, however, can be a sign of trouble. When the kernel detects that memory is running low, it attempts to free up memory by paging out. Though this may happen briefly from time to time, if page-outs are plentiful and constant, the kernel can reach a point where it's actually spending more time managing paging activity than running the applications, and system performance suffers. This woeful state is referred to as thrashing.

Using swap space is not inherently bad. Rather, it's intense paging activity that's problematic. For instance, if your most-memory-intensive application is idle, it's fine for portions of it to be set aside when another large job is active. Memory pages belonging to an idle application are better set aside so the kernel can use physical memory for disk buffering.

 

 

• Reference:

http://www.princeton.edu/~unix/Solaris/troubleshoot/vmstat.html

http://www.bga.org/~lessem/psyc5112/usail/man/solaris/vmstat.1.html

http://www.dba-oracle.com/unix_linux/memory_management.htm

 

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26136400/viewspace-716999/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/26136400/viewspace-716999/