빡쎄 이뤄 낸다 는건

samba 서버 사용중 묘하게 버퍼 케시 메모리가 높게 나와서 의야해 했다. 처음엔 메모리가 부족해서 그런가? 싶어서 증설하였으나 똑같은 증상을 보였다. 여유 있는 메모리들이 얼마 없어서 메모리 증설을 하였으나 자원이 들어오는 족족 buff/cache 에 맵핑 되는걸 확인 할 수 있었다. 단순히 메모리의 문제인가 아니면 buff/cache 의 문제인가 잘 몰라서 알아보도록 하자. buff/cache는 뭘까? 일단 buff란 프로세스가 사용하는 메모리 영역이 아니고 시스템 성능향상을 위해 커널에서 사용하고 있는 영역! 이다 cache는 페이지 캐시라 불리는 캐시 영역에 있는 메모리 양을 위미한다 I/O관련 작업을 더 빠르게 진행 하기 위해 커널에서 사용하고 있는 영역이다. 자 그러면 사용자 확인을 해보자 ..

유저 메모리 tmpfs 는 물리 메모리를 사용한 RAM 디스크 기능을 제공한다. tmpfs 는 파일 시스템으로서 마운트하면 일반적인 파일 시스템과 같은 파일의 읽기 쓰기가 가능 하지만 파일은 서버의 하드에 저장됨 tmpfs에 파일을 저장하면 시스템은 파일을 우선 디스크 캐시에 저장하게된다 이것이 Shmem 이며 디스크 캐시를 의미하는 buffer+cached로 분류됨 하지만 이것에 대응하는 물리디스크의 영역은 없으므로 File-bached 메모리가 아니라 Anonymous(Active[anon] + inactive[anon]) 메모리의 LRU리스트에 등록된다. 이것이 File-backed 메모리의 합계와 buffer+cached 값의 차이가 된다. tmpfs가 사용하는 메모리가 Shmem인 이유는 리눅스..

S3를 선택후 버킷을만들어준다. 버킷 이름은 전역 수준이며 고유한것이라 겹치지 않아야 한다. 버킷 이름을 설정해주고 Public Access 설정에서 해제 후 인지했다? 알고있다? 라고 뜨는 경고 문을 읽고 체크 버킷을 생성한다. 버킷을 만든 다음 누르면 속성에 들어가서 정적 우베 사이트 호스팅을 선택후 이 버킷을 사용하여 웹 사이트를 호스팅합니다 을 선택한다음 알맞은 값을 입력해준다. 서버에 인덱스 파일명 마다 다 다르니까 index.html 기본적인 설정으로 넣어줌 그후 저장 선택 개요에 가서 업로드 선택후 파일들을 올려주자 그후 파일들 선택후 작업에서 "퍼블릭으로 설정" 을 해줌 이후 들어가보면 정상적으로 뜬느걸 확인 할 수 있다.

기본적으로 WAS서버 구성은 인터넷에서 HTTP 트래픽이 WAS 서버로 들어온다. 그러면 WAS 서버가 연결된 DB에 정보를 요청하여 재공하는 형태로 운영이 되는 데 그림설명 하자면 아래와 같다 AWS에서는 보안 그룹을 지원하는데 위 그림에 보안 그룹안에 WAS서버와 DB서버들의 보안 그룹을 만들 수 있으며 접근하는 트래픽을 보안그룹에서 관리할 수 있다. 위 그림과 같이 작업순서는 1.각 파트 별 보안 그룹 생성 2. EC2 로 WAS 서버 생성 후 해당 보안 그룹 적용 3. RDS로 DB 서버 생성 후 해당 보안 그룹 적용 4. 호환 테스트 정도가 될거 같다. 처음으론 각 파트별 보안그룹 생성이다 EC2를 누른 후 리소스에 보안그룹을 선택해준다 그후 기본 세부 정보를 기입후 인바인드 규칙을 설정해준다...

메모리 관리의 기본이 되는 물리 어드레스 공간과 논리 어디레스 공간이 있다. 서버의 물리 메모리는 리눅스 커널 자신이 사용하는 영역과 유저 PS가 사용 하는 영역으로 나눠진다 리눅스 커널은 Low메모리로 불리는 1MB~896MB의 영역에서만 사용하고 그 이외엔 유저 영역인 High메모리 라고 불린다. 커널자체를 포함해 서버에서 동작하는 프로그램이 물리 메모리에 접근할때 물리 어드레스를 직접 지정하는 것이 아니고 논리 어드래스를 사용한다. 물리어드레스에 접근할 때 논리어드레스와 물리어드레스의 대응표인 페이지 테이블을 메모리의 커널 데이터 영역에 준비한다. 그리고 CPU에 탑재된 MMU(메모리 메니지먼트 유닛)가 페이지 테이블을 참고하며 물리 어드레스로 접근한다. 이때 커널이 사용하는 Low메모리 영역은 페..

