modinfo명령어를 알다!!…

커널에 모듈로 올라간 모듈에 대한 정보를 알 수 있다.

예를 들면.. ipf 모듈에 대해 보려면

modinfo | grep ipf

모듈을 제거하려면.

modunload -i pid

뭐 이렇게..

원문은 http://www.samag.com/documents/s=7667/sam0213b/0213b.htm

Solaris™ 8 Performance Tuning
James C. McPherson

UNIX 시스템의 퍼포먼스 튜닝에 대한 이야기를 할때, 시스템 관리자는 보통 몇가지 개념 – 현재의 측정된 퍼포먼스, 현재 레벨과 요구되는 퍼포먼스 레벨의 차이, 애플리케이션 벤더에 의해 요구되는 최적화 레벨, 퍼포먼스 차이를 어떻게 측정할것인가, 마지막으로 무엇을 튜닝하고 테스트할것인가 와같은 -을 가지고 작업을 한다.

현재 측정된 퍼포먼스 레벨은 사용자들이 말하는것과 시스템 모니터링을 관찰한 것을 기반으로 한다. 네트워크 환경에서, 만약 여러분이100Mbps Full-Duplex 연결을가지는 몇몇 사용자들과 나머지 사용자들은 여전히 10MBPS hdx연결을 사용한다면, 10Mbps 사용자들은 항상 시스템이 느리다고 말할 것이다. 그렇지만, 여러분은 100Mbps 사용자들이 불평하기전에 심각한 애필리케이션 오버로드나 리소스가 고갈 되기를 기다릴 것이다. 또한 시스템 레벨 모니터링을 위한 측정가능한 커널 통계와 자세한 로그화일들이 있다. 어떤 사이트는 snmp MIB를 통해 모니터하기위한 CA UniCenter TNG, HP OpenView, 또는 SUN의 SunMC같은 유용한 툴을 사용한다. 그렇지만 이것은 충분한 시스템과 애플리케이션 관리자에 의해 사용되는 툴이지 홀로 사용되지는 않는 툴이다.

요구된 퍼포먼스 레벨은 조금 다르다. 벤치마크는 때때로 덜 유용하지만, 여러분이 큰 벤더의 시스템이나 애플리케이션을 사용한다면 그들(벤더들)은 여러분의 환경과 여러분이 허락한 실제 부하들을 복제해서 특별한 벤치마킹 그룹을 가질 것이다. 여러분은 여러분 회사의 요구에 특별히 맞추어진 것이기에 이러한 방법에 의해 벤치마크된것을 신뢰할 수 있을 것이다. 맞춤 벤치마크를 구성하기위한 리소스나 시간이 부족하다면, 여러분은 스스로 하기위한 여분의 시간을 써야만 할 것이다.시작하기 전에, 어떤 측정이 여러분 시스템에 유효할 것이고 어떻게 그것을 얻을 지를 결정해야 한다. 또한, 테스트와 모니터링에 여러분의 사용자를 고려해 함께 작업해야 한다. 그들이 변화를 인식하고 여러분이 제공한 것을 고맙게 여기도록 여러분이 한일에 대한 정보를 사용자들에게 제공하라.

How to Measure before and after Performance Differences
효과적으로 튜닝하기 위해, 여러분은 무엇을 이루고자하는지를 먼저 결정해야 한다. 여기에 고려해야할 몇가지 팁이 있다.

성공을 위한 기준을 결정하라.
모든것을 기록(log)하고, Sun Explored를 실행해서 매 시간 데이타를 수집하라.;ㅡㅡ
로그를 주의깊게 분석하라.
이루고자 원한 것에 대한 퍼포먼스 변화를 측정하라.
올바른 규칙에 따라 하라.

여러분이 이미 리소스 부하(load)와 시스템의 레코드를 유지하지 않고 여러분 시스템상의 애플리케이션을 모니터링하는 방법을 가지지 않았다면, 간단히 시작하라. 여러분은 cpu/memory/swap 이용율과 디스크 이용율(특별하게 여러분의 애플리케이션 화일시스템)과 네트워크 이용율을 표준 시스템 틀을 사용해서 측정할 수 있다. Solaris 8은 여럴분이 다양한 시스템 특성을 갖가지 출력포맷으로 볼수있는 유틸리티인 kstat(1M) 유틸리티를 사용할 수 있게 한다. df -k 또한 유용하다. 여러분은 이러한 통계를 주기적으로 화일로 덤프하는 스크립트를 작성하거나 아파치와 mrtg1 같은 주기적으로 리프레시해서 보여주는 툴을 사용할 수 있다. 쉘을 작은 부분인 awk, seed, 또는 perl은 여러분에게 많은 그래프들을 제공할 수도 있을 것이다.

