' 분류 전체 보 기 ' 카테고리 의 글 목록 ( 2 Page ) : : Platform Engineer 
 ESXi Internal 2018 . 10 . 20 
 Dtrace 가 Windows 에 도입 되 었 습니다 . 2018 . 10 . 10 
 부팅 과정 및 복구 ( Grub ) 2018 . 06 . 17 
 성능 모니터링 ( sysstat , sar ) 2018 . 06 . 16 
 IO 부하 ( iostat , iotop ) 2018 . 06 . 06 
 시스템 부하 확인 ( uptime ) 2018 . 06 . 02 ( 2 ) 
 명령 줄 툴 인 Handle 을 사용 해서 핸들 수 파악 하 기 2018 . 03 . 17 
 2018 . 10 . 20 16 : 12 
 최근 에 VMware 제품 인 ESXi 를 공부 해야 할 필요 가 생겨서 공부 를 하 면서 정리 를 해 보 았 습니다 . 이제 공부 를 처음 시작 하 는 것 이 기 때문 에 어떤 내용 들 을 정리 할 수 있 을지 정하 지 는 않 았 지만 최대한 많이 자료 를 접하 면 정리 가 될 것 같 습니다 . 
 VMware world TA 8245 - ESXi Internals - Better Understanding for Better Management and Troubleshooting 
 자료 가 VMworld 2010 자료 라 현재 는 내용 이 달라졌 을 수 있 습니다 . 큰 그림 은 바뀌 지 않 았 으리라 생각 하 고 정리 해 봅니다 . 
 Olivier Cremel 이 라는 VMware 의 Principal Engineer 가 발표 를 하 는데 Linkedin 을 보 니 Google 로 갔 다가 다시 VMware 로 컴백 을 했 습니다 . 
 어떤 부트 디바이스 일 경우 에 도 단일 부팅 이미지 로 되 어 있 고 모든 내용 이 메모리 로 로드 가 된다고 합니다 . 그래서 부트 디바이스 에 문제 가 발생 하 더라도 운영 에 문제 가 없 다고 합니다 . Windows 의 경우 에 는 일부 시스템 이미지 가 로드 되 지 않 은 상태 이 고 페이지 아웃 까지 가능 해서 부팅 디바이스 가 문제 가 생가 면 1 분 안 에 시스템 이 크래시 됩니다 . 아무래도 가상 화 부분 만 담당 하 기 때문 에 좀 더 안정 적 으로 만들 수 있 었 던 것 같 습니다 . 
 ESXi 의 베이스 이미지 는 압축 되 어 있 고 메모리 에 압축 이 해제 되 어 로드 가 됩니다 . VIB ( VMware Installation Bundles ) 파일 은 압축 이 해제 되 지 않 고 Tardisks 라는 방식 으로 Mount 됩니다 . ( https : / / blogs . vmware . com / vsphere / 2011 / 09 / whats - in - a - vib . html ) 
 / etc 디렉 토리 에 있 는 파일 들 은 persisted state files 로 ( esx . conf , inetd . conf ) tardisk 에 위치 라며 sticky 로 설정 된다 . / var / spool / cron / root / cronjobs 와 같 은 파일 등 은 running state 가 유지 되 지 않 는다 . persisted state file 들 은 root filesystem 에 마운트 되 고 메모리 에서 유지 관리 됩니다 . 
 Persistence 파일 들 을 변경 하 려면 rebuild 를 하 고 부트 디바이스 에 저장 을 해야 합니다 . 
 Diskless , Stateless 가 가능 합니다 . Diskless 는 부팅 한 후 부트 디바이스 를 사용 하 지 않 는 것 이 고 Stateless 는 state 정보 가 ESXi 로 부터 얻 어 지 지 않 습니다 . 
 Archive 에서 Tardsk 로 파일 이 올라갑니다 . VisorFS 에 대한 상세 한 기술 문서 는 VMware lab 에 있 는데 다음 번 에 정리 를 해 보 고자 합니다 . ( https : / / labs . vmware . com / vmtj / visorfs - a - special - purpose - file - system - for - efficient - handling - of - system - images ) 
 vdf , vdu 명령 으로 tardisk 의 사용 률 을 볼 수 있 습니다 . 
 state file 은 / etc / vmware / esx . conf 파일 에 있 고 기본 환경 에서 실행 한 명령 은 / tmp . cmd . log , / var / run / cmd . pid 에 있 고 로그 파일 은 / var / log / vmkernel . log 에 있 습니다 . 
 Ramdisk 는 32 MB 정도 의 크기 를 가지 는 데 90 ~ 95 % 정도 의 사용 률 을 보입니다 . 버그 나 비 정상 적 인 상황 ( TSM 에서 큰 파일 을 다운 받 기 ) 를 하 지 않 는 경우 디스크 가 full 되 는 일 은 없 는데 Ramdisk 가 full 되 면 시스템 이 불 안정 한 상태 가 됩니다 . 이 경우 문제점 을 찾 은 후 조치 를 취하 거나 / var / log 파일 을 삭제 하 거나 Ramdisk 크기 를 조절 해서 조치 해야 합니다 . ( https : / / kb . vmware . com / s / article / 2001550 ) 
 컴포넌트 를 live system 에 설치 하 는 것 은 Ramdisk 를 마운트 하 고 tardisk 이미지 를 Ramdisk 에 다운로드 하 고 tardisk 를 마운트 하 는 작업 으로 적절 한 크기 의 메모리 가 있 어야 하 며 overcommitted 된 시스템 에서 는 해서 는 안 된다고 합니다 . 
 Esxi 의 디스크 와 Filesystem 구조 는 다음 과 같 습니다 . 
 Agents & Execution environment 
 코어 실행 모듈 은 vmkernel 이 고 코어 익스텐션 은 kernel 모듈 , 드라이버 가 있 습니다 . Idle , helper , Driver 는 시스템 권한 으로 실행 됩니다 . 유저 레벨 프로세스 도 있 는데 여기 서 유저 레벨 은 End user 를 의미 하 는 것 이 아니 라 실행 권한 이 시스템 레벨 이 아니 라는 것 입니다 . 
 Userworld 에 는 어떤 일 이 있 을 수 있 을까요 ? 
 Out of memory 가 발생 하 면 random 으로 userworld 프로세스 를 종료 합니다 . 
 메모리 부족 현상 이 발생 하 면 ENOMEM 이나 NULL 이 되 고 Exception 핸들러 가 없이 크래시 되 거나 행 이 됩니다 . 
 다른 Userworld 에 는 영향 이 없 으며 리 소소 를 많이 사용 한 모듈 이 종료 됩니다 . 
 CPU 부족 현상 이 발생 하 면 Userworld 가 느려 집니다 . 
 Remote CLI 나 PowerShell CLI 의 첫 엔트리 포인트 는 hostd 입니다 . hostd 가 응답 하 지 않 을 경우 DCUI 를 사용 하 여 네트워크 , 에이전트 등 을 확인 합니다 . 이 마저 도 동작 하 지 않 은 다면 VMware support 에 연락 을 하 고 TSM 을 Enable 한 후 문제 해결 을 합니다 . 
 Ramdisk 를 파일 을 저장 하 는 용도 로 사용 하 지 않 아야 합니다 . root filesystem 에서 변경 한 내용 은 재 부팅 이 되 면 삭제 됩니다 . 
 Userworld 의 리소스 풀 에 는 제약 이 있 어서 너무 많 은 명령 을 실행 하 면 에러 가 발생 할 수 있 고 CPU 를 많이 사용 하 는 명령 은 CPU 제한 때문 에 행 상태 로 보일 수 있 습니다 . 
 Userworld 는 일반 적 인 용도 를 위한 것 이 아닙니다 . ps 결과 는 vmkernel 월드 의 결과 를 보여 주 고 vsortfs 는 vdf 와 vdu 를 사용 해서 사용 률 을 확인 해야 합니다 . Debug VID 를 설치 해서 추가 적 인 Troubleshooting command 를 실행 할 수 있 습니다 . 
 ' Virtualization ' 카테고리 의 다른 글 
 ESXi Internal ( 0 ) 
 Dtrace 가 Windows 에 도입 되 었 습니다 . 
 2018 . 10 . 10 12 : 48 
 Dtrace , Ignite , OS Internal , Windows 
 OS internals : Technical deep - dive into operating system innovations - BRK 3365 
 Microsoft Ignite 2018 에서 OS internals 를 설명 하 는 과정 에서 DTrace 가 추가 된다는 것 이 발표 되 었 습니다 . 아래 내용 은 동영상 내용 을 정리 해 본 것 인데 기술 적 으로 자세히 다루 지 는 않 았 지만 많 은 변경 사항 을 보여준 것 같 습니다 . 
 12 : 23 - Dtrace on Windows , FreeBSD 에서 포 팅 을 했 다고 합니다 . FBT , SYSCall , ETW 를 사용 하 는 것 으로 보입니다 . 
 13 : 09 - traceext . sys , Dtrace . sys 드라이버 가 캡 처 를 담당 하 는 것 으로 보입니다 . 현재 는 커널 디버거 가 필요 합니다 . 
 17 : 40 - Dtrace 를 사용 해서 NamedPipe 를 연결 하 지 못하 는 문제 를 Trace 합니다 . MRxSmbFsdDispatch 에서 0 xc 0000033 가 발생 했 습니다 . 
 20 : 00 - Dtrace 를 사용 해서 Process 의 Profile , IO 등 을 확인 할 수 있 습니다 . 
 23 : 30 - GVFS 를 사용 해서 Git on Windows repository 의 속도 를 많이 향상 할 수 있 었 습니다 . 
 25 : 00 - WSL 에 대해서 설명 하 고 있 습니다 . 
 31 : 00 - WSL 의 코어 인 lxcore . sys 드라이버 에 대해서 설명 합니다 . 커널 디버깅 을 해서 fork 가 어떻게 실행 되 는지 보여 줍니다 . 
 37 : 00 - Hyper - V Container 에 대해서 설명 하 고 있 습니다 . Lightweight VM 의 Memory , Storage 에 대해서 설명 합니다 . 
 45 : 38 : - Container 프로세스 의 Memory 를 담당 하 는 vmmem 프로세스 를 디버깅 해서 자세히 설명 합니다 . 
 47 : 50 - Container 프로세스 의 이미지 파일 이 VSMB 를 통해서 매핑 되 어 있 는 것 을 디버깅 을 사용 해서 설명 합니다 . 
 54 : 28 - Virtualization Based Security 라는 가상 화 기술 을 이용 한 보안 기법 을 설명 하 고 있 습니다 . 
 1 : 05 : 28 - NVMe Storage 에 대해서 설명 하 고 있 습니다 . Para - virtualized storage 에 대해서 설명 합니다 . 
 1 : 08 : 00 - NVMe Direct 기술 을 사용 해서 Storage 성능 을 올렸 습니다 . Intel 의 APICv 기술 이 사용 되 었 다고 합니다 . 
 ' blogs update ' 카테고리 의 다른 글 
 Dtrace 가 Windows 에 도입 되 었 습니다 . ( 0 ) 
 [ 2016 - 05 - 09 ] Blog 정리 ( 0 ) 
 [ 2016 - 02 - 11 ] Blog update ( 0 ) 
 [ 2016 - 01 - 31 ] Blog update ( 0 ) 
 [ 2016 - 01 - 21 ] Blogs update ( 0 ) 
 부팅 과정 및 복구 ( Grub ) 
 2018 . 06 . 17 23 : 04 
 BCD , grub , Linux , Windows 
 오늘 은 리눅스 와 윈도우 의 부팅 과 복구 비교 해 보 고자 합니다 . 
 부팅 과정 에 대한 이론 적 인 내용 과 발생 할 수 있 는 문제 를 모두 다루 는 것 은 너무 어려운 일 이 기 때문 에 간략 하 게 줄여서 글 을 써 보 고자 합니다 . 
 리눅스 와 윈도우 모두 x 86 기반 의 시스템 이 기 때문 에 BIOS 와 UEFI 에 대한 부분 은 동일 합니다 . 하지만 부트 로드 이후 의 커널 을 올리 고 서비스 를 시작 하 는 과정 은 각자 의 특성 에 맞 게 동작 합니다 . 
 BIOS 를 기준 으로 설명 해 보 면 BIOS 에서 Boot 디스크 의 MBR 영역 에서 부트 로더 를 실행 시킵니다 . 
 과거 에 는 LILO 라는 프로그램 이 사용 되 었 으나 일반 리눅스 서버 에 는 GRUB 라는 프로그램 이 부트 로더 로 사용 됩니다 . 
 stage 1 이 라고 불리 는 GRUB 의 일부 가 MBR 에서 로드 되 면 stage 1 . 5 또는 stage 2 부트 로더 를 로드 합니다 . 부트 로더 를 메모리 에 모두 올리 면 부팅 가능 한 커널 의 목록 이 화면 에 출력 되 고 5 초 정도 기다린 후 가장 위 에 있 는 커널 이 실행 됩니다 . 커널 선택 화면 이 나오 지 않 는 경우 ESC 나 Shift 키 를 누르 면 GRUB 메뉴 로 들어갈 수 있 습니다 . ( GRUB 1 에서 는 ESC 이 고 GRUB 2 에서 는 Shift 가 사용 됩니다 . ) 커널 선택 화면 에서 " e " 버튼 을 누르 면 / boot / gurb / grub . cfg 파일 의 내용 이 출력 되 고 설정 값 을 변경 해서 커널 을 실행 할 수 있 습니다 . 이 부분 은 윈도우 보다 리눅스 가 훨씬 강력 한 것 같 습니다 . 윈도우 는 부팅 을 한 후 레지스트리 를 변경 하 거나 bcdedit 을 통해서 부트 옵션 을 변경 하 고 다시 부팅 을 해야 하 는데 리눅스 는 부팅 과정 에서 바로 커널 파라미터 를 변경 할 수 있 습니다 . 
 일반 적 인 설정 내용 은 / etc / default . grub 파일 에 들 어 있 고 실제 설정 파일 은 / boot / grub / grub . cfg 에 들 어 있 습니다 . ( Grub 2 의 경우 / boot / grub 2 / grub . cfg 파일 입니다 . ) 이 파일 을 사용 해서 crashkernel 을 설정 하 는 등 다양 한 커널 파라미터 를 수정 할 수 있 습니다 . 
 GRUB 문제 해결 
 부팅 이 안 되 는 이슈 가 있 을 때 Ubuntu 의 경우 ESC 나 Shift 키 를 이용 해서 Grub 메뉴 에 들어갈 수 있 다면 Advanced - Recovery mode 를 통해서 복구 를 진행할 수 있 습니다 . ( LiveCD 를 통해서 부팅 을 할 수 있 다고 하 는데 테스트 안 해 봤 습니다 . ) 
 ESC 키나 Shift 를 사용 해서 GRUB 프롬프트 로 진입 을 하 려고 하 였으나 디스크 오류 등 의 이슈 로 인해서 MBR 에서 GRUB 이 사라졌 을 수 있 습니다 . 이 경우 RHEL 의 경우 CD 로 부팅 을 한 후 rescue 키워드 를 통해서 복구 모드 로 들어갈 수 있 다고 합니다 . 
 https : / / access . redhat . com / documentation / ko - kr / red _ hat _ enterprise _ linux / 5 / html / installation _ guide / s 1 - rescuemode - boot 
 chroot / mnt / sysimage 를 사용 해서 루트 파티션 을 마운트 하 고 / sbin / grub - install / dev / sda 를 통해서 MBR 에 GRUB 를 재 설치 할 수 있 습니다 . ( grub 2 - install 을 사용 할 수 도 있 습니다 . ) 
 https : / / access . redhat . com / documentation / ko - kr / red _ hat _ enterprise _ linux / 5 / html / installation _ guide / s 1 - grub - installing 
 Red hat 의 설치 프로그램 복구 모두 에 대한 자세 한 내용 은 아래 링크 에 있 습니다 . 
 https : / / access . redhat . com / documentation / ko - kr / red _ hat _ enterprise _ linux / 7 / html / installation _ guide / sect - rescue - mode 
 부팅 이 된 후 GRUB 설정 파일 을 열 어서 문제 를 수정 할 수 있 습니다 . GRUB 1 의 경우 boot / grub / menu . lst 파일 이 설정 파일 이 고 GRUB 2 의 경우 / etc / default / grub 파일 을 변경 한 후 / usr / sbin / update - grup 를 실행 해서 / boot / grub / grub . cfg 를 실행 합니다 . 
 Linux 에서 GRUB 관련 더 많 은 사례 와 방법 이 있 을 수 있 을 것 같 은데 많이 시도 는 해 보 지 못했 습니다 . 
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ------------------------- Windows - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ------------------------- 
 Windows 2003 이나 XP 까지 는 ntldr 이 부트 로더 로 사용 되 었 으나 Windows 2008 , vista 부터 는 bootmgr , winload 등 으로 변경 되 었 습니다 . 부팅 과 관련 된 정보 는 Boot Configuration Data ( BCD ) 라는 곳 에 저장 되 어 있 고 관리자 권한 으로 CMD 를 실행 한 후 bcdedit . exe 를 사용 해서 설정 을 확인 / 변경 할 수 있 습니다 . 
 부트 옵션 은 bcdedit 을 통해서 변경 할 수 있 으며 아래 명령 을 통해서 현재 부트 옵션 을 복사 해서 DebugEntry 라는 엔트리 를 하나 더 만들 수 있 습니다 . 엔트리 를 하나 더 만들 게 되 면 부팅 할 때 어떤 부트 옵션 을 선택 해서 부팅 을 할지 물 어 보 는 화면 이 나옵니다 . 
 bcdedit 을 통해서 디버그 모드 설정 , 메모리 관련 설정 , Checked build 설정 , PAE 설정 등 을 설정 할 수 있 고 추가 설정 은 registry 를 변경 해야 합니다 . 
 https : / / docs . microsoft . com / en - us / windows - hardware / drivers / devtest / using - boot - parameters 
 BCD 는 시스템 을 설치 할 때 만들 어 진 500 MB 크기 의 System Reserved 파티션 에 들 어 있 고 그 안 에 는 BCD 정보 , 복구 콘솔 이미지 , bootmgr 등 의 정보 가 들 어 있 습니다 . ( 디스크 를 다른 시스템 에 마운트 하 면 system reserved 파티션 의 내용 을 확인 할 수 있 습니다 ) 
 시스템 이 부팅 이 안 되 는 경우 부팅 될 때 F 8 을 눌러서 Advanced Boot Options 가 나오 게 한 후 Repair Your Computer 를 선택 해서 복구 모드 로 들어갈 수 있 습니다 . 
 부팅 이 되 지 않 거나 F 8 을 눌러서 복구 모드 로 들어갈 수 없 는 경우 CD 로 부팅 을 하 여 Repair your computer 를 눌러 복구 콘솔 로 들어간 후 System Recovery options 에서 Command Prompt 를 선택 해서 부트 로더 를 복구 할 수 있 습니다 . 
 bootrec 명령 을 사용 하 여 부트 로더 , BCD 등 을 복구 할 수 있 습니다 . ( Raid 1 을 사용 하 고 있 다면 복구 모드 에서 Raid 드라이버 가 로드 되 어야 합니다 . 로드 되 지 않 는다면 디스크 중 하나 에 만 변경 사항 이 적용 됩니다 . ) 
 / FixMbr 을 사용 하 면 시스템 파티션 에 MBR 을 다시 작성 합니다 . ( 파티션 정보 는 변경 하 지 않 습니다 . ). 
 / FixBoot 를 사용 하 면 부팅 섹터 를 다시 작성 합니다 . 
 / RebuildBcd 를 사용 하 면 BCD 저 장소 를 다시 만듭니다 . 
 https : / / support . microsoft . com / ko - kr / help / 927392 / use - bootrec - exe - in - the - windows - re - to - troubleshoot - startup - issues 
 리눅스 와 윈도우 에 부팅 정보 와 부팅 에 대한 문제 해결 방법 이 너무 많 아서 기본 적 인 것 만 다루 어 보 았 습니다 . 
 성능 모니터링 ( sysstat , sar ) 
 2018 . 06 . 16 10 : 35 
 Linux , perfmon , sar , SYSSTAT , Windows 
 문제 가 발생 한 시점 에 성능 데이터 를 확인 하 는 것 은 어렵 기 때문 에 성능 을 기록 하 는 도구 를 사용 하 게 됩니다 . 
 Linux 에서 는 sysstat 를 사용 하 고 Windows 에서 는 Perfmon 을 사용 합니다 . 
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ------------------------- Linux 도구 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ------------------------- 
 리눅스 에서 는 sysstat 패키지 를 설치 하 고 sysstat 을 활성 화 하 면 / var / log / sysstat 또는 / var / log / sa 에 성능 을 기록 합니다 . 
 수집 주기 를 10 분 에서 2 분 으로 변경 
 sudo vi / etc / cron . d / sysstat 
 5 - 55 / 10 * * * * root command - v debian - sa 1 > / dev / null && debian - sa 1 1 1 을 
 */ 2 * * * * root command - v debian - sa 1 > / dev / null && debian - sa 1 1 1 로 변경 
 sysstat 재 시작 
 제 시스템 의 경우 / var / log / sysstat / sa 16 이 라는 파일 에 데이터 가 저장 되 었 는데 cat 으로 내용 이 보이 지 않 는 것 으로 보 아 바이너리 로 저장 되 는 것 같 습니다 . 
 블로그 를 작성 하 는 날짜 가 16 일 이 어서 sa 16 으로 기록 되 었 습니다 . 로그 파일 이 어느 정도 오랬 동안 저장 되 는지 ? 한 달 이 지나 면 숫자 가 반복 되 면서 overwrite 되 는 것 인지 는 아직 확인 하 지 못했 습니다 . 
 sar 명령 을 실행 하 니 CPU 의 상태 정보 가 기록 되 어 있 습니다 . 2 분 단위 로 자료 수집 이 된 것 을 확인 할 수 있 습니다 . 
 sar - r 을 사용 하 면 메모리 의 상태 를 확인 할 수 있 습니다 . 
 sar - b 를 사용 하 면 IO 상태 를 확인 할 수 있 습니다 . 
 sar 에 - s 와 - e 인자 를 사용 해서 시작 , 끝 시간 을 지정 할 수 있 습니다 . 
 sar 옵션 은 아래 와 같 습니다 . 
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ------------------------- Windows 도구 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ------------------------- 
 Linux 에 Sar 이 있 다면 Windows 에 는 perfmon 이 있 습니다 . 
 시작 - 실행 - perfmon - 성능 모니터 를 실행 하 면 아래 그림 과 같이 Memory , Network Interface , PhysicalDisk Processor Information 에 대한 정보 를 보여 줍니다 . ( 성능 모니터 로 CPU 정보 를 확인 하 실 때 Processor 가 아니 고 Processor Information 을 선택 하 셔야 합니다 . Processor 는 NUMA 를 지원 하 지 않 기 때문 에 CPU 가 많이 장착 된 시스템 에서 는 올바른 정보 를 보여 주 지 못합니다 . ) 
 주기 적 으로 정보 를 수집 하 고 저장 하 기 위해서 는 사용 자 정의 데이터 수집 기 집합 을 사용 해야 합니다 . ( logman 명령 을 사용 해서 데이터 수집 기 집합 을 만들 수 도 있 으니 다음 블로그 를 참 고 하 세요 https : / / blogs . technet . microsoft . com / yongrhee / 2015 / 05 / 16 / setting - a - local - perfmon - in - a - windows - client - or - windows - server / ) 
 성능 로그 보다 더 상세 한 정보 수집 을 위해 System Diagnostics 를 선택 합니다 . 
 데이터 파일 이 저장 될 위치 를 확인 할 수 있 습니다 . 수집 된 데이터 파일 을 다른 장비 로 가져가 서 분석 가능 합니다 . 
 기본 적 으로 수집 되 던 성능 로그 이외 에 많 은 항목 들 이 추가 되 어 있 습니다 . NT Kernel 은 커널 정보 를 추적 하 는 것 이 고 Performance Counter 는 전통 적 인 성능 로그 그리고 구성 유형 은 시스템 의 각종 구성 정보 를 수집 하 는 것 입니다 . 
 전체 자료 수집 시간 은 10 분 이 고 1 분 에 한 번 씩 정보 를 수집 합니다 . 
 10 분 이 지나 면 아래 와 같이 보 고서 - 사용 자 장의 - [ 정의 한 이름 ] 아래 에 시스템 성능 구성 정보 를 보여 줍니다 . 각 구성 요소 에 대한 점검 을 진행 하 고 구성 또는 성능 에 문제 가 있 는지 를 확인 해줍니다 . 
 디스크 항목 을 자세히 확인 해 보 니 입 축력 이 가장 많 은 파일 , 디스크 에 대한 IO 정보 , NTFS 성능 에 영향 을 주 는 구성 정보 를 보여 줍니다 . 
 템플 릿 을 사용 하 면 시스템 구성 정보 등 더 많 은 정보 를 보여 주 는데 데이터 수집 기 집합 을 만들 때 수동 으로 만들 기 를 선택 한 후 성능 카운터 를 수집 하 도록 하 면 sar 와 비슷 하 게 성능 정보 만 수집 할 수 있 습니다 . 
 sar 와 는 다르 게 perfmon 은 어떤 데이터 를 수집 할지 선택 할 수 있 습니다 . 각 카운터 에 대해서 잘 알 지 못한다면 아래 " 설명 표시 " 를 클릭 하 면 해당 카운터 에 대한 설명 을 확인 할 수 있 습니다 . 
 주의 ) 성능 로그 가 3 일 이상 수집 이 되 지 않 을 경우 Task Scheduler - Task Scheduler Library - Microsoft - Windows - PLA 의 설정 에 " 다음 시간 이상 실행 되 면 중지 3 일 " 이 설정 되 어 있 는지 확인 해야 합니다 . Windows Server 2012 에서 는 이 옵션 이 설정 되 어 있 어 3 일 이상 실행 되 면 자료 수집 이 멈추 는 이슈 가 있 었 습니다 . 
 sar 와 perfmon 에 대한 비교 를 마칩니다 . 두 도구 가 완전히 동일 하 다고 할 수 는 없 겠 지만 주기 적 으로 시스템 성능 정보 를 수집 할 수 있 다는 점 에서 유용 합니다 . 
 IO 부하 ( iostat , iotop ) 
 2018 . 06 . 06 08 : 50 
 iostat , iotop , Linux , perfmon , resource monitor , Windows 
 오늘 은 IO 부하 에 대한 도구 를 살펴보 도록 하 겠 습니다 . 
 성능 저하 현상 이 발생 하 면 디스크 에 어느 정도 부하 가 걸려 있 고 응답 속도 는 어떻게 되 는지 , 어떤 프로세스 가 많 은 IO 를 발생 시키 고 있 는지 확인 해야 합니다 . 
 iostat 을 사용 하 면 CPU 사용 률 과 디스크 장치 및 파티션 에 대한 IO 통계 정보 를 보여 줍니다 . 
 tps 는 초당 전송 량 , KB _ read / s 는 초당 읽힌 KB , KB _ wrtn / s 는 초당 쓴 KB , KB _ read 는 해당 장치 에서 읽혀진 전체 KB , KB _ wrtn 은 해당 장치 에 쓰여진 전체 KB 입니다 . Windows 에서 는 성능 모니터 를 실행 하 지 않 으면 시스템 시작 부터 현재 까지 의 IO 정보 를 저장 해 놓 지 않 는다는 점 이 다른 것 같 습니다 . 
 IO 가 많이 발생 한 장치 에 어떤 파일 들 이 있 고 Read 요청 이 많이 발생 하 는지 Write 요청 이 많이 발생 하 는지 를 확인 해서 문제 분석 을 위한 방향 을 잡 을 수 있 습니다 . 
 iostat 이 장치 단위 로 정보 를 보여 주 었 다면 iotop 으로 모든 프로세스 의 IO 통계 를 볼 수 있 습니다 . 
 iotop 을 실행 했 더니 보 안 이슈 때문 에 root 또는 NET _ ADMIN capability 가 있 어야 한다고 되 어 있 습니다 . Windows 로 따져 본다면 관리자 권한 으로 실행 하 거나 특정 user right 이 있 어야 한다는 의미 로 보입니다 . Linux 에서 capability 라는 것 은 Windows 의 User right 라고 보 면 될 것 같 습니다 . 
 키보드 왼쪽 , 오른쪽 키 를 이동 해서 헤더 를 이동 하 면 해당 헤더 값 으로 정렬 이 됩니다 . 
 -- only 옵션 을 사용 하 면 현재 IO 를 하 고 있 는 프로세스 만 보여 주 게 됩니다 . 
 # sudo iotop -- only 
 윈도우 에서 는 perfmon / res 명령 을 사용 하 거나 작업 관리자 를 통해서 리소스 모니터 를 실행 할 수 있 습니다 . 
 iostat 과 는 달리 장치 별 Read / Write 값 을 보여 주 지 않 고 디스크 활성 시간 , 큐 길이 를 보여 주 고 iotop 과 같이 각 프로세스 의 Read / Write 값 을 볼 수 있 습니다 . 어떤 파일 에 Read / Write 를 하 고 있 는지 , 각 파일 에 대한 IO 응답 시간 은 어떻게 되 는지 를 볼 수 있 다는 점 이 장점 입니다 . 파일 에 대한 응답 시간 을 확인 할 수 있 기 때문 에 특정 프로그램 이 사용 하 는 파일 에 IO 응답 시간 에 문제 가 있 는지 확인 할 수 있 습니다 . 
 iostat , iotop 과 같 은 정보 를 보 려면 성능 모니터 를 실행 해야 합니다 . 명령 줄 에서 perfmon 을 실행 하 면 되 고 보 기 에서 보고서 를 선택 하 면 기본 값 인 선형 그래프 가 아닌 숫자 로 결과 를 볼 수 있 어 편리 합니다 . 
 성능 모니터 에 는 아래 보이 는 것 과 같이 많 은 데이터 를 한 눈 에 볼 수 있 습니다 . PhysicalDisk 를 선택 하 면 물리 디스크 에 대한 정보 를 확인 할 수 있 습니다 . 
 iotop 과 같이 각 프로세스 별 IO 를 확인 하 려면 Process 를 선택 하 면 됩니다 . 아쉬운 것 은 보 고서 형식 을 선택 할 경우 프로세스 들 이 가로 로 나열 되 어 스크롤바 를 이동 해서 정보 를 확인 하 는 것 이 좀 불편 합니다 . 
 시스템 부하 확인 ( uptime ) 
 2018 . 06 . 02 21 : 05 
 Linux , taskmgr , uptime , Windows 
 Linux 를 공부 하 면서 Windows 와 Linux 의 같 은 점 과 다른 점 을 비교 하 는 블로그 를 하 면 좋 겠 다는 생각 이 들 었 습니다 . 
 Linux 명령 을 사용 해서 시스템 의 정보 를 확인 할 때 Windows 에 도 동일 한 정보 를 얻 을 수 있 는 명령 이 있 다는 생각 을 하 였 고 Windows 를 잘 아 시 는 엔지니어 들 은 Linux 를 잘 모르 고 Linux 를 잘 아 시 는 엔지니어 들 은 Windows 를 잘 알 지 못한다는 생각 이 들 어 동일 한 정보 를 확인 하 는 방법 을 Windows 와 Linux 로 설명 하 면 도움 이 될 것 같 다는 생각 을 하 였 습니다 . 
 저 는 Windows 에 대해서 는 잘 알 고 있 지만 Linux 에 대해서 는 초보 이 기 때문 에 Linux 명령 을 확인 하 면서 Windows 의 동일 한 명령 을 정리 하 고자 합니다 . 
 uptime 은 시스템 이 시작 된 지 얼마나 되 었 으며 1 분 , 5 분 15 분 동안 의 평균 부하 가 얼마나 되 었 는지 보여 줍니다 . 시스템 의 평균 부 하 는 실행 가능 한 상태 혹은 중단 불 가능 한 상태 의 프로세스 들 의 평균 개수 라고 합니다 . 
 Linux 에 uptime 이 있 다면 Windows 에 는 taskmgr 이 있 습니다 . 시작 - 실행 - taskmgr 을 입력 해서 실행 할 수 도 있 고 Ctrl + Shift + Esc 를 눌러서 실행 할 수 도 있 습니다 . 성능 탭 을 클릭 하 면 uptime 과 비슷 한 정보 를 볼 수 있 습니다 . uptime 과 는 달리 taskmgr 을 실행 시키 기 이전 의 부하 는 알 수 없 으며 taskmgr 을 실행 한 이후 의 부하 를 알 수 있 습니다 . 
 uptime 과 Taskmgr 이 동일 하 다고 볼 수 는 없 지만 시스템 의 부하 를 간단히 보여 준다는 점 에서 동일 한 도구 로 볼 수 있 습니다 . 
 redrock 2018 . 06 . 03 01 : 32 신고 
 전 windows 에선 net statistics server 를 주로 사용 합니다 단순히 uptime 대용 으로 ^^ 
 load average 정의 가 상당히 애매 한데 어디 서 해당 값 에 대한 설명 이 있 던 글 이 있 었 는데 까먹 었 네요 . 
 load average 는 참고 로 top 실행 시 에 도 나옵니다 . 
 Platform Engineer 2018 . 06 . 03 20 : 19 신고 
 net stats 는 Server Service 에 대한 통계 를 보여 주 는 것 이 군요 . 저 도 처음 봤 습니다 . Load average 에 대해서 는 나중 에 성능 에 대해서 비교 할 때 더 자세히 다뤄 보 도록 하 겠 습니다 . 
 명령 줄 툴 인 Handle 을 사용 해서 핸들 수 파악 하 기 
 2018 . 03 . 17 18 : 41 
 HANDLE , sysinternals 
 프로세스 의 핸들 수 가 많이 증가 되 었 거나 시스템 에 커널 메모리 사용량 이 많이 올라가 면 어떤 핸들 이 많이 사용 되 었 는지 확인 해야 합니다 . 
 일반 적 으로 우리 가 핸들 수 를 확인 하 는 방식 은 아래 와 같 습니다 . 
 1 . 작업 관리자 를 열 어서 세부 정보 나 프로세스 탭 에서 " 열 선택 " 을 한 후 핸들 을 선택 해서 각 프로세스 의 핸들 수 를 확인 
 2 . Process Explorer 를 실행 해서 해당 프로세스 를 선택 한 후 View - Lower Pane View - Handles 를 선택 해서 어떤 핸들 이 있 는지 확인 . 
 그런데 이 방법 을 사용 하 면 해당 프로세스 에 핸들 이 많 다는 것 은 확인 할 수 있 는데 어떤 종류 의 핸들 이 많이 있 는지 는 확인 하 기 힘듭니다 . 
 이 경우 에 사용 할 수 있 는 것 이 명령 줄 에서 사용 할 수 있 는 handle . exe 입니다 . 
 https : / / docs . microsoft . com / ko - kr / sysinternals / downloads / handle 
 1 . 시스템 전체 의 핸들 수 를 종류 별 로 알 고 싶 을 때 
 C : \ Users \ clust > handle - s 
 < Unknown type > : 272 
 < Unknown type > : 3 
 < Unknown type > : 2 
 < Unknown type > : 686 
 < Unknown type > : 24 
 < Unknown type > : 8 
 < Unknown type > : 11 
 < Unknown type > : 23 
 < Unknown type > : 17 
 < Unknown type > : 7 
 < Unknown type > : 21730 
 < Unknown type > : 12 
 < Unknown type > : 1 
 < Unknown type > : 60 
 ALPC Port : 4317 
 Desktop : 209 
 Directory : 593 
 DxgkSharedResource : 80 
 DxgkSharedSyncObject : 3 
 Event : 24745 
 File : 6150 
 IoCompletion : 2893 
 IoCompletionReserve : 206 
 IRTimer : 1452 
 Job : 264 
 Key : 8033 
 Mutant : 2661 
 Process : 2565 
 Section : 4447 
 Semaphore : 5817 
 Thread : 4827 
 Timer : 816 
 Token : 1423 
 TpWorkerFactory : 715 
 UserApcReserve : 12 
 WaitCompletionPacket : 6216 
 WindowStation : 386 
 WmiGuid : 44 
 Total handles : 101747 
 2 . Process 의 핸들 수 를 종류 별로 알 고 싶 을 때 
 C : \ Users \ clust > handle - s - p notepad 
 < Unknown type > : 110 
 ALPC Port : 10 
 Directory : 2 
 Event : 32 
 IoCompletion : 3 
 IoCompletionReserve : 1 
 IRTimer : 4 
 Key : 22 
 Semaphore : 18 
 Thread : 6 
 Timer : 2 
 TpWorkerFactory : 2 
 WaitCompletionPacket : 12 
 Total handles : 249 
 3 . 프로세스 별로 핸들 의 자세 한 정보 를 알 고자 할 때 
 C : \ Users \ clust > handle - u 
 smss . exe pid : 536 \< unable to open process > 
 csrss . exe pid : 796 \< unable to open process > 
 sihost . exe pid : 1092 CLUSTALEEY 700 \ clust 
 40 : File C : \ Windows \ System 32 
 16 C : File C : \ Windows \ Registration \ R 00000000000 d . clb 
 svchost . exe pid : 13964 CLUSTALEEY 700 \ clust 
 44 : File C : \ Windows \ System 32 
 280 : File C : \ Windows \ Registration \ R 00000000000 d . clb 
 4 E 8 : File C : \ Windows \ System 32 \ ko - KR \ winnlsres . dll . mui 
 634 : File C : \ Users \ clust \ AppData \ Local \ ConnectedDevicesPlatform \ 908 b 443 ce 4 ed 0 b 0 c \ ActivitiesCache . db 
 638 : File C : \ Users \ clust \ AppData \ Local \ ConnectedDevicesPlatform \ 908 b 443 ce 4 ed 0 b 0 c \ ActivitiesCache . db - wal 
 63 C : File C : \ Users \ clust \ AppData \ Local \ ConnectedDevicesPlatform \ 908 b 443 ce 4 ed 0 b 0 c \ ActivitiesCache . db - shm 
 명령 줄 툴 인 Handle 을 사용 해서 핸들 수 파악 하 기 ( 0 ) 
 Windows Server 2012 원격 터미널 접속 시 패스워드 변경 불가 ( 0 )