오랜만에 Windows Kernel에 대한 블로그가 올라와서 정리를 해 보았습니다.

One Windows Kernel

https://techcommunity.microsoft.com/t5/Windows-Kernel-Internals/One-Windows-Kernel/ba-p/267142

Windows는 x86, x64, ARM, ARM64를 지원하고 예전에는 Itanium, PowerPC, DEC Alpha, MIPS를 지원할 정도로 다양한 하드웨어를 지원하고 Data center, Laptop, xbox, phone, IOT device를 지원할 정도로 다양한 SKU를 가지고 있습니다.

아래 이미지는 896 코어에 1792 개의 logical processor와 2TB RAM을 지원하는 Windows DataCenter 버전의 작업 관리자 이미지 입니다. (저도 이렇게 큰 장비를 본 적은 없습니다. 대형 장비 이지만 Windows 10을 쓰는 방법과 거의 유사하게 시스템을 관리할 수 있어 금방 적응할 수 있습니다.)

Windows refactoring 에 대해서 먼저 이야기 하고 있습니다. 다양한 SKU의 Windows을 동일한 DLL로 지원을 하지만 일부 코드를 다르게 구현할 수 있도록 API set (https://docs.microsoft.com/en-us/windows/desktop/apiindex/windows-apisets) 이라는 것을 만들었습니다. 예를 들면 kernel32.dll을 그대로 사용하면서 실제 구현은 다른 DLL에 되어 있는 것입니다. (저도 API set을 자세히 분석해 본 적은 아직 없어서 자세한 내용은 나중에 정리해 봐야 할것 같습니다.)

Kernel Components

Windows NT는 마이크로 커널 유형으로 되어 있습니다. (완전한 마이크로 커널은 아닙니다.) 코어 커널 모듈이 있고 실행부라는 영역이 커널에 존재 합니다. 커널은 스레드 디스패칭, 멀티프로세서 동기화, 하드웨어 예외 핸들링 등을 처리 하고 실행부에서는 IO, 객체 관리, 메모리 관리, 프로세스 서브 시스템 등을 담당합니다.

윈도우 컴포넌트의 크기를 코드수로 보면 아래와 같습니다. 역시 메모리가 가장 많은 코드를 가지고 있고 커널 순으로 이어집니다. 좀 더 자세한 내용을 학고 싶으면 Windows Internals 책을 구입해서 읽어보면 됩니다. 

Scheduler

스레드는 프로그램 코드가 실행되는 가장 기본 유닛으로 Windows 스케줄러가 스케줄 합니다. 윈도우 스케줄러는 스레드 우선순위에 따라서 높은 우선순위를 가진 스레드 부터 스케줄링 합니다. 스레드는 주어진 시간 (Quantum time) 동안 실행되고 다음 스레드가 실행됩니다. 만약 높은 우선순위를 가지고 있는 스레드가 계속 실행되고 있어서 낮은 우선 순위를 가지는 스레드가 실행될 기회를 얻지 못한다면 낮은 우선순위를 가진 스레드의 우선순위가 올라가게 됩니다. 

최초에 Windows 스케줄러는 하나의 레디큐를 가지고 있었습니다. 하지만 많은 프로세서를 지원하기 시작하면서 하나의 레디큐가 병목현상을 보이게 되었고 Windows Server 2003 에서 프로세서마다 하나의 레디큐를 가지게 디자인이 변경 되었습니다. 하나의 레디큐를 사용하면서 발생했던 글로벌 락 문제가 사라졌습니다. 가장 높은 우선순위를 가지는 스레드가 실행되는 것은 보장할 수 있지만 N 개의 core를 가지는 시스템에서 최대 N 개의 높은 우선순위를 가지는 스레드가 실행된다고 말 할 수는 없습니다. (현재 실행되는 스레드보다 높은 스레드가 다른 코어에 대기 상태로 있을 수 있습니다.) Windows가 laptop 이나 태블릿 같은 CPU 파워가 낮은 시스템에 적용되면서 UI가 느려지는 현상등이 발생하게 되었습니다. 그래서 Windows 8.1 에서 스케줄러가 프로세서당 레디큐를 가지는 것과 프로세서간 공유하는 레디큐를 가지는 하디브리드 형태로 변경 되었습니다. 다른 아키텍처의 변경이 있었기 때문에 스케줄로 변경으로 인한 성능 향상이 크게 보이지는 않았습니다.

Windows 7 에서 동적인 공정 공유 스케줄러 (Dynamic Fair Share Scheduler)가 도입되었습니다. 이 기능은 터미널 서버를 위해서 도입되었습니다. 하나의 터미널 세션이 과도한 CPU 자원을 사용해서 다른 터미널 세션에 영향을 주는 것을 방지하기 위해 도입 되었습니다. 기존의 스케줄링은 세션을 고려하지 않고 스레드 우선순위만 고려해서 스케줄링 했는데 이 기능이 도입 되어 다른 세션에 영향을 주지 않게 되었습니다. Linux의 Completely Fair Scheduler와 유사한 것 입니다. Windows 8 에서 이 개념이 스케줄러 그룹으로 일반화 되었고 각 세션마다 윈도우 스케줄러가 사용됩니다. 스케줄러 그룹은 스레드 우선순위에서도 2차 인덱스 역할을 해서 어떤 스레드가 다음에 실행될지를 결정 합니다. 터미널 세션에서 모든 스케줄러 그룹은 동일한 양의 스케줄링을 받게 됩니다. 그리고 Job 오브젝트가 향상되어 CPU rate control (https://docs.microsoft.com/en-us/windows/desktop/api/winnt/ns-winnt-_jobobject_cpu_rate_control_information) 기능을 지원하게되어 프로세스가 사용할 수 있는 CPU 양의 hard cap과 soft cap을 제한할수 있습니다. 이 기능은 리눅스의 cgroups 과 유사 합니다.

Windows 7 이후 부터 Windows 서버는 64개 이상의 프로세서를 지원하게 됩니다. 많은 프로세서를 지원하기 위해 프로세서 그룹 이라는 개념이 도입되었습니다. 프로세서 그룹은 최대 64개 까지의 프로세서를 하나의 그룹으로 묶어서 하나의 스케줄링 단위로 만드는 것으로 부팅하는 시점에 커널에서 어떤 프로세서가 어떤 그룹에 설정될지를 결정 합니다. (64개 이하의 코어를 가질 경우 프로세서 그룹은 적합하지 않습니다.) 단일 프로세스 (SQL Server)는 프로세서 그룹에 확장될 수 있으나 개별 스레드는 하나의스케줄링 그룹에서만 실행될 수 있습니다. (응용 프로그램이 프로세서 그룹이나 NUMA에 적합하지 않을 경우 BIOS에서 프로세서를 하나의 그룹으로 인식 시킬 수 있습니다.)

64개 이상의 코어를 가지는 시스템에서 코어 수를 늘렸을 때 SQL server와 같은 제품에서 성능 향상이 많이 일어나지 않는 것이 확인 되었습니다. 코어 수가 늘어나면 디스패처 락 문제 때문에 성능 향상에 문제가 있는 것이 확인 되었습니다. 디스패처 락은 디스패치가 되는 오브젝트를 보호하는 락으로 스레드, 타이머, I/O 완료 포트, 동기화 객체 등을 보호 합니다. Windows 7 에서 디스패처 락을 제거하고 객체 별 락을 도입하였고 290%의 성능 향상을 보였습니다. 

Windows 10 (Windows Server 2016)에서는 CPU Sets이 추가 되었습니다. CPU Set은 프로세스가 시스템을 나눠서 프로세스가 특정 프로세서 그룹을 사용할 수 있게하고 다른 프로세스나 시스템이 할당된 프로세서 그룹을 사용하지 못하게 하는 것 입니다. 프로세서가 CPU set으로 설정되면 디바이스의 코드도 실행되지 않습니다. Windows 10의 Game Mode가 이 기능을 사용한다고 합니다. (https://www.windowscentral.com/windows-10-game-mode)

그 외에도 ARM 관련 내용이 일부 있습니다. 

Scheduler 라는 것이 일반 사용자나 개발자 모두에게 잘 보여지지 않는 내용인데 블로그를 통해서 간단하게나마 소개가 되었습니다. 하지만 깊이 있는 내용은 문서를 찾기 힘들고 이해 하기가 힘들기 때문에 이정도에서 마무리 하려고 합니다.

최근에 VMware 제품인 ESXi를 공부해야할 필요가 생겨서 공부를 하면서 정리를 해 보았습니다. 이제 공부를 처음 시작하는 것이기 때문에 어떤 내용들을 정리할 수 있을지 정하지는 않았지만 최대한 많이 자료를 접하면 정리가 될 것 같습니다.

VMware world TA8245-ESXi Internals - Better Understanding for Better Management and Troubleshooting

https://www.youtube.com/watch?v=Qq3H3yIh5UQ&list=WL&index=6&t=0s

자료가 VMworld 2010 자료라 현재는 내용이 달라졌을 수 있습니다. 큰 그림은 바뀌지 않았으리라 생각하고 정리해 봅니다.

Olivier Cremel 이라는 VMware의 Principal Engineer가 발표를 하는데 Linkedin을 보니 Google로 갔다가 다시 VMware로 컴백을 했습니다.

Files & Filesystems

어떤 부트 디바이스일 경우에도 단일 부팅 이미지로 되어 있고 모든 내용이 메모리로 로드가 된다고 합니다. 그래서 부트 디바이스에 문제가 발생 하더라도 운영에 문제가 없다고 합니다. 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 는 32MB 정도의 크기를 가지는데 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를 실행할 수 있습니다.

OS internals: Technical deep-dive into operating system innovations - BRK3365

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 에서 0xc0000033 가 발생했습니다.

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 기술이 사용되었다고 합니다.

오늘은 리눅스와 윈도우의 부팅과 복구 비교해보고자 합니다. 

부팅 과정에 대한 이론적인 내용과 발생할 수 있는 문제를 모두 다루는 것은 너무 어려운 일이기 때문에 간략하게 줄여서 글을 써보고자 합니다.

리눅스와 윈도우 모두 x86 기반의 시스템이기 때문에 BIOS와 UEFI 에 대한 부분은 동일 합니다. 하지만 부트 로드 이후의 커널을 올리고 서비스를 시작하는 과정은 각자의 특성에 맞게 동작 합니다.

BIOS를 기준으로 설명해보면 BIOS에서 Boot 디스크의 MBR 영역에서 부트 로더를 실행 시킵니다.

-------------------------------------------------------- Linux -----------------------------------------------------------

과거에는 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에 들어 있습니다. (Grub2의 경우 /boot/grub2/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/s1-rescuemode-boot

chroot /mnt/sysimage를 사용해서 루트 파티션을 마운트 하고 /sbin/grub-install /dev/sda를 통해서 MBR에 GRUB를 재설치 할 수 있습니다. (grub2-install을 사용할 수도 있습니다.)

https://access.redhat.com/documentation/ko-kr/red_hat_enterprise_linux/5/html/installation_guide/s1-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 /copy {current} /d "DebugEntry"

bcdedit을 통해서 디버그 모드 설정, 메모리 관련 설정, Checked build 설정, PAE 설정 등을 설정할 수 있고 추가 설정은 registry를 변경해야 합니다.

https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/using-boot-parameters

BCD는 시스템을 설치할 때 만들어진 500MB 크기의 System Reserved 파티션에 들어 있고 그 안에는 BCD 정보, 복구 콘솔 이미지, bootmgr 등의 정보가 들어 있습니다. (디스크를 다른 시스템에 마운트 하면 system reserved 파티션의 내용을 확인할 수 있습니다)

시스템이 부팅이 안되는 경우 부팅될 때 F8을 눌러서 Advanced Boot Options가 나오게 한 후 Repair Your Computer를 선택해서 복구 모드로 들어갈 수 있습니다.

부팅이 되지 않거나 F8을 눌러서 복구 모드로 들어갈 수 없는 경우 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

리눅스와 윈도우에 부팅 정보와 부팅에 대한 문제 해결 방법이 너무 많아서 기본적인 것만 다루어 보았습니다.

문제가 발생한 시점에 성능 데이터를 확인하는 것은 어렵기 때문에 성능을 기록하는 도구를 사용하게 됩니다.

Linux에서는 sysstat를 사용하고 Windows 에서는 Perfmon을 사용합니다.

-------------------------------------------------------- Linux 도구 --------------------------------------------------------

SAR

리눅스에서는 sysstat 패키지를 설치하고 sysstat을 활성화 하면 /var/log/sysstat 또는 /var/log/sa에 성능을 기록합니다.

Install

sudo apt-get install sysstat

enable

sudo vi /etc/default/sysstat

ENABLED="false"를 ENABLE="true" 로 변경

수집 주기를 10 분에서 2분으로 변경

sudo vi /etc/cron.d/sysstat

5-55/10 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1 을

*/2 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1 로 변경

sysstat 재시작

sudo service sysstat restart

정보 수집

sar 

제 시스템의 경우 /var/log/sysstat/sa16 이라는 파일에 데이터가 저장되었는데 cat으로 내용이 보이지 않는 것으로보아 바이너리로 저장되는 것 같습니다.

블로그를 작성하는 날짜가 16일 이어서 sa16으로 기록되었습니다. 로그 파일이 어느 정도 오랬동안 저장되는지? 한달이 지나면 숫자가 반복되면서 overwrite 되는 것인지는 아직 확인하지 못했습니다.

sar 명령을 실행하니 CPU의 상태 정보가 기록되어 있습니다. 2분 단위로 자료 수집이 된것을 확인할 수 있습니다.

sar -r을 사용하면 메모리의 상태를 확인할 수 있습니다. 

sar -b를 사용하면 IO 상태를 확인할 수 있습니다.

sar에 -s 와 -e 인자를 사용해서 시작, 끝 시간을 지정할 수 있습니다. 

sar 옵션은 아래와 같습니다.

-------------------------------------------------------- Windows 도구 --------------------------------------------------------

Perfmon

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 부하에 대한 도구를 살펴보도록 하겠습니다.

성능 저하 현상이 발생하면 디스크에 어느 정도 부하가 걸려 있고 응답 속도는 어떻게 되는지, 어떤 프로세스가 많은 IO를 발생시키고 있는지 확인해야 합니다. 

-------------------------------------------------------- Linux 도구 --------------------------------------------------------

iostat  

iostat을 사용하면 CPU 사용률과 디스크 장치 및 파티션에 대한 IO 통계 정보를 보여 줍니다.

tps 는 초당 전송량, KB_read/s 는 초당 읽힌 KB, KB_wrtn/s 는 초당 쓴 KB, KB_read는 해당 장치에서 읽혀진 전체 KB, KB_wrtn은 해당 장치에 쓰여진 전체 KB 입니다. Windows 에서는 성능 모니터를 실행하지 않으면 시스템 시작 부터 현재까지의 IO 정보를 저장해 놓지 않는다는 점이 다른것 같습니다.

IO가 많이 발생한 장치에 어떤 파일들이 있고 Read 요청이 많이 발생하는지 Write 요청이 많이 발생하는지를 확인해서 문제 분석을 위한 방향을 잡을 수 있습니다.

iotop

iostat이 장치 단위로 정보를 보여 주었다면 iotop으로 모든 프로세스의 IO 통계를 볼 수 있습니다.

iotop을 실행했더니 보안 이슈 때문에 root 또는 NET_ADMIN capability가 있어야 한다고 되어 있습니다. Windows로 따져본다면 관리자 권한으로 실행 하거나 특정 user right이 있어야 한다는 의미로 보입니다. Linux에서 capability 라는 것은 Windows의 User right 라고 보면 될것 같습니다.

키보드 왼쪽, 오른쪽 키를 이동해서 헤더를 이동하면 해당 헤더 값으로 정렬이 됩니다.

--only 옵션을 사용하면 현재 IO를 하고 있는 프로세스만 보여주게 됩니다.

# sudo iotop --only 

-------------------------------------------------------- Windows 도구 --------------------------------------------------------

리소스 모니터

윈도우 에서는 perfmon /res 명령을 사용하거나 작업 관리자를 통해서 리소스 모니터를 실행할 수 있습니다.

iostat 과는 달리 장치별 Read/Write 값을 보여주지 않고 디스크 활성 시간, 큐 길이를 보여주고 iotop과 같이 각 프로세스의 Read/Write 값을 볼 수 있습니다.  어떤 파일에 Read/Write를 하고 있는지, 각 파일에 대한 IO 응답시간은 어떻게 되는지를 볼 수 있다는 점이 장점입니다. 파일에 대한 응답시간을 확인할 수 있기 때문에 특정 프로그램이 사용하는 파일에 IO 응답 시간에 문제가 있는지 확인할 수 있습니다.

성능 모니터

iostat, iotop과 같은 정보를 보려면 성능 모니터를 실행해야 합니다. 명령줄에서 perfmon을 실행하면되고 보기에서 보고서를 선택하면 기본 값인 선형 그래프가 아닌 숫자로 결과를 볼 수 있어 편리 합니다.

성능 모니터에는 아래 보이는 것과 같이 많은 데이터를 한 눈에 볼 수 있습니다. PhysicalDisk를 선택하면 물리 디스크에 대한 정보를 확인할 수 있습니다.

iotop과 같이 각 프로세스별 IO를 확인하려면 Process를 선택하면 됩니다. 아쉬운 것은 보고서 형식을 선택할 경우 프로세스 들이 가로로 나열되어 스크롤바를 이동해서 정보를 확인하는 것이 좀 불편합니다. 

첫 번째 글을 올리고 나서 이 블로그 내용은 리눅스 전문가 분들이 PC를 사용할 때 도움이 될거라고 생각 됩니다. Linux 전문가 분들께서 Linux를 사용할 때는 수많은 도구를 사용해서 문제 해결을 하실 수 있는데 업무를 위해서 PC를 사용하다가 문제가 발생하면 해결하는 것에 어려움을 느끼시는 것을 봤습니다. 여기 소개드리는 도구들을 사용하시면 Linux의 문제 해결 방법을 Windows의 도구를 사용해서 적용해 보실 수 있습니다.

지난번 블로그에 올렸던 uptime 보다는 top 명령을 더 많이 사용하는 것 같습니다. (uptime에서 보여주었던 동작시간, load average 도 top에서 보여주고 있습니다.) 

top (Linux)

top을 실행하면 시스템 정보를 한번에 살펴볼 수 있습니다. 시스템이 얼마나 오랫동안 실행되고 있는지, 평균 부하는 얼마나 되는지, 실행중인 프로세스에 대한 정보, 메모리 상태는 어떤지를 보여줍니다. Windows 에서는 이러한 정보를 보려면 Process Explorer 같은 도구를 설치해서 봐야 하지만 Linux에서는 OS에 포함되어 있는 도구로 한 눈에 보여주는 것이 좋은 것 같습니다. 각각의 정보에 대한 설명은 나중에 운영체제 커널을 비교하면서 설명하려고 합니다.

top 에는 wa 값이 있어서 CPU가 IO를 기다리면서 소비한 시간의 비율을 보여주고 있는데 Windows 에서는 해당 값을 보여주는 도구가 없습니다. (제가 못 찾은 것일수도 있습니다.) 그리고 st (steal time) 도 가상머신을 위해 다른 task에서 사용된 CPU 사용량이라고 되어 있는데 이 값 또한 Windows에는 없습니다.

top을 실행할 때 -c 옵션을 주면 프로세스의 전체 경로를 보여줍니다.

top에서는 여러가지 명령어를 제공하는데 

1) k를 입력하면 특정 프로세스를 종료할 수 있습니다.

2) 여러가지 키를 이용해서 프로세스 리스트를 정렬할 수 있습니다. (M은 메모리 사용량, P는 CPU 사용량, N은 프로세스 ID, T는 실행 시간)

3) V를 입력하면 프로세스의 부모 자식 관계를 보여 줍니다.

4) h를 입력하면 도움말을 보여 줍니다.

