메모리 관리에 관해서

[watermelonyu]

OS:HP-UX 11.23

사용하고 있는 시스템에서 사용가능 메모리가 점점 줄어듭니다. 문제는 기동한채로 그냥 두었음에도 줄어들고 있습니다. 접속도 하지않고 심지어 데이터를 전송하는등의 움직임은 일체 하지 않고있습니다. 이럴경우 커널의 설정이 잘못되어서 (dbc_max_pct는 기본설정으로 50)인지 아니면 애플리케이션의 특정 프로세스가 메모리를 사용하기때문인지,실제메모리가 부족해서인지 분석할수 있는 방법이 없을까요? 자세하게 메모리 관리하는 법을 알려주세요.

(※GlancePlus는 사용할수 없는 상황입니다. 체험판도 인스톨 불가능입니다.)

[김춘수]

www.itrc.hp.com에 있는 내용인데, 혹시 도움이 될까해서 올려봅니다.







제출 날짜: 98. 1. 8.

제목: What process causes a memory leak?

문서 ID: A4955688B

최종 수정 날짜: 05. 8. 5.







이 문서에 대한 피드백 제공을 할 수 있습니다.







Problem Description



What process causes a memory leak?



Configuration Info



Operating System - HP-UX

Version -10.10

Hardware System - HP 9000

Series -800



Solution



A memory leak is a subjective term, but often unix system

administrators will use it to refer to a system-wide problem where,

over time, there is less and less free physical memory. It is also

seen as a shortage of unreserved swap space.



In this context, there are 2 kinds of memory leaks on hp-ux. The

kernel can leak memory, or processes can leak memory. Processes

leaking memory can include user programs, applications, and (rarely)

system daemons.



In the performance tools (GlancePlus, MeasureWare Agent, and PerfView),

all memory leaks are usually seen as GBL_MEM_USER_UTIL (thus

GBL_MEM_UTIL) growing slowly but consistently over time. The metrics

will climb slowly until something crashes (sometimes an application

aborts, sometimes hp-ux itself panics). From a long-term analysis point

of view (such as PerfView provides), You'll see the metrics dip back

down to "normal", then the steady march upward resumes. Often you'll

also see GBL_SWAP_SPACE_UTIL grow apace. On some systems (with large

dynamic buffer caches and lots of disk activity) the GBL_MEM_UTIL metric

will always be near 100% but the growing metric GBL_MEM_USER_UTIL will

cause the buffer cache to shrink until it hits its minimum.



All this doesn't mean that its actual "user" memory being leaked,

however! The System memory is allocated mostly at bootup and a little

after, and most memory leaks even inside the kernel don't show up as

System memory growing. The performance tools calculate User memory as

being equal to:



Physical memory minus Free memory minus System memory minus Buffer Cache

In a system memory leak situation, User memory *seems* to go up because

Free memory is going down and the other memory metrics aren't changing

much.



The easiest case first: System or user processes that leak memory are

usually pretty easy to catch. Typically an application will be

allocating memory for some dynamic object and not freeing it. As this

happens over and over, the memory virtual set size for the process

steadily increases. In the performance tools, you'll see PROC_MEM_VIRT

(thus APP_MEM_VIRT) increasing over time.. sometimes it may take days or

weeks for this to be obvious so one trick to use is to draw a long-term

PerfView Class Compare graph for all applications using APP_MEM_VIRT.

Depending on how well you've defined your parm file applications, this

will help narrow down the problem but at some point you need to go to

the process-level data and look for hogs. Usually PROC_MEM_RES and

APP_MEM_RES (resident set size) will help show the hogs also, since

resident physical memory is usually what's actually being

constrained on the system, but if there is a lot of memory pressure then

sometimes even the memory hog processes will have smallish resident set

sizes because they are being paged out.



There various 3rd-party development tools available on hp-ux that can

be purchased to catch memory leaks in applications when the source is

available. You can use Glance, MeasureWare, or PerfView to characterize

a memory leak down to a single program but these tools will not help you

isolate the specific area of code causing the problem.



For kernel memory leaks (which are fortunately quite rare), analysis is

much more difficult and best left to the HP Response Center to

characterize. You might suspect you're seeing a kernel memory leak when

the Global memory metrics show leakage as described above, but you don't

see any corresponding APP_MEM_VIRT growth. If no processes are

increasing their memory allocations over time, yet system memory is more

and more constrained, then their could be a problem inside the operating

system itself. One such problem seen on busy HP-UX 10.20 systems

