오류메세지를 읽고 해결을 하려고 시도를 하겠지만 그것이 root cause는 아닐 수 있다.
파일 생성이 안되는 이유가 권한이 없거나 스토리지가 부족해서 일 수 있기 때문이다.
- 문제상황파악 구조화
- 관찰 열거 단계 절차
원래 어떻게 되는지를 알아야 진단을 할 수 있다.
메모리문제를 해결하려면 원래 메모리가 어떻게 동작하는지 알아야 한다.
이런 것들을 통해서 기준을 잡고 구글링을 하면 더 의미있게 삽질을 할 수 있다.
네트워크 동작 과정을 이해하고 구간과 구간사이에 무슨 일이 일어나는지 나열할 수 있어야한다.
- 서버와 클라이언트
서버가 실행이 되어야한다. nginx나 tomcat이 될 수 있다.
서버가 실행이 되면 클라이언트 접속이 있을 때 까지 waiting을 한다. 이걸 Blocking IO 라고 한다.
Blocking IO 라는 것은 cpu가 슬립해서 cpu를 놓고 프로세스가 슬립을 해서 기다리느냐 아니냐의 차이점이 된다. 그럼 결국 클라이언트에게 동작이 오지 않기 때문에 보통 Standby 상태로 슬립하고있다. 패킷이 오면 wake up 되면서 처리를 시작한다.
클라이언트 사이에서는 Non-Blocking IO를 한다. 브라우저가 Blocking IO를 하게 되면 IO 요청이 끝날 때까지 프로세스가 sleep하고 기다리기 때문에 사용자 입장에서는 버벅인다고 느낄 수 있다.
그래서 자바스크립트나 ajax 같은 곳에서 Non-Blocking IO를 주로 사용하게 된다.
어차피 I 요청할 때까지 좀 오래 걸리기 때문에 다른 작업도 병렬적으로 진행하게 되기 때문이다.
관련 자료 링크: https://etloveguitar.tistory.com/140
3 hand shake를 통해서 connection이 이루어진 이후 어플리케이션 레벨에서 curl이나 GET요청이 발생한 경우, 데이터가 커널 안으로 들어가게 된다 이것을 버퍼 push (소켓 안에 있는 버퍼) 소켓은 네트워크를 다루게되는 커널의 자료구조를 지칭하게 된다. 이때 버퍼가 두 가지 종류가 있다. Receive 버퍼와 Write 버퍼 두 가지 종류가 있다. Send 버퍼로서 큐잉이 된다. 이때 큐잉이 된 Send 버퍼와 Receive 버퍼를 확인하는 방법이 있다. 이게바로 ss명령어이다.
소켓의 상태를 확인할 수 있으면서도 Receive Q와 Send Q를 볼 수 있다.
이 부분이 결국 커널 안에서 네트워크 자원을 관리하게 되는 소켓 안에 있는 Receive와 Send 버퍼를 지칭하게 된다.
개념만 알아도 안되고 진단하는 방법만 알아도 안된다. 개념을 알고 그것을 추적하고 진단하는 방법을 맵핑시키는 것이 중요하다고 할 수 있다.
- tshark
- ss
- netstat
- tcpdump
- tracepoint
이렇게 패킷이 버퍼에 들어 왔으면 패킷이 데이터에 대해서 완성을 시키기 위해서 헤더를 붙인다. 그런 과정들을 커널 안에서 하게 된다. 커널에는 L4/L3/L2가 구현이 되어있고 그 과정에서 패킷이 일단 구성이 된다.
Eth IP TCP 데이터 (HTTP message)
쉽게말해 우편물이 있으면 주소지도 합쳐진다는 이야기이다.
SyscallVFSSockTCP: L4IP: L3DD: L2
이렇게 완성된 패킷이 밖으로 나오게 된다.
이것을 구간을 나누게 되면 첫 번째는 어플리케이션이다. 가장 대표적인 것인 http 통신 방식이다.
그 다음 밑으로 내려와서는 커널레이어이고 TCP 레이어에서 벌어지는 일도 있을 것이고 IP 레이어에서 벌어지는 일들도 있다. 크게는 이런 것들을 커널 구간으로 나눌 수 있다.
그다음 패킷이 나가게 되면 하드웨어 레벨로 떨어지게 된다. 그러면 첫 번째로 내가 갖고 있는 네트워크 하드를 기준으로 처리가 되는 로컬하드웨어 레벨이 있을 수 있고 이게 게이트웨이로 빠져나가면 게이트웨이 장비에 보안 설정에 영향을 받을 수 있다.
그리고 이게 패킷의 라우터의 라우터를 거치면서 외부로 나가게 되는데 그런 라우터들에게도 영향을 받을 수 있다. 왜냐하면 mtu라고 하는 보내는 사이즈 때문에 패킷을 1000 사이즈를 보냈더라도 700/300 이렇게 나눠질 수가 있다.
결국 이런 것들이 머릿속에 정립이 되어 있어야 한다.
그래야지 네트워크에 1부터 100까지 알고 있다고 할 수 있다.
깊이는 어느정도 조절을 해야겠지만 1부터 100까지 다 알고는 있어야 한다. 그래야 빈틈없이 진단을 내릴 수 있다.
라우터와 라우터를 거치는 것을 확인할 때 traceroute라는 명령어를 통해서 확인도 가능하게 된다.
이렇게 패킷이 도착하게 되면 (tx, xmit, transmit) 인터럽트가 발생하게 된다. 인터럽트가 발생하고 난 후 인터럽트를 처리하는 것은 두 구간으로 나뉘게 된다. Top-Half, Bottom-Half 이다.
용어상으로는 반반인것 같지만 실제로는 hi가 top half si는 bottom half이다. 거의 99.9%는 Bottom-half에서 처리를 하게 된다. 여기에 netfilter 로직들도 존재한다.
netfilter가 포워딩이나 패킷을 드랍한다던지 화이트리스트 블랙리스트를 관리할 수 있다. iptables를 통해서도 제어를 할 수 있다. 이런것들이 Bottom half이다.
tshark
tshark를 통해서 추적할 수 있다.
tcpdump, netstat, ss 명령어가 존재한다.
연습할 때에는 ping www.google.com을 할 때 발생되는 과정을 추적하는것도 공부가 될 수 있다.
arp, dns, icmp를 한다라고 하는걸 이해하는 등등..
소켓상태를 확인하려면
netstat
ss
trace point
해당 내용은 여기서 따로 정리하겠다.
https://velog.io/@repush/%EB%AA%A8%EB%8B%88%ED%84%B0%EB%A7%81%EC%9D%84-%EC%9C%84%ED%95%9C-%EB%A6%AC%EB%88%85%EC%8A%A4-%EB%AA%85%EB%A0%B9%EC%96%B4
inode 생성 한계
df -h
df -i
디스크의 용량 뿐만 아니라 파일의 갯수로도 한계가 존재할 수 있다.
이런 상황을 통해 단순한 확인 명령어로는 트러블슈팅을 할 수 없다는 것을 이해하고 인프라, 리눅스 서버의 제약사항을 이해하고 그 이해를 기반으로 트러블 슈팅을 한다면 훨씬 빠르게 원인을 찾아낼 수 있을것이다.