Taskmgr (Windows)

Linux에 Top 이 있다면 Windows 에는 taskmgr이 있습니다. taskmgr 를 실행하면 우선 시스템 전반적인 성능 정보를 한 눈에 볼 수 있습니다. Taskmgr은 운영체제 버전마다 조금씩 다르기 때문에 이 글에서는 Windows 10을 사용했습니다. 

성능 탭에서는 각각의 프로세스에 대한 정보를 보여주지 않기 때문에 세부정보 탭을 클릭해서 세부 정보를 볼 수 있습니다. 

Taskmgr 에서도 여러가지 추가 정보를 볼 수 있는데 컬럼 헤더를 마우스 오른쪽 클릭하면 열 선택 메뉴가 나오고 확인하고자 하는 정보를 선택하면 됩니다. 이전 Windows를 사용한다면 메뉴에서 보기 - 열선택 을 사용할 수 있습니다. 열 선택에서 명령줄을 선택하면 위에 보이는 것 처럼 프로세스의 전체 경로와 어떤 파라미터가 전달 되었는지 알 수 있습니다. svchost나 java 처럼 하나의 실행 파일이 다양한 방법으로 실행될 수 있을때 유용합니다.

top에서 프로세스를 종료 시킬 수 있는 것처럼 Taskmgr에서도 작업 끝내기로 프로세스를 종료할 수 있습니다. 그리고 덤프 파일 만들기로 프로세스의 덤프 파일을 만들 수 있고 서비스로 이동을 클릭하면 해당 프로세스의 서비스로 이동 합니다. svchost 처럼 하나의 실행 파일이 많은 서비스에 사용되고 있을때 유용하게 사용할 수 있습니다.

