Eclipse를 쓰다보니 디버깅도 Eclipse로 하고 싶어졌다. 

문제는 로그인한 유저와 디버깅 대상 프로세스가 실행되고 있는 유저가 다르다는 것. 

"C/C++ Attach to Application"을 사용하려 해도, 해당 프로세스에 대한 권한이 없어서 안된다. 


이를 해결하기 위해 첫 번째 해야 될 일은 "sudo gdb"이다. 

이렇게 하면, gdb를 실행할 때 root로 실행하기 때문에 다른 프로세스에 접근할 수 있게 된다.

그러나 실제로 위를 실행하면 실행이 안 되는데,  sudo를 할 때 패스워드를 입력해야 되어 프롬프트에서 멈추게 되는데, eclipse에서는 이를 입력할 수 있는 방법이 없다. 

그래서 두번째로 해야 될 일은 현재 유저가 gdb에 대해서는 root로 실행할 때 패스워드를 입력하지 않아도 되게 하는 것이다. 이는 root로 접속하여 visudo를 실행하여 아래와 같이 수정한다. 

<users> ALL=(root) NOPASSWD:<program>



이제 root 권한으로 이클립스에서 타 유저의 프로세스를 디버깅할 수 있게 된다. 


출처:http://stackoverflow.com/questions/2891356/how-to-debug-application-as-root-in-eclipse-in-ubuntu


' > 개발' 카테고리의 다른 글

VIM - 여러 파일 편집  (0) 2013.04.08
Eclipse에서 다른 유저의 프로세스 debug  (0) 2013.04.05
GDB에서 특정 쓰레드만 멈추게 하는 법  (0) 2013.03.27
vi 설정  (0) 2013.02.22
Difftool  (0) 2012.12.17
No repository found in Eclipse  (0) 2012.11.27
Posted by 라판

Eclipse 속도 향상 팁

2013.03.06 16:07

참고로, eclipse.ini에 대한 위키는 여기를 참조:




* eclipse.ini 파일을 다음과 같이 수정

 원본수정 후 
-vmargs
-Dosgi.requiredJavaVersion=1.5 
-Xms40m  
-Xmx256m
-vmargs
-Dosgi.requiredJavaVersion=1.5 
-Xverify:none 

-XX:+UseParallelGC
-XX:-UseConcMarkSweepGC 

-XX:PermSize=32M
-XX:MaxPermSize=128M  
-XX:MaxNewSize=32M 
-XX:NewSize=32M 
-Xms256m  
-Xmx256m



* 설명

-Xverify:none                         // 클래스 검사 생략. 이클립스 실행 시간이 줄어든다.
-XX:+UseParallelGC               // Parallel Collector를 사용. 병렬 가비지 컬렉션.
-XX:-UseConcMarkSweepGC // 병행 mark-sweepGC 기능을 수행하여 GUI 응답 속도 처리
-XX:PermSize=32M                // 이클립스 클래스 로딩 기본 메모리
 
-XX:MaxPermSize=128M       // 이클립스 클래스 로딩 최대 메모리
-XX:NewSize=32M                 // JVM에서 새로운 객체가 생성 될때 로딩되는 최소 영역
-XX:MaxNewSize=32M           // JVM에서 새로운 객체가 생성 될때 로딩되는 최대 영역
-Xms256m                            // 이클립스 실행시 잡는 최소 메모리
-Xmx256m                            // 이클립스 실행시 잡는 최대 메모리

* Xms와 Xmx를 똑같이 잡아 주는 이유는 이클립스가 메모리를 유동적으로 관리하는데 이걸 정적으로 고정시켜 주기 위해서이다. 유동적으로 관리하게 놔두면 자바는 메모리가 부족할때 확보하려고 메모리 할당을 하게 되고 메모리의 여유가 있으면 남는 메모리를 조금씩 시스템으로 돌려버린다. 이러한 작업때문에 이클립스 속도가 더 느려지기에 아예 처음부터 최소값과 최대값을 고정시켜 버리면 불필요한 작업을 하지 않게 된다. 물론 메모리 값은 컴퓨터 사양에 따라 수정해주시면 된다. 




* 힙 메모리 정리
Window -> Perference -> General  에서 'Show heap status'에 체크.



체크를 해주면 이클립스 오른쪽 하단에 현재 메모리 사용량과 휴지통 아이콘이 생긴다.
힙에 메모리가 많이 쌓였을때 휴지통을 눌러서 한번씩 날려주면 빨라진다.






* 코드 오토 어시스트 기능 비활성화
 
코드 어시스트 기능을 끈다. 단축키 ctrl + space 로 코드 어시스트 사용가능하다.
Window -> Preferences -> Java -> Editor -> Code Assist tab 에서 'Enable auto activation' 을 꺼준다.

아래의 글은 Sun(Oracle?) Hotspot JVM을 기반으로 정리한 내용이다.

JVM에서 GC는 크게 Minor GC와 Major GC로 나뉜다. Minor GC는 Young Generation영역을 정리하는 GC이고, Major GC는 Old Generation영역을 정리하는 GC이다. 그리고 Major GC는 Full GC로도 불린다. 하지만 일부 CMS Collector를 설명하는 글에서는 Major GC와 Full GC를 구분하기도 하는 것 같다. Major GC와 Full GC의 명확한 구분은 잘 모르겠다.

                     Java Heap Memeory 구조


