리눅스 전반적인 운영체제 복습
리눅스 역할 2가지
- App관리, HW관리(cpu, ram, disk, net)
리눅스 실체 → c코드 → 10만개 / proc/kallsyms → 300~400개 → 시스템콜(open, read, write) 컴파일해서 결과물은 vmlinux(가상메모리 메커니즘을 지원)으로 나온다.
가상메모리 메커니즘의 배경이 될 수 있는 ABI (application binary interface) 바이너리를 만들때 규약, 규칙을 만드는데 OS,CPU,컴파일러가 규칙을 만들어서 ELF, syscall number(함수호출규약- 여러가지 레지스터를 어떻게 사용할건지), calling convension, 가상메모리 매커니즘
- 컴파일러
- PA 기반 컴파일러 입장에서는 물리주소로 컴파일하면 실행이 한정적이다.
- VA 기반 컴파일하면 어디서든 실행이 된다.
실행하게 되면 OS가 프로세스를 실행하면서 자료구조 task_stuct 를 만들고 거기 딸려있는
- mm_struct(text, heap, stack vma 를 만듬) - 이런 것들을 확인할 수 있는 방법 /proc/[PID]/maps (가상주소 기록만 함) 를 통해서 확인가능
- VA-PA매핑, 변환테이블(페이지 테이블)이고 기본적으로 깡통으로 둬서 후매핑 방식으로 사용 - ps -eo pid,comm,vsz,rss | head -2 를 통해서 확인가능
OS준비하고 CPU가 VA 를 통해 CPU 내부에 있는 MMU에게 준다 이것은 현재 페이지테이블을 찾아서 VA-PA 변환시도를 한다. 변환실패하면 MMU 를 통해 pagefault 를 통해 예외처리로 페이지 폴트 핸들링을 한다.
페이지 폴트 핸들링
- 페이지폴드 핸들링(VA검사를 통해 유효한지 mm_struct 사용해서 확인하고 유효하지 않다고 판단되면 segfault
- 유효하다고 판단되면 페이지(4KB, 0x1000, 12bit, 2^12, 4096) 한조각 할당
- huge page 설정이 되어있다면 512개를 한번에 할당할 수 있다. // VA-PA 매핑 기록을 페이지 테이블에 기록한다.
결론적으로 컴파일러는전세계있는 PA를 모르기떄문에 VA 기반으로 한번 컴파일하면 알아서 변환해서 써라고 OS, CPU 에게 던져주는 구조이다.
던져주면 OS 는 mm_struct, page table을 준비하고 CPU는 MMU를 통해서 변환을 제어하고, 변환에 대한 이벤트가 발생하면 OS 수습 → CPU
구성
core
- PM 프로세스 관리 → task_struct 를 사용한다 CFS 스케쥴러(virtual run time 이라고해서 최소값을 선택하는 방식
- MM 메모리관리 → mm_struct(vma, vma, vma … / 페이지 테이블(VA-PA) / 시스템 이벤트 핸들러 : 인터럽트: 네트워크, USB, 타이머 // 예외처리 : syscall , pagefault 부팅한 이후에는 숨쉬듯 계속 발생해서 예외처리를 해야함
결국 이벤트핸들러는 우렁각시 같은 것이고 주인공은 nginx, mysql 같은게 주인공이다. 그래서 메모리를 계속 물고 있으면 안된다 → 그래서 탄생한게 TH( top half : 전반부), BH (bottom half: 후반부 작업(나중에 호출해도 되는 커널, 함수 미루기 - 대표적으로 workqueue(다양하게 계층적으로 처리 (kworker), softirq (8개의 함수밖에 못미뤄서 유연성 떨어짐 - ksoftirqd), tasklet(유연성은 있지만 큐가 2개밖에 없음) )
I/O
- 네트워크
- L4 TCP
- L3: IP,netfilter(iptables 명령어를 제어하고, 블랙리스트, 화이트리스트, 디도스 공격 등을 제어가능 아이피 대역에 대한 관리)
- L2:MAC
- 디스크 (VFS, FS, Block FS) //
- 파일시스템: 디스크 블록을 어떻게 read/write할지 전략, 규칙을 세우는 것 (대표적으로 ext4, xfs, f2fs, btrfs)
- 디바이스 드라이버
기타 : 도구, 사운드, 보안
traceroute www.google.com
아이피가 두개가 적혀져 있는 이유는 혹시 모를 상황을 대비하는 것
traceroute는 ICMP로 동작한다. → ICMP 를 응답하지 않는 것들은 응답을 받지 못할 수 있다.
웹서버는 TCP 사용하기 떄문에 www.naver.com 같은 일반 사이트는 응답받지 못한다. 하지만 google은 예외.
보통 웹서버는 ICMP 를 안받기 떄문에 정상적으로 안된다.
웹서버(nginx, httpd) ↔ 웹 어플리케이션 서버(WAS) ↔ DB(mysql, postgresql …)
C코드 → HTTP 통신은 기능이 많다 예를들어 결제, 로그인 정보조회기능 등 보통java(spring), python(django), js(nodejs, next.js) 등을 사용한다. 프레임워크는 미리 짜놓은 코드
캐시(HTML, 이미지…)
(1) 포트번호 살아 있는지 확인하기
- sudo netstat -tplan | grep 3000
(2) nginx 상태확인
- sudo service nginx status
(3) nginx 설정적용
- sudo service nginx reload
(4) nginx 재시작
- sudo service nginx stop && sudo service nginx start
- GitHub 오픈소스 spring 프로젝트 소스 다운
- java 소스 → 빌드 → jar → java~~.jar → 스프링 → 내장 tomcat → WAS 실행
- 8080 포트 확인
- 웹서버 테스트 확인
- 나의실습환경 → 웹서버 테스트 확인
리눅스 서버 1대 ←—- 여러개의 터미널로 접속가능하다.
터미널을 끄면 java 서버가 꺼지는데 터미널을계속 켜놔야하는가?
- 우리가 java 실습한 건 테스트서버로 실행
- 배포할때는 service 활용, daemon 프로세스
- nohup → 백그라운드
프로세스 강제종료
kill -9 (number)
Node.js 설치와 웹 애플리케이션 테스트
성능부하테스트
sudo dnf install -y bmon / httpd-tools / hping3 / iftop
터미널 1 : bmon 모니터링
터미널 2 성능부하테스트 : ab -n 1000 -c 100 http://localhost/
loadavg → 시스템 부하가 어느정도
1분, 5분, 15분 → 평균 → 코어의 개수 → nproc
R / D(Disk sleep = Disk I/O 처리가 늦어지고 있다는 말) 상태의 프로세스가 많을때
wa 가 높아지는경우 → I/O 기다리는 시간이 길어진다.
- used : heap, stack 처럼 순수메모리 사용량 (Anonymous)
- free : 미사용공간
- buff/cache : 디스크 블록을 임시적으로 저장해두는용도 (Pagecache 용도)
buff/cache 비우기
- echo 3 › /proc/sys/vm/drop_caches
drop_caches 를 했는데 왜 buff/cache 가 남아있는가? -> 현재 돌아가고 있는 프로세스들이 있다. 아래의 명령어를 통해 실행중인 프로세스 확인 가능
ps -ef | wc -l
- Buffered I/O: 파일 입출력을 할 때, 데이터를 직접 디스크에 쓰지 않고 메모리에 버퍼를 사용하여 효율적으로 처리합니다. 이 과정에서 페이지 캐시를 활용하여 성능을 향상시킵니다.
- Dirty 페이지: 메모리에서 수정된 데이터(Dirty 페이지)는 디스크와 동기화되지 않은 상태입니다. 이러한 페이지는 주기적으로 디스크에 기록되며, 이 과정을 "writeback"이라고 합니다. 기본적으로 5초마다 수행됩니다.
- Available 메모리: 사용 가능한 메모리 양을 나타내며, 유저 프로세스가 사용할 수 있는 메모리의 추정치입니다. 이는 free, buff/cache에서 시스템 예약 메모리를 빼서 계산됩니다. 따라서 free 메모리가 많더라도, 실제 사용 가능한 메모리는 더 적을 수 있습니다.
- 메모리 관리: 시스템의 메모리 상태를 지속적으로 모니터링하고 관리하는 것이 중요합니다. available 수치가 낮으면 성능 저하를 초래할 수 있으므로, 필요 시 프로세스를 종료하거나, 메모리 사용을 최적화하는 방안을 고려해야 합니다.
Direct I/O vs Buffered I/O
- Direct I/O : CPU가 DISK 로 바로 때리는 방식
- Buffered I/O : CPU가 DRAM 을 거치고 DISK 를 가는 방식 ( DRAM에 자주 access 하는 게 메모리에 남겨져 있어서 buffered 가 direct보다 빠르다.
네트워크 패킷 전송 과정:
목적지 IP 주소 필요 → 나의 IP 주소192.168.0.12 , 서브넷마스크를 통해 외부망 안에 포함되는지 내부망에 포함되는지 확인을 한다.
- 192.168.0.15 내부망일 경우 → ARP 브로드캐스트 → ARP 통해서 whohas 192.168.0.15 를 누가 가지고 있는지에 대한 패킷을 뿌림 → ARP → 192.168.0.15의 MAC 주소를 획득 → ARP 테이블에 저장
- 8.8.8.8 → 외부망인걸 확인 → ARP 브로드캐스트 → ARP 누가 게이트웨이인지에 대한 내용의 패킷을 뿌림 → ARP → 게이트웨이의 MAC 주소를 획득한다.
ICMP L3(네트워크 계층) 통신
DNS
TCP
4 way handshake
HTTP GET 요청(패킷 1개) / 응답(패킷 1개) 라면
총 몇개의 패킷을 주고 받은걸까
3개(3way hand) + 2개(connection) + 4개 (4way hand) = 9개
ARP broadcast
ping 10.0.2.17 (목적지 아이피주소)
나의 IP 주소 10.0.2.15
목적지 IP 주소 10.0.2.17
출발지 MAC주소는 (나의 MAC주소)
내부망에 있는 10.0.2.17 에게 ICMP 패킷을 전송한다는 말
패킷전송을 하려면 목적지 MAC 주소가 필요하다. → 어떻게 알아내냐면 ARP 브로드캐스트 를뿌려서 알아낸다. (누가 10.0.2.17을 가지고 있어? whohas)