리소스 모니터(Windows)

메모리에 대한 좀 더 자세한 정보를 확인 하려면 리소스 모니터를 사용할 수 있습니다. 실행 방법은 두 가지가 있는데 하나는 taskmgr를 실행한 후 성능 탭을 클릭하면 아래쪽에 리소스 모니터 열기 버튼이 있습니다. 명령 줄로 실행하는 방법은 perfmon /res 명령을 실행하면 됩니다.

리소스 모니터의 CPU 탭을 선택하면 Process 들의 정보를 확인할 수 있습니다. 특정 프로세스를 선택하면 해당 프로세스에서 사용하고 있는 핸들 정보를 보여줍니다. (한글화의 문제인지 "연결된 핸" 이라고만 나오네요 TT) 여기서 핸들은 Linux의 FD라고 생각하시면 됩니다. 

핸들 검색에 파일명이나 핸들 정보 등을 넣어서 검색하면 해당 핸들을 사용하는 프로세스를 찾을 수 있습니다. 예를 들면 특정 디렉토리나 파일을 삭제 하려고 할때 다른 프로세스가 사용중이라고 하면 리소스 모니터의 핸들 검색을 통해서 해당 디렉토리나 파일을 사용하는 프로세스를 찾을 수 있습니다.

메모리 탭을 눌러보면 물리 메모리에 대한 정보를 보여주는데 사용중, 대기모드, 여유 등의 메모리 상태를 확인할 수 있습니다. 수정한 날짜는 잘못된 한글화 인데 실제로는 Modified 메모리로 수정된 메모리 입니다. 여유는 Free 메모리 입니다. 