GC의 종류는 아래와 같다. 
===========================================================================================
1. Serial Collector
  - 단일 Thread로 GC 작업을 수행
  - "-XX:+UseSerialGC" 옵션 사용하여 활성화 할 수 있다. 
  - 요즘 H/W환경에서는 사용할 필요가 없는? GC라고 생각된다.
 
2. Parallel Collector
  - 복수의 Thread로 GC작업을 수행한다 
  - "-XX:+UseParallelGC" 옵션을 사용하여 Minor GC 에서 parallel collector를 활성화 할 수 있다.
  - "-XX:+UseParallelOldGC" 옵션을 사용하여 Major GC에서 parallel collector를 활성화 할 수 있다. 
  - 복수의 Thread를 사용하여 GC를 수행하기 때문에 Serial Collector에 비해서 GC가 빨리 수행된다.
  - 최대 성능을 내기 위한 GC라고 생각된다.

3. CMS Collector
  - Major GC 실행시 Application Thread와 GC Thread가 동시에 수행된다. (GC의 6단계 중에서 2단계에서만 Application Thread를 Block 하며 나머지 4단계는 동시에 수해된다.)
     * 참조 :  http://www.javaperformancetuning.com/news/qotm026.shtml
  - "-XX:+UseConcMarkSweepGC" 옵션을 사용하여 활성화 할 수 있다. 
  - Minor GC에서 Parallel Collector를 활성화하기 위해서는 "-XX:+UseParNewGC" 옵션을 사용해야 하며,  "-XX:+UseParallelGC" 와는 같이 사용해서는 않된다!!!
  -  Parallel Collector GC 보다는 최대 성능이 낮게 나오지만, GC로 인한 Application Thread 정지 시간을 최소화 하여 응답시간 지연을 줄이고자 하는 경우 사용된다.
  - CMS Collector에 의한 Major GC가 수행되는 동안 Application에 의해서 Old generation 영역이 꽉차게 되면, 모든 Application Thread를 멈추고, Full GC를 수행하게 된다.
===========================================================================================

JVM Heap 메모리 및 GC 옵션 예제
  - 최소 사이즈 : -Xms128m
  - 최대 사이즈 : -Xmx384m
 
 - GC 로그 옵션 
   > -verbose:gc -Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
  - Young Gen 영역을 위한 옵션 
    > -XX:NewSize=100m -XX:MaxNewSize=100m -XX:SurvivorRatio=32
  - GC 소요시간 최소화 옵션
    > -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:-CMSParallelRemarkEnabled
  - 성능을 위한 기타 추가 옵션
    > -XX:MaxTenuringThreshold=0 -XX:CMSInitiatingOccupancyFraction=60
  - OutOfMemoryError 발생시 자동으로 힙덤프 생성 옵션
    > -XX:+HeapDumpOnOutOfmemoryError -XX:HeapDumpPath=/path

JVM 옵션 상세 정보 참고자료 :  http://wiki.ex-em.com/index.php/JVM_Options