resulted in the hp-ux patch PHKL_11165.



For any heavily used system, workloads slowly tend to increase over time.

More users are added to a system, the complexity of the workload increases,

and users log into a system and then forget about the sessions. It may

be hard to tell the difference between normal increasing workload and a

memory leak. Knowing what's normal for your system is the key. Use your

performance tools to look at the system often and then you'll be better

prepared to handle a problem situation.

[김병수]

Glance Tool을 사요할수 없다고 하셨는데 memory 사용률이 감소한다는 것은 어떻게 확인하셨는지 궁금하네요.



# sysdef |grep -i dbc

dbc_max_pct 25 - - -

dbc_min_pct 5 - -



하시면 현제 설정된 dyncmic buffer cache설정값을 확인하실수 있습니다.

특정 processor를 확인하기 위해서는 lsof를 설치하시기 바랍니다.



가능하면,정확한 분석을 위하여 glance tool을 설치하시기 바랍니다.



그럼~~~

[watermelonyu]

메모리는 vmstat를 이용해서 메모리추이를 확인했습니다. 일주일 동안의 메모리사용을 확인하면, 8기가중 사용가능(free)메모리가 부팅후 어플리케이션이 시작되는 시점에서 팍 줄어들면서 일정기간 안정기에 들어갔니다(900-800메가사이). 그리고 점점 조금씩 줄어들기 시작합니다. 일주일이 지나면 리부팅을 하기때문에 같은 문제가 다시 반복합니다. 문제는 아무것도 하지 않는 상황에서 사용가능 메모리가 물리메모리의 10분지 1밖에 남지않습니다. 거기서 데이터전송등을 작업을 하면 줄어들지 않을까 걱정입니다. 일단 생각할수 있는게 버퍼캐쉬메모리가 최대50%로 되어있고 vmstat와top을이용해서 어플리케이션 이 많은 메모리를 이용하고 있다는것은 확인했습니다.(어플리케이션의 경우 공유메모리등의 문제로 특정프로세스가 문제가 있다고 확인을 못하겠습니다.방법을아시면 알려주세요) 사용가능 메모리가 조금씩 없어지는 원인을 알고싶습니다.

[monoworld]

안녕하세요? 질문내용을 보니 버퍼 캐쉬 때문인것 같습니다.

일반적으로 OS올라오면 시스템,버퍼 등

기본적으로 사용하는 메모리 할당 량이 있습니다.

커널 튜닝 안되어 있으면 기본 버퍼 할당량이 50%로 잡혀 있습니다.

(아래 텍스트 로그 참조)

특히 버퍼 캐쉬는 능동적으로 늘었다 줄었다 합니다.

물론 사용중인 버퍼가 줄어드는 경우는 많지않고

처음에는 작았다가 설정 한계치 까지 계속 증가 하게 됩니다.



크리어님 시스템 같은 경우 8G 메모리중 50%이니 약 4G까지 증가 하게 됩니다.

따라서 4G까지 버퍼 증가는 이상 현상이 아닙니다.

다만 너무 큰 버퍼 사용은 유저가 사용할 수 있는 메모리량을 줄이며

메모리 사용량 증가시 버퍼영역을 줄이고 비우는 작업을 하게되 성능 저하가 발생 할 수 있습니다.

따라서 dbc_max_pct 커널 값 적당히 조절 하시면 되고

(/usr/sbin/kctune dbc_max_pct=20)



조절 방법은 11.23에서는 dynamic 하게 변경 하능하며

sam 으로설명하면 아래 순서대로 하시면 됩니다.





SAM -> Kernel Configuration -> Tunable -> Modify (dbc_max_pct)

-----------------------------------------------------------------

Tunable dbc_max_pct

Description Maximum percentage of memory to be used for caching file I/O data and metadata

Dynamic yes

Subsystem fs

Default Value 50

Current Value 50

Planned Value 20

Last Boot Value 20

Constraints dbc_max_pct >= 1

Constraints dbc_max_pct <= 90

Constraints dbc_max_pct >= dbc_min_pct

Auto Tuning Not Supported



Enter Value/Expression OR q(quit) = 20 <-- 필요한 커널 크기(%)



Do you want to hold this change till next boot ? (y/n/q) = n

<- 온라인중 즉시 적용시 n, 다음 부팅시 적용 y



Do you want to save the current kernel configuration ? (y/n/q) = y



Enter Comments = imsi



Command Preview: /usr/sbin/kctune -C "imsi" dbc_max_pct=20



Do you want to proceed ? (y/n) = y