Windows 에서도 가능한한 물리 메모리를 많이 사용하려고 캐시를 많이 사용하고 있습니다. 하지만 캐시 메모리는 언제든지 제거할 수 있는 것이기 때문에 사용 가능한 메모리로 계산 됩니다.

마지막으로 네트워크 탭을 누르면 각 프로세스별로 네트워크의 사용률, 보내고 받기를 하고 있는 주소, 포트 정보 등을 확인할 수 있습니다.

Linux를 공부하면서 Windows와 Linux의 같은 점과 다른 점을 비교하는 블로그를 하면 좋겠다는 생각이 들었습니다.

Linux 명령을 사용해서 시스템의 정보를 확인할 때 Windows에도 동일한 정보를 얻을 수 있는 명령이 있다는 생각을 하였고 Windows를 잘 아시는 엔지니어들은 Linux를 잘 모르고 Linux를 잘 아시는 엔지니어들은 Windows를 잘 알지 못한다는 생각이 들어 동일한 정보를 확인하는 방법을 Windows와 Linux로 설명하면 도움이 될 것 같다는 생각을 하였습니다.

저는 Windows에 대해서는 잘 알고 있지만 Linux에 대해서는 초보 이기 때문에 Linux 명령을 확인하면서 Windows의 동일한 명령을 정리하고자 합니다.