기타 툴
  - Java Stack Trace (dead lock 분석)
    > jps   [java 프로세스 확인]
    > kill -3 <pid>  [IBM JDK]

    > $JAVA_HOME/bin/jstack <pid>   [Hotspot JDK
  - Runtime JVM Heap Dump 생성
    > jmap -dump:format=b,file=heap.hprof [pid]
  - 힙덤프 분석 툴 : jhat, MemoryAnalyzer, visualvm

'' 카테고리의 다른 글

VMWARE workstation 7.1.4 patch for kerenel 3.1  (0) 2013.06.28
NX Client 속도 향상  (0) 2013.04.27
[명령어] 특정유저 프로세스 강제 종료 명령어  (0) 2013.04.08
NX 단축키  (0) 2013.04.05
Eclipse 속도 향상 팁  (0) 2013.03.06
Posted by 라판

이클립스를 잘 쓰고 있다. 파이썬을 짤 대, 한번 이클립스를 써보고 싶어서 시도했는데, Repository를 못 찾는다.

그러고보니 이전 이클립스 업데이트할 때도 그래서, 아예 새로 깐 적이 있었는데, 알고보니, 이미 버그로 등록되어

있었으며 우회법이 존재했다. 


hen doing Help->Install New Software and choosing the repository "Juno - http://download.eclipse.org/releases/juno", Eclipse always shows an error: 
No repository found at http://download.eclipse.org/releases/juno.

There is a work around, though: click on "Available Software Sites", select the "Juno" repository and click "Reload". Eclipse will now load the repository contents properly. When done, click OK and choose "Juno" from the Install New Software drop down menu again to get the cached content of the repository.

그래도 얼른 버그 고쳐주길! 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=370212

' > 개발' 카테고리의 다른 글

vi 설정  (0) 2013.02.22
Difftool  (0) 2012.12.17
No repository found in Eclipse  (0) 2012.11.27
[util] Makefile 에서 파일 존재 여부 체크하기  (0) 2012.07.05
unable to execute dex java heap space 에러  (0) 2012.01.04
Vim 명령어 리눅스/안드로이드  (0) 2011.12.09
Posted by 라판

참고 - http://wiki.eclipse.org/EGit/User_Guide#Rebase_Conflicts


Rebase 소개 

브랜치 A을 복사한 브랜치 B에서 작업 중, 누군가 브랜치 A에 커밋 하였다고 하자. 


 

                                          B'        A'

--o--o--o--o--o     Branch A

        |

         --o--o--o Branch B



향 후,  브랜치 B의 작업을 다시  브랜치 A에 반영하고 싶다면,  브랜치  B를 브랜치 A에 Merge해야 한다. 

그러나 아직, B의 작업이 끝나지 않아 반영하지는 않는다고 가정하자. 

대신 커밋 A'의 내용을 현재 B의 작업에 사용하기 위해,  브랜치 A을 B에 반영하기 원할 때가 있다.

아니면 향후 Merge 시의 무수한 충돌들이 염려되어 수시로 최신의  브랜치 A를  브랜치 B에 반영하면서 작업하고

싶다고 가정하자. 

 이럴 경우, 우리는 Merge 대신 Rebase을 선택하게 된다. Rebase 명령어의 동작 방식은 다음과 같다. 

  1. 브랜치 B의 커밋 B' 이후의 커밋들을 임시 저장하고  브랜치 B를 커밋 B' 상태로 되돌린다.
  2. 브랜치 B에  브랜치 A의 커밋 B' 이후의 커밋들, 즉 커밋 A'를 반영한다. 
  3. 1에서 임시저장한  브랜치 B의 커밋들을  브랜치 B에 반영한다.  

Rebase 후의 결과는 아래와 같이 우리가 원하는 결과를 볼 수 있다. 


 
                                          B'       A'

--o--o--o--o--o     Branch A

                      |

                       --o--o--o Branch B




Eclipse에서의 Rebase  방법

Image:EGit-0.10-StartRebaseFromRepoView.png

Eclipse의 EGit에서도 위와 같이 Rebase를 지원한다. Rebae 방법은 2가지가 있다. 

  1. Git 저장소 뷰에서나, 프로젝트의 Team 메뉴에서 Rebase를 선택하고 기준으로 삼기 원하는 브랜치, 혹은 커밋, 태그 등을 선택
  2. Git 저장소 뷰에서 기준으로 삼기 원하는  브랜치를 직접 선택



Eclispe에서 Rebase 충돌 해결 방법 

  그러나 실제 작업 중에는 위와 같은 Rebase 중 충돌이 일어날 때가 많다. Merge 때와 마찬가지로, 충돌을 해결해야 하는데, 

Eclipse에서 충돌을 해결해도 계속 문제가 발생하여 한참을 헤맨 적이 있다. 알고 봤더니, 본인은 문제가 일어나는 파일들을

수정을 했지만, 이것을 Git의 index 상에 반영하기 위한 작업을 하지 않았던 것이 문제였다. ㅡ.ㅡ 굳이 Eclipse가 아니고 리눅스 환경에서도 동일한 작업이 필요한데, 바로 충돌 해결 후, git add 를 해주어야 index에 제대로 반영된다. 그제서야 Merge 든 

Rebase든 진행이 가능하다. Eclipse에서 Rebase 중 충돌이 일어나면 다음과 같은 다이얼로그가 뜬다. 


위의 Action to perform에서 보듯이 현재 문제가 되는 커밋만 제외하고 계속 Rebase를 진행하거나, Rebase를 취소할 수도 있다. 

충돌을 해결할려면 Merge때와 같이, Merge Tool을 이용하면 된다. (혹은 Do nothing을 선택하여 직접 문제가 되는 부분들을 찾아 수정할 수도 있다.) 

여기서 중요한 포인트는, 모든 수정이 끝났으면, 꼭 Git Add를 해준다는 것! Eclipse 상에서는 다음 절차를 따른다. 

  1. 위의 Start MergeTool to resolve conflicts을 선택하여 MergeTool을 통해 수정하거나, 충돌이 일어난 파일을 수동을 찾아 직접 수정하여 충돌 해결
  2. Project의 Team Menu->Add to Index 선택 
  3. Project의 Team Menu -> Rebase -> Continue Rebaes 선택 

이 방법을 몰라 어제 작업 중 2시간을 날려 먹고, 결국에는 충돌나는 파일을 백업해놓고 지운 다음, 다시 Merge하는 등 온갑 삽질을 다하였다. Merge 시에도 위의 2번만 알았다면 파일을 백업해놓는 추태는 벌이지도 않았을텐데. 아쉽다; 

  개인적으로는, Merge 시 발생하는 Merge 커밋이 보기가 싫어 Rebase를 더 선호하는 편이다. 물론 Merge 커밋을 안 보이게 할 수도 있지만, 따로 옵션을 주는 것이 번거롭기도 하고, 변경 이력 관리도 Rebase가 더 깔끔하게 느껴지는 것 같다. 

앞으로 프로젝트에 자주 참고해야겠다!     

Posted by 라판