파이프라인의 구조를 이용함으로써 다양한 부분을 자유롭게 조합이 가능해진다. 프로그램의 출력처 -표준출력stdout -애러출력stderr -표준입력stdin 표준입력은 터미널에서 키보드로 입력하는 것이고 입력받은 표준입력에서 명령어가 stdout와 stderr을 통해 화면에 나타나게 되는데 이때 파이프를 써서 동작하게 되면 stdin에서 명령이 들어오면 psA가 stderr로 출력하고 stdout을 출력하게 되는데 여기서 stdout 출력이 psB에 stdin으로 들어가서 stderr와 stdout으로 출력된다. 기본적으로 파이프라인과 같이 사용하기 좋은 커맨드 들은 cut awk grep head tail paste sort tr uniq wc 정도 인거 같다.

리눅스로 프로세스를 생성하는 방법에는 fork 와 exec 가 있다. exec의 경우 - 자신을 변화 시킨다! 프로세스 PID는 같으나 프로그램이 변한다 fork의 경우 - 자식 프로세스를 만든다! 똑같은 프로그램을 실행시키는데 프로세스가 두 개로 나뉜다 여기서 부모 프로세스 자식 프로세스로 나뉘게 되는데 자식 프로세스는 PID가 다르다. 예를 들어 로그인 프로세스인 mingetty의 활동 상태를 살펴 보면 로그인 전 프롬프트 화면에 "hostname login : "라고 처음으로 보일 것 인데 mingetty의 ps라고 생각하자 여기서 로그인 성공시 exec가 일어나서 로그인이 된다 이 경우 PID는 그대로 이면서 실행 프로그램만 바뀌게 되고 로그인이 일어난 후 자식 ps인 -bash도 만들게 되는데 ..

I/O 서브시스템의 전체 적인 모습 위 서브시스템의 구조에 대해 살펴 보자 VFS 레이어에 파일 시스템과 디스크 캐시, 블록 레이어에 속한 I/O 스케줄러 디바이스 드라이버의 상호 작용이다 우선 파일에 데이터를 쓰는 경우, 파일에서 데이터를 읽는 경우를 나눠 생각 해 보자 -데이터를 쓰는 경우 파일 시스템의 파일에 데이터를 쓸 경우 1. 그 내용을 먼저 메모리의 디스크 캐시에 쓴다. 2. 데이터의 읽고 쓰기를 요청한 애플리케이션 프로그램(PS)은 이 단계에서 데이터를 읽거나 쓰는 동작을 맞쳤다고 생각하고 처리를 계속한다. -디스크 캐시에 기록되어 있을 뿐 아직 물리 디스크에는 기록되지 않는 데이터가 생긴다 (이를 더티 데이터라 한다) - 디스크 캐시에 더티데이터가 어느정도 쌓이게 되면 I/O 스케쥴러에게..

디스크에 대한 섹터 기존의 하드는 1섹터당 512byte로 되어있어 하드 디스크에 접근하는 측의 서버, 하드웨어, OS등은 512바이트의 섹터 크기로 설계 되어있다. 하지만 점차 디스크 용량이 커지며 단점들이 보이는데 이를 완화 시키키는 방법이 4KB 섹터를 사용하는것 이다. 일단 대용량에 디스크에 섹터 사이즈가 커지게 되면 오버헤드를 줄일 수 있고 부가 정보가 차지하는 비율을 줄이고 기록 영역을 더욱 효과적으로 활용 할 수 있다. 4K는 기존에 설계 되어 있는 512방식에 대한 하드디스크에 내장된 컨트롤러가 논리적으로 512바이트 섹터들을 에뮬레이션 하는 방식을 사용한다. (512바이트논리 섹터들이 8개 모여 4K섹터가됨) 때문에 기본적으로 파티션의 시작 지점과 사이즈는 논리 섹터 수로 생각한 8의 배..

후속작이 나온 간단한 이유 : 시스템 BIOS가 사용할 수 있는 메모리의 한계 때문 UEFI에 들어와선 부트스트랩 로더의 로딩 방법도 변경되어 GRUB 스테이지1, 1.5, 2으로 단계적 부트로더를 가동할 필요가 없어졌다. GPT 기존 파티션 테이블 0섹터의 MBR에 저장되 있지만, GPT는 1섹터부터 33섹터에 기록하는 새로운 타입의 파티션 테이블이다. 위와 같은 그림을 가졌다 . 그럼 기존 파티션과 무엇이 달라 졌을까 기존 파티션 GPT 파티션 테이블 장소 MBR MBR 바로 뒤(디스크 끝에 복제) 최대 디스크 용량 2TB 8ZB 최대 파티션 수 15 128 파티션 라벨 파티션 ID GUID 파티션 작성 툴 fdisk parted 기존 파티션에 대한 메모리 한계는 없어졌다고 보면된다. (최대 용량 디..