uptime

uptime은 시스템이 시작된지 얼마나 되었으며 1분, 5분 15분 동안의 평균 부하가 얼마나 되었는지 보여줍니다. 시스템의 평균 부하는 실행 가능한 상태 혹은 중단 불가능한 상태의 프로세스들의 평균 개수라고 합니다.

Taskmgr

Linux에 uptime이 있다면 Windows에는 taskmgr이 있습니다. 시작 - 실행 - taskmgr을 입력해서 실행할 수도 있고 Ctrl + Shift + Esc를 눌러서 실행할 수 도 있습니다. 성능 탭을 클릭하면 uptime과 비슷한 정보를 볼 수 있습니다. uptime과는 달리 taskmgr을 실행 시키기 이전의 부하는 알 수 없으며 taskmgr을 실행한 이후의 부하를 알 수 있습니다.

uptime과 Taskmgr이 동일하다고 볼수는 없지만 시스템의 부하를 간단히 보여준다는 점에서 동일한 도구로 볼 수 있습니다.

Windows Server 2019에 해당하는 Windows Server 2019 Insider Preview Build 17639가 공개 되었습니다.

이번에 공개된 것은 10년 기술지원을 받을 수 있는 LTSC 릴리즈이고 GUI를 이용하는 Desktop Experience와 Server Core 버전 입니다. (Nano server는 SAC 릴리즈만 제공됩니다.)

