리눅스에서 할당된 논리적인 볼륨 크기를 조정하는 법을 정리한다.
테스트서버 : Ubuntu22.04 작성일 : 2023-02-23
1> 디스크 용량을 확인
df -h
2> 논리적인 볼륨 크기 조정
# 100%로 조정
lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
# 적용
resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv
3> 현재 디스크 블럭의 정보를 확인
lsblk
JMeter를 통해 성능테스트 하는 방법을 정리한다.
테스트클라이언트 : Windows10 + JMeter5.5 테스트서버 : Ubuntu22.04 작성일 : 2023-01-09
1> 아래 사이트에 접속하여 바이너리 파일을 다운로드 하고 압축을 해제한다.
https://jmeter.apache.org/download_jmeter.cgi
apache-jmeter-5.5.zip 파일 압축해제
2> JMeter 실행
압축해제 폴더/bin/jmeter.bat 실행
3> Thread Group 추가
Test Plan 우클릭 > Add > Threads(Users) > Thread Group
Number of Threads (users) : 사용자수
Ramp-up period (seconds) : 요청 반복주기
Loop Count : 반복횟수 (Infinite 체크시 무한반복)
※ 위와 같이 설정하면 10명의 유저로 10초에 한번씩 100번을 반복해 호출한다.
4> 요청값 설정
추가한 Thread Group (OpendocsTest) 우클릭 > Add > Sampler > HTTP Request
Protocol / Server Name or IP / Method(POST or GET) / Path / Parameters 입력
5> Listener 추가 (결과 확인)
Test Plan 우클릭 > Add > Listener > 유형선택
① ~ ⑥의 유형은 아래와 같은 결과를 보여준다.
① View Results Tree : 요청별로 상세정보를 확인할 수 있다.
– 결과값 / 요청값 / 응답데이터 확인가능
– 전체 요청에 대한 검색기능 제공
② View Results in Table : 모든 결과를 Table로 보여준다.
– Sample : ID번호
– Start Time : 부하 시작시간
– Thread Name : Thread Group Name
– Label : request 이름
– Sample Time(ms) : 요청 시작부터 응답 종료까지의 시간
(Load Time, Elapsed Time, Response Time 과 동일한 의미)
– Status : 응답 상태
– Bytes : 응답 데이터 바이트
– Sent Byte : 요청 데이터 바이트
– Latency : 요청 시작부터 응답 시작까지의 시간 (지연 속도)
– Connect Time(ms) : TCP Handshake 이후 연결된 시간
– No of Samples : 처리중인 데이터의 수
– Latest Sample : 가장 마지막 Sample Time
– Average : Sample Time 평균
– Deviation : Sample Time의 표준편차
③ Graph Result : 대략적인 그래프
④ Summery Report : 결과 레포트
– Samples : requset 갯수
– Average : Sample Time 평균
– Min : Sample Time 최소
– Max : Sample Time 최대
– Std. Dev. : Sample Time 표준편차
– Error % : 에러율
– Throughput : 시간당 처리량
– Received KB/sec : 시간당(sec) 받은 데이터(KB)
– Sent KB/sec : 시간당(sec) 보낸 데이터(KB)
– Avg. Bytes : 평균 바이트
⑤ Response Time Graph : 지속적인 추세 확인
프로세스를 종료 하였음에도 메모리가 정상해지 되지 않았거나 프로세스 엔트리에 남아 실행되고 있는 경우 이를 제거 하는 방법을 정리한다.
테스트서버 : Ubuntu22.04 작성일 : 2023-01-03
Zombie On Unix operating systems, a zombie process or defunct process is a process that has completed execution but still has an entry in the process table, allowing the process that started it to read its exit status. In the term's colorful metaphor, the child process has died but has not yet been reaped. When a process ends, all of the memory and resources associated with it are deallocated so they can be used by other processes. However, the process's entry in the process table remains. The parent is sent a SIGCHLD signal indicating that a child has died; the handler for this signal will typically execute the wait system call, which reads the exit status and removes the zombie. The zombie's process ID and entry in the process table can then be reused. However, if a parent ignores the SIGCHLD, the zombie will be left in the process table. In some situations this may be desirable, for example if the parent creates another child process it ensures that it will not be allocated the same process ID.
1> zombie 프로세서 확인
top
# ----------------------------------------
top - 10:13:56 up 4 days, 16:19, 2 users, load average: 0.08, 0.53, 3.08
Tasks: 246 total, 1 running, 245 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.2 us, 0.7 sy, 0.0 ni, 97.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
# ----------------------------------------
zombie의 숫자가 1이상이라면 pid 를 확인하여 kill 해야한다.
2> pid 확인
ps axo stat,ppid,pid,comm | grep -w defunct
# ----------------------------------------
Z 544478 545217 ruby <defunct>
Z 544478 547937 ruby <defunct>
# ----------------------------------------
3> kill 프로세스
kill -9 544478