가장 쓸만한 퍼포먼스 모니터링은 여러분의 애플리케이션 관리자와 사용자들이 결정한 충분한 길이의 시간동안 주지적이고 규칙적인 스냅샷을 요구한다. 내 경험은 모니터링 데이타(가급적 피크 로드 기간을 포함하는)가 8일보다 짧게 모여서는 안되며 그래서 여러분은 찾을수 있는 분명한 피크와 through를 얻어야 한다. 측정의 다른 측면은 어떻게 그들이 모니터링 기간에 퍼포먼스가 변화한 과정의 이전과 이후 모두를 사용자를 대상으로 조사하는 것이다. 여러분의 퍼포먼스 튜닝이 사용자들이 차이를 인지할 수 없는 결과를 가져왔다면, 나는 퍼포먼스가 정말로 튜닝되지 않았다고 말할 것이다. 질문에 대한 쓸만한 답이 있다.

튜닝을 시작하기 전에 오전 9시, 정오12시, 오후 2시, 오후5시에 표준작업(초단위로 측정된)을 얼마나 오래 수행했는가?
이런 작업이 지금 얼마나 오래 됐나?
여러분은 그 퍼포먼스가 지난 x날 동안 향상되었는지, 같은지 더 나빠졌는지를 생각하는가?(적어도 이 질문에대해서는 7-지점의 측정이 추천된다)

시스템 관리자인 여러분은 여러분스스로 이런 표준 작업을 측정하는것이 필요하고 여러분은 측정을 위한 참고용 프레임을 가지게 된다.

What to Tune and When to Tune It

I/O and Buffers (Including VxVM and VxFS)

가장 일반적인 퍼포먼스 튜닝의 목표는 분명히 I/O이고, 솔라리스에서는 몇몇 버퍼들과 우리가 할 수 있는 조정이 있다. 여러분은 아마도 디스크 vs 램의 상대 속도와 어떻게 지난 20여년간 이 속도차이가 드라마택하게 변해왔는지에 주목할 것이다. 이것은 솔라리스가 페이징2로 구현된 방법 때문에 여러분 서버의 ‘가상메모리’ 구성에 특히 중요하다. 여기서 주요 관심은 여러분의 느린 디스크(비록 10000rpm fcal 디스크도 여전히 느리다)로 데이타가 페이징 되는 것을 피하고 다음 적정시점에 tcp 스택이나 스커지로 보내지기까지 램에 데이타가 남아있는것을 보장하는 것이다.

어떻게 페이징을 방지하는가? 이 질문에는 ‘좋은’ 그리고 ‘나쁜’ 페이징의 식별이 필요하다. ‘좋은’ 페이징이라 불리는 것은 프로세스로부터 페이지가 다시 요청되거나 시스템 할당시에 발생하는데 반해 ‘나쁜’ 페이징은 디스크장치로부터 신뢰할 할당이 일어나고 시스템은 불필요한 액세스를 초래한다. 그래서 우리는 ‘좋은’페이징에 대해 특별한 주의를 할 필요는 없기 때문에 커널의 페이징 알고리즘은 가능한 드물게 발생하도록 지능적으로 작성한다. 페이징 우선순위(priority_paging)설정은 솔라리스 2.6과 솔라리스 7에 필요하다. 솔라리스 8이나 솔라리스 9는 이것이 필요하지 않은데 이것은 새 커널에 통합된 사이클릭 페이지 캐쉬라 불리는 priority_paging의 수정된 버전때문이다. ‘나쁜’ 페이징은 스와핑으로 알려져 있으며, 극단적인 환경에서 여러분의 I/O 서브 시스템이 thrashing이라 말하는 높은 I/O 부하 같은 결과를 초래할 수 있다.

여러분은 특히 솔라리스쪽의 ncsize와 lotsfree의 조정을 주의해야 한다. 여러분이 베리타스 볼륨 매니저(vxvm)일 구동하고 있다면, 여러분은 volkio에 친숙하고 주의해야 할 필요가 있다. 여러분이 베리타스 화일시스템(vxfs)를 구동한다면, 여러분은 vxfs:vxfs_ninode와 vxfs:vx_bc_bufhvm의 조정에 주의 해야한다. 나는 이러한 변수들을 조정하는것에대하 강의할 것이다.

ncsize
ncsize의 ‘nc’는 네임캐쉬(Name Cache)를 의미하고, 디렉토리 네임 루크업 캐쉬(Driectory Name Lookup Cache, 짧게 dnlc)의 크기를 설정하는 데 사용한다. 이것은 ;ㅡㅡ 여러분의 화일시스템으로부터의 보다 좋은 퍼포먼스를 주기위한 최적화이다. ncsize의 디폴트 세팅은 max_nprocs와 maxusers 두 변수에 의존하며, 다음과같은 관계가 있다.

ncsize = (4 * (max_nprocs+maxusers)) + 320
max_nprocs = 10 + (16 * maxusers)
maxusers = physmem – 2

나머지는 나중에 …