In-place upgrades

Windows Server 2012 R2와 2016에서 Windows Server 2019로 In-place upgrade를 지원 합니다.

Storage Migration Service

Windows Server에서는 데이터 마이그레이션 기능이 취약했었는데 Windows Server 2019에서 Storage Migration Service(SMS) 라는 롤이 추가 되었습니다. 기존 서버에서 데이터, 보안 설정, 네트워크 설정 등을 SMB 프로토콜을 사용해서 마이그레이션하는 기능으로 호놀룰루 기반의 그래픽 관리 시스템으로 되어 있습니다.

Storage Replica

Windows Server 2016 Datacenter 에서만 가능하던 Storage Replica 기능이 사용자들의 꾸준한 요청으로 Standard에서도 사용할 수 있게 되었습니다. Standard에서는 하나의 볼륨만 최대 2TB 까지 복제가 가능 합니다. 계속 요청을 등록하여 Storage Space Direct도 Standard에서 사용할 수 있게 되었으면 합니다.

참고) https://blogs.windows.com/windowsexperience/2018/04/10/announcing-windows-server-2019-insider-preview-build-17639/amp/?__twitter_impression=true

프로세스의 핸들 수가 많이 증가 되었거나 시스템에 커널 메모리 사용량이 많이 올라가면 어떤 핸들이 많이 사용되었는지 확인해야 합니다.

일반적으로 우리가 핸들 수를 확인하는 방식은 아래와 같습니다.

1. 작업 관리자를 열어서 세부정보나 프로세스 탭에서 "열 선택"을 한 후 핸들을 선택해서 각 프로세스의 핸들 수를 확인

2. Process Explorer를 실행해서 해당 프로세스를 선택한 후 View - Lower Pane View - Handles 를 선택해서 어떤 핸들이 있는지 확인.

그런데 이 방법을 사용하면 해당 프로세스에 핸들이 많다는 것은 확인할 수 있는데 어떤 종류의 핸들이 많이 있는지는 확인하기 힘듭니다.

이 경우에 사용할 수 있는 것이 명령 줄에서 사용할 수 있는 handle.exe 입니다.

Handle v4.11

https://docs.microsoft.com/ko-kr/sysinternals/downloads/handle

사용 방법은 아래와 같습니다.

1. 시스템 전체의 핸들 수를 종류별로 알고 싶을 때

C:\Users\clust>handle -s

Nthandle v4.11 - Handle viewer
Copyright (C) 1997-2017 Mark Russinovich
Sysinternals - www.sysinternals.com

Handle type summary:
  <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>  : 2
  <Unknown type>  : 7
  <Unknown type>  : 21730
  <Unknown type>  : 12
  <Unknown type>  : 1
  <Unknown type>  : 60
  <Unknown type>  : 8
  <Unknown type>  : 7
  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

Nthandle v4.11 - Handle viewer
Copyright (C) 1997-2017 Mark Russinovich
Sysinternals - www.sysinternals.com

Handle type summary:
  <Unknown type>  : 110
  ALPC Port       : 10
  Desktop         : 1
  Directory       : 2
  Event           : 32
  File            : 10
  IoCompletion    : 3
  IoCompletionReserve: 1
  IRTimer         : 4
  Key             : 22
  Mutant          : 4
  Section         : 8
  Semaphore       : 18
  Thread          : 6
  Timer           : 2
  TpWorkerFactory : 2
  WaitCompletionPacket: 12
  WindowStation   : 2
Total handles: 249

3. 프로세스 별로 핸들의 자세한 정보를 알고자 할때

C:\Users\clust>handle -u

Nthandle v4.11 - Handle viewer
Copyright (C) 1997-2017 Mark Russinovich
Sysinternals - www.sysinternals.com

------------------------------------------------------------------------------
System pid: 4 \<unable to open process>
------------------------------------------------------------------------------
smss.exe pid: 536 \<unable to open process>
------------------------------------------------------------------------------
csrss.exe pid: 796 \<unable to open process>
------------------------------------------------------------------------------

...

...

------------------------------------------------------------------------------
sihost.exe pid: 1092 CLUSTALEEY700\clust
   40: File          C:\Windows\System32
  16C: File          C:\Windows\Registration\R00000000000d.clb
------------------------------------------------------------------------------
svchost.exe pid: 13964 CLUSTALEEY700\clust
   44: File          C:\Windows\System32
  280: File          C:\Windows\Registration\R00000000000d.clb
  4E8: File          C:\Windows\System32\ko-KR\winnlsres.dll.mui
  634: File          C:\Users\clust\AppData\Local\ConnectedDevicesPlatform\908b443ce4ed0b0c\ActivitiesCache.db
  638: File          C:\Users\clust\AppData\Local\ConnectedDevicesPlatform\908b443ce4ed0b0c\ActivitiesCache.db-wal
  63C: File          C:\Users\clust\AppData\Local\ConnectedDevicesPlatform\908b443ce4ed0b0c\ActivitiesCache.db-shm