서버에 네트워크가 연결되지 않을때 네트워크 어뎁터 상태, ip address 구성, route 정보, ping, 네트워크 연결 상태, 네트워크 연결 테스트, 방화벽 설정 등을 점검하는 방법에 대해서 정리해 보았습니다.


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

네트워크 어뎁터가 연결되어 있는지 확인하기 위해 리눅스 에서는 ethtool을 사용합니다. 명령의 결과 가장 아래에 Link detected 가 yes로 되어 있으면 네트워크 어뎁터가 연결되어 있는 것입니다.


네트워크 IP 구성이 잘 되어있는지 확인하기 위해 ip address 명령을 사용 합니다. 


라우팅 정보는 route 명령을 사용해서 확인 합니다.


다른 장비로 Ping이 되는지 테스트 해봅니다.


라우팅 경로는 traceroute를 사용하고 mtr을 사용해서 좀 더 자세한 정보를 얻을 수 있습니다.

Network port 가 열려 있는지는 telnet, nc, nmap 등의 도구로 테스트 가능하나 샘플로 테스트는 진행하지 못했습니다.


Network connection 상태는 netstat 명령을 사용하면 확인 가능 합니다.


-------------------------------------------------------- ESXi -----------------------------------------------------------

네트워크 어뎁터가 연결되어 있는지 확인하기 위해 ESXi에서는 esxcli network nic list 명령을 사용합니다. Link Status 값이 Up으로 되어 있으면 네트워크가 연결된 것입니다.


ESXi 에서는 esxcli network ip interface ipv4 address list 명령을 사용해서 IP address와 netmask를 알 수 있습니다. CLI로 물리 어뎁터의 IP를 확인하는 방법은 찾지 못했습니다. vCenter나 Console에서 확인이 가능하기는 하지만 esxcli 또는 PowerCLI로 확인하는 방법도 있을것 같습니다.


라우팅도 esxcli 명령을 사용해서 확인 합니다.


esxi 에서는 vmkping을 사용해서 네트워크 상태를 확인할 수 있습니다. -s를 이용하면 패킷의 크기를 조절할 수 있고, -I 옵션을 사용하면 특정 vmk 을 사용해서 ICMP를 보낼 수 있습니다.


ESXi 에서도 traceroute를 사용할 수 있습니다.


telnet은 예전 버전에서는 사용 가능했던 것으로 보이나 6.7에서는 실행되지 않았습니다. 대신 nc를 사용하면 됩니다. 자세한 내용은 아래 KB를 확인하면 됩니다.

https://kb.vmware.com/s/article/2020669


Network 이 연결된 상태를 확인하려면 esxcli network ip connection list 명령을 사용하면 됩니다. 자세한 설명은 KB에 있습니다.

https://kb.vmware.com/s/article/2020669?lang=en_US


Network connection의 상태는 esxcli network ip connection list 명령을 통해서 확인 가능 합니다.


ESXi 에도 기본적으로 방화벽이 설정되어 있습니다. esxcli network firewall ruleset rule list 명령을 통해서 어떤 포트가 열려 있는지 확인 가능 합니다.


------------------------------------------------------ Windows ---------------------------------------------------------

Windows 에서는 NIC가 연결되어 있는지 확인은 GUI로 할 수 도 있으나 PowerShell로 확인해 보도록 하겠습니다. Get-NetAdapter cmdlet을 사용하면되고 Ethernet1 은 Network cable이 Disconnect 되어 있는 상태이고 Ethernet0은 정상적으로 연결되어 있는 상태인 것을 확인할 수 있습니다.


Windows 에서는 ipconfig 명령을 사용하는 것이 더 일반적이지만 PowerShell의 Get-NetIPAddress cmdlet을 사용해 보았습니다. Windows 에서도 ipconfig, netstat 명령처럼 오래전에 개발된 명령들은 더이상 추가 개발이나 수정을 하지 않기 때문에 PowerShell을 사용하는 것에 익숙해질 필요가 있습니다.


라우팅도 route print 명령이 있지만 PowerShell을 사용해서 확인 합니다.


Ping을 사용할 수 있지만 역시 PowerShell을 사용하도록 하겠습니다. Test-Connection은 ICMP를 보내는 Ping과 유사하다고 생각하면 됩니다. Test-NetConnection으로 Port를 지정해주면 해당 포트가 열려 있는지 확인할 수 있습니다. (Windows 에서 보안 이슈로 telnet은 기본 설치가 아닙니다. Feature로 추가를 하거나 Test-Connection 명령으로 테스트를 해야 합니다.)


Windows 에서는 Tracert를 사용할 수 있는데 PowerShell의 Test-NetConnection을 사용할 수도 있습니다. Windows에는 mtr과 같은 도구가 설치되어 있지 않은데 PowerShell로 개발된 스크립트가 있으니 대용으로 사용할 수 있습니다. https://gist.github.com/tylerapplebaum/dc527a3bd875f11871e2


Network의 연결 상태는 netstat 명령으로도 확인 가능하지만 Get-NetTCPConnection cmdlet으로 확인 가능 합니다. netstat에 마이너한 버그가 있었던 것으로 기억하는데 오래전 코드라 수정을 안한다고 기억 합니다.


방화벽 설정 룰을 확인하는 PowerShell cmdlet은 Get-NetFirewallRule, Get-NetFirewallPortFilter 를 조합하는 것인데 사용법이 편하지 않습니다. (블로그를 보면 이 cmdlet을 조합하는 것이 있습니다. https://itluke.online/2018/11/27/how-to-display-firewall-rule-ports-with-powershell/) 

방화벽 설정은 기존 netsh 명령으로 확인을 할 수 있습니다.



감사합니다.


시스템 행 현상이 발생 되었을때 원인 분석을 하는 방법에 대해서 글을 써보려고 하고 다음번 글에서는 행 덤프를 분석하는 방법을 쓰려고 합니다.


Windows나 ESXi 모두 커널 레벨에서 행이 발생하였을때 Reset을 해서 시스템을 재부팅하는 방법으로 문제를 해결하는 경우가 종종 있습니다. 하지만 문제가 빈번하게 재현되고 운영중인 Application이 중요한 역할을 하는 경우 원인 분석을 해야 하는 경우가 많이 있습니다. 행 현상이 발생하면 NMI를 이용해서 덤프를 수집하는 방법을 알아보겠습니다.


NMI란 무엇인가?

우선 NMI가 무엇인지 확인해보면 Wiki에 Non-maskable interrupt 라고 되어 있고 하드웨어가 발생시키는 인터럽트로 시스템이 ignore 할 수 없다고 되어 있습니다. 하지만 NMI는 하드웨어에서 발생시키는 경우만 있는 것이 아니라 행 분석을 위해서 시스템에 있는 NMI switch를 눌러(쇼트)서 수동으로 발생시키는 경우도 있습니다.

https://en.wikipedia.org/wiki/Non-maskable_interrupt


먼저 하드웨어로 인한 문제를 확인해 보겠습니다. 아래 HPE의 문서를 보면 하드웨어 이슈로 NMI가 호출되어 VMware의 ESXi에서 PSOD가 발생되었다고 합니다.

Advisory: (Revision) VMware - HPE ProLiant Gen8 Servers running VMware ESXi 5.5 Patch 10, VMware ESXi 6.0 Patch 4, Or VMware ESXi 6.5 May Experience Purple Screen Of Death (PSOD): LINT1 Motherboard Interrupt

https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c05392947

ESXi host fails with intermittent NMI purple diagnostic screen on HP servers (2085921)

https://kb.vmware.com/s/article/2085921

ESXi host fails with intermittent NMI PSOD on HP ProLiant Gen8 servers (2149043)

https://kb.vmware.com/s/article/2149043


VMware 환경에서 하드웨어로 인한 NMI 크래시에 대해서 설명하고 있습니다.

"LINT1 motherboard interrupt" error in an ESX/ESXi host (1804)

https://kb.vmware.com/s/article/1804


Windows 환경에서도 유사하가 하드웨어(Memory) 오류로 NMI가 호출되어 시스템이 BSOD가 발생된 것이 확인됩니다.

NMI Memory Parity error received during shutdown on Windows 7 and Windows Server 2008 R2

https://support.microsoft.com/en-au/help/2845432/nmi-memory-parity-error-received-during-shutdown-on-windows-7-and-wind


물리적인 하드웨어 뿐만 아니라 가상 하드웨어로 인해서 NMI가 발생할 수도 있습니다. 

VMware ESXi 5.5.x and 6.x hosts experiences a purple diagnostic screen mentioning ALERT: NMI: 709: NMI IPI received (2149704)

https://kb.vmware.com/s/article/2149704


하드웨어로 인한 NMI가 발생한 경우 하드웨어 업체에 연락을 해서 관련 이슈가 있는지 파악을 하고 하드웨어 점검, Firmware, Driver 업데이트 등을 진행할 수 있습니다. 문제가 계속 재현되는 경우 하드웨어를 교체해야할 수도 있습니다.


시스템 행 현상이 발생하였을 때 NMI를 이용한 행 덤프 수집

시스템 행 현상은 ESXi host에 ssh 접속이 안되거나 Windows 의 경우 RDP 등이 접속안되는 상태를 이야기 합니다. 결국 시스템의 중요 프로세스가 응답하지 못하는 상태가 되어 SSH 연결이나 RDP 연결을 받아주지 못하는 경우를 이야기 합니다. 이런 경우 우선 Ping을 해서 하드웨어 레벨에서 행이 걸렸는지 확인해볼 수 있습니다. Ping은 되는데 SSH나 RDP가 안되는 경우 하드웨어가 아닌 소프트웨어 이슈로 시스템이 응답하지 않는 것입니다.

시스템 행 현상이 발생하면 일반적으로 Reset 키를 눌러서 시스템을 재부팅을 하게 되는데 기술지원 계약이 되어 있는 경우 NMI를 이용해서 Dump를 수집하면 원인분석을 의뢰 할 수 있습니다.


-------------------------------------------------------- ESXi -----------------------------------------------------------

VMware는 KB문서를 통해서 시스템 행 현상이 있을 때 덤프를 수집하는 방법을 가이드 하고 있습니다.

ESXi host fails with intermittent NMI PSOD on HP ProLiant Gen8 servers (2149043)

https://kb.vmware.com/s/article/2149043https://kb.vmware.com/s/article/1014767


문서의 내용을 살펴보면 행 현상이 어떤 것인지 정의를 먼저 하고 있습니다. 행 현상은 vSphere client 에 응답하지 않거나, Ping에 응답하지 않거나, ESXi에서 실행중인 VM이 network에 응답하지 않거나, 콘솔 명령에 응답하지 않거나, Alt+F12를 콘솔에서 눌렀을때 VMkernel log가 화면에 출력되지 않는 경우를 이야기 합니다. 행 현상이 하드웨어에 의한 것인지 확인하기 위해 NumLock 키를 눌러 보거나 디스크나 네트워크에 워크로드가 있는지 확인, Ping으로 확인하는 등의 작업을 할 수 있지만 원인 분석을 위해서는 NMI를 이용해서 덤프를 수집해야 합니다.

Determining why an ESX/ESXi host does not respond to user interaction at the console (1017135)

https://kb.vmware.com/s/article/1017135?CoveoV2.CoveoLightningApex.getInitializationData=1&r=2&ui-communities-components-aura-components-forceCommunity-seoAssistant.SeoAssistant.getSeoData=1&other.KM_Utility.getArticleDetails=1&other.KM_Utility.getArticleMetadata=2&other.KM_Utility.getUrl=1&other.KM_Utility.getUser=1&other.KM_Utility.getAllTranslatedLanguages=2&ui-comm-runtime-components-aura-components-siteforce-qb.Quarterback.validateRoute=1


NMI를 사용해서 수동으로 덤프를 수집하기 위해서는 ESXi에 설정이 필요한데 ESXi 5.0 이후로는 별도의 설정 없이 NMI 버튼을 누르면 PSOD 덤프가 수집 됩니다.

KB의 마지막 부분에는 각 하드웨어 별로 NMI를 발생시키는 방법이 가이드 되어 있습니다.

Triggering the NMI

The NMI button or switch location varies depending on the hardware. A small set of examples are available:


IBM x3650 M2 – The NMI button is on the diagnostic panel. There may also be a Send NMI button in the RSA. For more information, see the x3650 M2 Installation and Users Guide.

 

HP Proliant – The NMI button or jumper is on the motherboard. There is also a Send NMI button in the iLO. For more information, see Performing an HP ProLiant server NMI crash dump.

 

Dell R900 – The NMI button is on the front panel. For more information, see the R900 Systems Hardware Owner's Manual.

 

Fujitsu PRIMERGY Servers (RX/TX) - The NMI button is on the front of the server. For more information, see the Operating Manual for your PRIMERGY Servers. The manual can be found at the Fujitsu website.

 

Click [Industry standard servers] - [PRIMERGY Servers]

Select your PRIMERGY Servers from the pulldown menu. For example, [PRIMERGY RX Servers] - [PRIMERGY RX300 Sriese] - [PRIMERGY RX300 S7]

Download the Operating Manual and check for the NMI button location.

Cisco UCS – The NMI can be sent via IPMI or the UCS Manager command-line interface:

IPMI command – ipmitool -I lan -H <RemoteServerBMCAddress> -U <Username> -a chassis power diag

UCSM command – diagnostic-interrupt.


For more information, see the Cisco UCS command-line reference documentation for the diagnostic-interrupt command.

The preceding links were correct as of November 6, 2013. If you find a link is broken, provide feedback and a VMware employee will update the link.


ESXi 호스트가 아닌 VM에 행 현상이 발생할 경우에도 NMI를 이용해서 덤프를 수집할 수 있습니다. ESXi 에서는 Snapshot을 이용해서 메모리 파일을 덤프 파일로 변환하는 방법으로 덤프를 수집할 수 도 있지만 VM에 NMI 인터럽트를 전달해서 행 덤프를 수집할 수도 있습니다. vCenter Web Clinet를 이용하거나 VM-support 명령 또는 vmdumper 명령을 사용해서 덥프를 수집할 수 있습니다.

How to send NMI to Guest OS on ESXi 6.x (2149185)

https://kb.vmware.com/s/article/2149185

How to capture a vmcore of hung Red Hat Enterprise Linux VMware® guest system using VMware® "vmss2core" tool ?

https://access.redhat.com/solutions/411653


아래 문서는 NMI로 인해 Windows VM이 크래시 된 것에 대한 설명을 하고 있습니다.

Windows virtual machines fails with a Stop Error: Hardware Malfunction - Call your hardware vendor for support (2105345)

https://kb.vmware.com/s/article/2105345


아래 문서에서는 Red Hat 리눅스가 행 현상이 있을때 ESXi 에서 NMI를 발생하는 방법을 설명하고 있습니다.

Red Hat Enterprise Linux - How to Force a Crash on a Hung Linux Virtual Machine Running on VMware ESXi Server

https://support.hpe.com/hpsc/doc/public/display?docId=mmr_kc-0105964


------------------------------------------------------ Windows ---------------------------------------------------------

Microsoft 에서는 아래 문서에서 행 현상이 있을때 덤프를 수집하는 방법을 설명하고 있습니다.

How to generate a kernel or a complete memory dump file in Windows Server

https://support.microsoft.com/en-us/help/969028/how-to-generate-a-kernel-or-a-complete-memory-dump-file-in-windows-ser


이 문서에서 별도로 행 현상에 대해서 설명을 하고 있지는 않지만 ESXi와 비슷하게 RDP 접속해보기, Numslock 눌러보기, Ping 해보기 등으로 행 현상이 있는지 확인해볼 수 있습니다.

Windows 는 커널 덤프, 전체 덤프와 같이 덤프의 유형이 있는데 각 유형에 따라서 적절한 페이지 파일 크기를 설정해 주어야 덤프파일이 정상적으로 수집됩니다. 커널 덤프의 경우 Windows 커널이 사용하는 메모리만 덤프 파일에 저장하는 것으로 커널의 메모리 사용량에 따라서 2 ~ 16GB 정도면 충분한 크기라고 할 수 있습니다. 전체 덤프의 경우 물리 메모리의 내용을 모두 덤프 파일에 저장하는 것으로 물리메모리 크기 + 1MB 이상의 페이지 파일이 있어야 덤프를 수집할 수 있습니다. Windows 커널의 행 현상에 대해서는 커널 덤프로 분석이 가능하지만 유저모드 프로세스의 행 현상은 전체 덤프를 수집해야 분석이 가능할 수 있습니다.

Windows 시스템에서는 일반적으로 키보드 (오른쪽 Ctrl 키를 누른 상태에서 Scroll Lock 를 두번 누르기)를 이용해서 덤프를 수집할 수 있는데 별도의 설정을 키보드에 해야하기 때문에 문제가 발생하기 전에 운영하는 시스템에 모두 키보드 덤프를 설정해 두어야 합니다. 덤프 생성을 위한 키를 변경할 수도 있으며 

Forcing a System Crash from the Keyboard

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/forcing-a-system-crash-from-the-keyboard


Windows 시스템에서도 NMI를 이용해서 덤프를 수집할 수 있습니다. 

How to generate a complete crash dump file or a kernel crash dump file by using an NMI on a Windows-based system

https://support.microsoft.com/en-us/help/927069/how-to-generate-a-complete-crash-dump-file-or-a-kernel-crash-dump-file


Windows 8, Windows Server 2012 이전까지는 NMI 레지스트리 키를 설정해 주어야 했지만 이제는 기본 값으로 NMI 덤프가 설정되어 있습니다.
NMI_HARDWARE_FAILURE error when an NMI is triggered on Windows 8 and Windows Server 2012
https://support.microsoft.com/en-us/help/2750146/nmi-hardware-failure-error-when-an-nmi-is-triggered-on-windows-8-and-w


PowerShell을 사용해서 Hyper-V 에서 VM에 NMI 인터럽트를 발생시키는 방법도 있습니다.

Debug-VM

https://docs.microsoft.com/en-us/powershell/module/hyper-v/debug-vm?view=win10-ps


Azure 환경에서 Serial console을 사용해서 Guest에 NMI를 보내는 방법도 있습니다. AWS에서는 어떻게 NMI를 보낼 수 있는지 찾지를 못했습니다.

Use Serial Console for SysRq and NMI calls

https://docs.microsoft.com/ko-kr/azure/virtual-machines/troubleshooting/serial-console-nmi-sysrq


다음 번에는 수집된 덤프를 분석하는 방법을 써보려고 합니다.


감사합니다.




최근에 BSOD 분석을 넘어서 PSOD 분석을 하고 있습니다. 처음에는 gdb 사용법을 전혀 몰라서 고생을 했는데 이제는 간단한 분석은 회사 시스템을 통해서 할 수 있게 되었습니다.

디버깅을 하면서 느낀 것은 Windows Kernel Debugging과 원리는 비슷한데 실제 구현은 다르다는 것입니다. 비슷하면서 다른 점을 확인해보면 Windows kernel에 있는 spinlock이라는 개념이 동일하게 LinuxESXi에 있고 ESXi 에서는 spinlock을 오래 소유하면 시스템이 크래시 될 수 있습니다. Windows 에서는 Spinlock을 오래 소유하면 행만 말생하고 크래시가 되지는 않습니다. (시스템을 행 상태로 둘 것인지? 아니면 크래시를 해서라도 행을 해소하고 원인 분석을 할지는 업체마다 판단이 다릅니다.)

아래 VMware 문서의 설명을 보면 Spinlock을 오래 소유하고 있어서 Spinlock count가 한계에 달해서 시스템이 크래시 되었다고 합니다. 스택에 나오는 것은 Spinlock을 소유하기 위해 대기하는 Thread 이어서 원인을 찾기 위해서는 Spinlock을 소유한 Thread를 찾아야합니다. 일반적으로 원인은 ESXi 또는 3rd party kernel driver spinlock을 해제하지 않았기 때문입니다.

MicrosoftWinDbg를 통해서 BSOD를 분석할 수 있게 공개하였지만 VMware는 디버깅 방법이 공개되어 있지 않기 때문에(아마도 공개 안 되어 있을 것 같습니다.) VMware support 부서에 연락해서 기술지원을 받아야 할 것입니다. 만약 원인 분석 보다는 문제 예방을 원하실 경우 ESXi 와 각종 드라이버를 최신으로 update 하면 좋습니다. 신규 버그가 아니라면 패치를 설치해서 기존 문제들을 해결할 수 있습니다. 그래도 문제가 재현된다면 core dump 파일을 수집해서 업체의 분석을 받아야 합니다.

 

Understanding a "Spin count exceeded" purple diagnostic screen (1020105)

https://kb.vmware.com/s/article/1020105

VMware ESX Server [Releasebuild-207095]

Spin count exceeded (iplLock) - possible deadlock

cr2=0xb6ea3fff cr3=0x22401000 cr4=0x6f0

frame=0x14028d4 ip=0x626265

es=0xffffffff ds=0xffffffff fs=0xffffffff gs=0xffffffff

eax=0xffffffff ebx=0xffffffff ecx=0xffffffff edx=0xffffffff

ebp=0x1402a3c esi=0xffffffff edi=0xffffffff err=-1 eflags=0xffffffff

*0:1024/console 1:1094/vmm0:M100 2:1086/vmware-vm 3:1118/mks:dby-d

4:1109/vmm0:M102 5:1116/vmm0:dby- 6:1096/mks:M1000 7:1082/vmm0:M100

@BlueScreen: Spin count exceeded (iplLock) - possible deadlock

0x1402a3c:[0x626265]Panic+0x10 stack: 0x83821c, 0x2970608, 0x4

0x1402a90:[0x634ff3]SP_WaitLock+0x1ca stack: 0x2970600, 0x1402ab8, 0x9d75ef

0x1402a9c:[0x9b1386]cosShadow+0x385 stack: 0x0, 0x2865a40, 0x2865a40

0x1402ab8:[0x9d75ef]cosShadow+0x265ee stack: 0x0, 0xa8ae9be8, 0x53ac1

0x1402af0:[0x63b947]TimerBHHandlerLoop+0x18e stack: 0x1456c98, 0x0, 0x148a798

0x1402b30:[0x63e7b1]Timer_BHHandler+0xb8 stack: 0x0, 0xdf, 0x0

0x1402b88:[0x6188c5]BH_Check+0x84 stack: 0x1, 0x1402bac, 0x1754941

0x1402bac:[0x620126]IDT_HandleInterrupt+0x85 stack: 0x1402bf8, 0x0, 0x37638000

0x1402bc0:[0x62024d]IDT_IntrHandler+0x4c stack: 0x1402bf8, 0x4028, 0x4028

0x1402c70:[0x693b7c]CommonIntr+0xb stack: 0x14897a0, 0x0, 0x1402de0

0x1402e1c:[0x763234]CpuSchedDispatch+0x487 stack: 0x2391f00, 0x14897a0, 0x0

0x1402e88:[0x765a36]CpuSchedDoWaitDirectedYield+0x351 stack: 0x0, 0x1f57f60, 0x0

0x1402ea4:[0x765b66]CpuSched_WaitIRQ+0x31 stack: 0xfedcba90, 0x6, 0x1f57f60

0x1402ec4:[0x692893]VMNIXVMKSyscall_Idle+0xe2 stack: 0x1402f6c, 0x6924e3, 0x0

0x1402ecc:[0x687538]VMNIXVMKSyscallUnpackIdle+0x7 stack: 0x0, 0x0, 0x0

0x1402f6c:[0x6924e3]HostSyscall+0xf6 stack: 0x1402fbc, 0xc03dbf98, 0x1c

0x1402fe8:[0x69187f]HostVMKEntry+0xce stack: 0x0, 0x0, 0x0

VMK uptime: 6:09:43:15.399 TSC: 1472031313725856

Starting coredump to disk Starting coredump to disk Dumping using slot 1 of 1... using slot 1 of 1... log

 

 

Windows에는 Spinlock에 의한 크래시는 없지만 인터럽트의 후속처리를 하는 DPC (LinuxBottom half에 해당하는 것으로 보임) 에서 너무 많은 시간 동은 실행이 되면 BugCheck 0x133이 발생합니다. 일반적으로 HW 에서 인터럽트가 발생하고 DPC 루틴을 실행할 때 너무 시간이 많이 걸려서 크래시 되는 것입니다.

Bug Check 0x133 DPC_WATCHDOG_VIOLATION

https://docs.microsoft.com/ko-kr/windows-hardware/drivers/debugger/bug-check-0x133-dpc-watchdog-violation

 

DPC 루틴 하나가 너무 많은 시간을 사용한 경우 콜스택만 보면 원인을 확인할 수 있으나 다수의 DPC 루틴이 실행된 경우 원인을 찾기가 힘들어집니다. 이 경우 아래 블로그를 참고해서 xPerf를 실행해야할 수도 있습니다. (Microsoft의 지원을 받으셔야 원인을 찾을 수 있습니다.)

Determining the source of Bug Check 0x133 (DPC_WATCHDOG_VIOLATION) errors on Windows Server 2012

https://blogs.msdn.microsoft.com/ntdebugging/2012/12/07/determining-the-source-of-bug-check-0x133-dpc_watchdog_violation-errors-on-windows-server-2012/

 

아래와 같이 HP 드라이버에서 문제가 발생할 수도 있고 Windows Kernel의 문제로 발생할 수도 있습니다.

권고: HP 네트워크 서버 어댑터 - Windows Server 2012 R2에서 ocnd64.sys v11.1.145.30 드라이버를 실행하면 Bugcheck 0x133 오류가 발생할 수 있음

https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00005104es_es

FIX: Stop error 0x133 or 0x9E occurs when WHEA record is not acknowledged by SMI in Windows

https://support.microsoft.com/en-us/help/2877237/fix-stop-error-0x133-or-0x9e-occurs-when-whea-record-is-not-acknowledg

Analyzing the dump showed the following stack

DPC_WATCHDOG_VIOLATION (133)

The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL

or above.

Arguments:

Arg1: 0000000000000001, The system cumulatively spent an extended period of time at

DISPATCH_LEVEL or above. The offending component can usually be

identified with a stack trace.

Arg2: 0000000000003c19, The watchdog period.

Arg3: 0000000000000000

Arg4: 0000000000000000

 

Debugging Details:

------------------

 

 

DPC_TIMEOUT_TYPE: DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED

 

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

 

BUGCHECK_STR: 0x133

 

PROCESS_NAME: System

 

CURRENT_IRQL: d

 

ANALYSIS_VERSION: 6.13.0015.1713 (debuggers(dbg).130203-2012) amd64fre

 

LAST_CONTROL_TRANSFER: from fffff802145e3cb3 to fffff80214464440

 

STACK_TEXT:

fffff880`0c4a54f8 fffff802`145e3cb3 : 00000000`00000133 00000000`00000001 00000000`00003c19 00000000`00000000 : nt!KeBugCheckEx

fffff880`0c4a5500 fffff802`144a8774 : fffff880`0c4a5670 00000000`0042f906 fffff880`0c4a5680 fffff780`00000320 : nt! ?? ::FNODOBFM::`string'+0x14600

fffff880`0c4a5580 fffff802`14b78eca : 00000000`00000001 fffffa80`31427a01 00000000`00275f48 fffffa80`437f7000 : nt!KeUpdateTime+0x2ec

fffff880`0c4a5760 fffff802`1445d00e : 0000009f`6bc998e4 ffff7af7`41437906 fffff802`14ba2580 00001f80`004a0260 : hal!HalpTimerClockInterrupt+0x86

fffff880`0c4a5790 fffff802`14b740ba : fffffa80`437f70b8 00000000`00010008 00000000`0000e39d fffff802`14b96e80 : nt!KiInterruptDispatchLBControl+0x1ce

fffff880`0c4a5920 fffff880`00d79c88 : 00000000`00000001 00000000`00000001 fffff802`14b96e80 00000000`00000001 : hal!HalpTimerStallExecutionProcessor+0x10b

fffff880`0c4a59b0 fffff880`00d787f8 : 00000000`00000001 fffff802`14b96e80 00000000`00000700 fffff802`1456a72d : PSHED!PshedpWaitForOperationToComplete+0x1c

fffff880`0c4a59e0 fffff880`00d77539 : fffffa80`00000609 fffff802`14b96e80 fffffa80`321fb950 fffffa80`437f7010 : PSHED!PshedpWriteErrorRecordERST+0x89

fffff880`0c4a5a10 fffff802`1456ac60 : 00000000`00000001 00000000`00000000 00000000`00000000 fffffa80`437f7038 : PSHED!PshedWriteErrorRecord+0x71

fffff880`0c4a5a40 fffff802`14b83703 : fffff880`00000728 00000000`00000000 fffff880`0c4a5ba0 fffff802`14b96e80 : nt!WheaReportHwError+0x200

fffff880`0c4a5aa0 fffff802`14b831f3 : 00000000`00000001 00000000`00000000 fffff880`0c4a5c50 00000000`00000000 : hal!HalpMcaReportError+0x53

fffff880`0c4a5c00 fffff802`14bb0485 : 00000000`00000002 00000000`00000000 00000000`00000000 00000000`00000000 : hal!HalpCmcPollProcessor+0x73

fffff880`0c4a5c50 fffff802`144a22b1 : fffff802`14690110 fffffa80`3316b700 fffff802`14bb03f0 fffff802`1446dc00 : hal!HalpCmcWorkerRoutine+0x95

fffff880`0c4a5cc0 fffff802`14437045 : fffff880`0c4a5ec0 00000000`00000080 fffff802`144a2170 fffffa80`3316b700 : nt!ExpWorkerThread+0x142

fffff880`0c4a5d50 fffff802`144eb766 : fffff880`02a47180 fffffa80`3316b700 fffff880`02a53d40 fffffa80`310ba980 : nt!PspSystemThreadStartup+0x59

fffff880`0c4a5da0 00000000`00000000 : fffff880`0c4a6000 fffff880`0c4a0000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16


감사합니다.

ESXi의 패치를 설치하고 제거하는 방법과 Windows (Hyper-V)는 어떻게 다른지 확인해 보았습니다.


-------------------------------------------------------- ESXi -----------------------------------------------------------

1. ESXi 의 Build number 확인 합니다.


2. https://kb.vmware.com/articleview?docid=2143832&lang=en_US 에서 설치할 Build number 확인 합니다.

  현재 설치된 ESXi 는 10302608로 ESXi 6.7 U1 이고 상위 버전인 Build number 10764712를 설치할 것입니다.

  ESXi 에서 같은 버전에서는 Build number가 더 높은 것이 상위 버전 입니다. 6.7 U1 보다 EP 05가 Build number가 더 높으니 상위 버전 입니다.

  6.5 P03의 Build number가 더 높다고 하실 수 있는데 Build number로 구분하는 것은 같은 버전에서만 해당 됩니다. (ESXi는 누적패치 입니다.)


3. https://my.vmware.com/group/vmware/patch#search 를 연 후 VMware에 로그온 합니다.

  Product을 ESXi 그리고 버전을 6.7로 맞춘 후 Build number 10764712 로 검색을 하면 아래와 같이 다운로드 가능한 경로가 나옵니다.


4. ESXi host client로 접속을 한 후 스토리지 -> 적절한 데이터스토어 선택 -> 데이터스토어 브라우저 -> Patch 디렉토리 생성 -> 업로드 클릭하여 Patch 업로드


5. 아래 명령을 실행해서 ESXi 를 Maintenance mode로 변경 합니다.

# vim-cmd hostsvc/maintenance_mode_enter 


6. 패치 파일이 있는 데이터스토어로 이동해서 패치 파일이 잘 업로드 되었는지 확인 합니다.


7. 다음 명령을 실행해서 패치를 설치 하고 재부팅을 합니다. (Host Client로 접속을 해 보면 Build number가 바뀐 것을 알 수 있습니다.)

  esxcli software vib update -d "/vmfs/volumes/5c1daaa4-d1f39d97-acc4-000c29d43d4f/patch/ESXi670-201811001.zip" 


8. 아래 명령을 실행해서 Maintenance mode에서 빠져 나옵니다.

  vim-cmd /hostsvc/maintenance_mode_exit


9. Patch 에 문제가 있어서 이전으로 돌아가려면 ESXi를 재부팅 하면서 부팅 화면에서 Shift+R을 누른 후 Y 를 눌러서 Patch 설치 이전 커널로 돌아갈 수 있습니다. 이전 버전이 아니고 더 예전으로 돌아하는 방법은 해당 버전의 해치를 설치해 주면 된다고 들었는데 관련 자료를 아직 찾지 못했습니다.


<추가>

패치에 어떤 내용이 수정되었는지 확인 하려면 설치 하려는 패치의 정보를 아래 웹 사이트에서 선택을 합니다.

https://esxi-patches.v-front.de/

이 사이트에서는 아래와 같이 VMware의 공식 사이트로 링크되어 있어 어떤 수정이 있었는지 확인할 수 있습니다.

https://docs.vmware.com/en/VMware-vSphere/6.7/rn/esxi670-201811001.html



<참고>

How to download patches in MyVMware (1021623)

https://kb.vmware.com/s/article/1021623

Build numbers and versions of VMware ESXi/ESX (2143832)

https://kb.vmware.com/articleview?docid=2143832&lang=en_US

“esxcli software vib” commands to patch an ESXi 5.x/6.x host (2008939)

https://kb.vmware.com/s/article/2008939

esxcli software profile or esxcli software vib?

http://byounghee.me/2017/04/28/esxcli-software-profile-or-esxcli-software-vib/

Reverting to a previous version of ESXi (1033604)

https://kb.vmware.com/s/article/1033604



-------------------------------------------------------- Windows -----------------------------------------------------------



1. 현재 설치된 버전을 확인 합니다.

  CMD를 사용할 경우는 Systeminfo 를 사용하고 GUI라면 Winver를 사용하면 됩니다.


2. 아래 웹 페이지에서 17134 Build와 관련된 version이 무엇인지 확인 합니다. 17134 Build 는 Windows 10 1803 빌드라는 것을 확인할 수 있습니다.

  (Windows 10 1607은 Windows Server 2016 이고 Windows 10 1809는 Windows Server 2019 입니다.)

  https://docs.microsoft.com/en-us/windows/windows-10/release-information


3. 아래 웹 페이지에서 설치해야 할 패치를 선택 합니다. December 19, 2018이 가장 최신 패치 입니다. (최신 Windows는 누적 패치 입니다.)

  Windows 10 version 1803을 선택 한 후 

  https://support.microsoft.com/en-us/help/4099479/windows-10-update-history


설치할 패치를 선택하면 어떤 수정이 있었는지 확인 가능 합니다.



4. 인터넷에 Windows가 연결되어 있다면 Windows update를 통해서 설치 할 수 있겠지만 오프라인으로 설치 하려면 Windows update 카탈로그를 통해 다운 받아야 합니다.

  http://www.catalog.update.microsoft.com/home.aspx


5. 설치 방법은 다운로드한 .msu 파일을 아래와 같은 명령으로 설치 하면 됩니다.

  wusa windows10.0-kb4471324-x64_delta_ffcf11ca79d79a6fc03aca53c7a00e6106d66f07.msu /quiet /nostart


6. 설치된 결과는 wmic qfe 명령으로 확인 가능 합니다.


<참고>

설치된 KB는 아래 명령으로 삭제할 수 있습니다.

wusa.exe /quiet /uninstall /kb:1212121 /promptrestart



Windows의 Windows Update 독립 실행형 설치 프로그램에 대한 설명

https://support.microsoft.com/ko-kr/help/934307/description-of-the-windows-update-standalone-installer-in-windows

Windows 소프트웨어 업데이트 패키지의 명령줄 스위치

https://support.microsoft.com/ko-kr/help/262841/command-line-switches-for-windows-software-update-packages


오늘은 디스크 공간을 다 써버리는 문제에 대해서 살펴 보도록 하겠습니다.


윈도우, 리눅스 등의 운영체제에서 디스크 공간을 다 써버려서 특정 애플리케이션이 오동작 하거나 시스템 파티션의 공간이 부족해져서 시스템이 멈추는 현상을 본 적이 있을 것 입니다. 윈도우, 리눅스 모두 디스크 공간을 확인하는 방법이 있는데 아무래도 리눅스 쪽이 좀 더 강력합니다.


-------------------------------------------------------- Linux -----------------------------------------------------------
리눅스 에서는 마운트 되어 있는 모든 파티션의 크기, 사용 중인 공간, 사용 가능한 공간을 df 명령을 통해서 확인할 수 있습니다.


출력 결과를 보면 바로 디스크 공간이 얼마나 남아 있는지 확인할 수 있습니다. 그런데 /dev/sda2를 보면 전체 크기 20G에서 사용량 4G를 빼면 16G가 나와야 할 것 같은데 15G가 나오는 것을 확인할 수 있습니다. 리눅스가 긴급 상황을 위해서 Reserved block을 따로 만들어 놓는다고 합니다. (tune2fs 명령을 사용해서 Reserved block의 크기를 확인할 수 있습니다.)

Red hat 문서를 보면 Reserved block을 5% 할당하게 되어 있는데 파일 시스템이 큰 경우 이 크기를 줄일 수 있다고 합니다.

https://access.redhat.com/solutions/1189733


디스크 공간이 많이 사용된 것을 확인했으먼 어떤 디렉토리가 많이 사용하고 있는지 확인해야 합니다. 이 때 사용할 수 있는 명령이 du 입니다.


일반적으로 많이 발생하지는 않지만 df 명령을 실행했을때 충분한 디스크 공간이 있는데 공간이 부족하다는 오류가 발생하는 경우 입니다. 이 경우에는 inode가 고갈되었는지 확인해봐야 합니다. inode의 사용률은 df -i 명령을 통해서 확인할 수 있습니다. /dev/sda2 파티션은 1,310,720 개의 inode가 있고 그중 109,878 개가 사용되었습니다.

inode가 부족한 현상이 발생하면 해당 파티션의 파일을 지우는 작업을 통해서 inode를 확보할 수 있으며 문제 해결을 위해서는 inode가 충분히 할당되도록 파일 시스템을 새로 만들어야 합니다.

https://access.redhat.com/solutions/641333


리눅스는 부팅 시점에 자동으로 파일 시스템 체크 명령인 fsck를 실행 합니다. 파일시스템이 손상된 경우 해당 파이션을 umount 한 후 fsck 명령으로 조치를 취합니다.


-------------------------------------------------------- Windows --------------------------------------------------------

Windows 에서는 df 명령이 없고 GUI를 사용하거나 WMI를 사용해서 Win32_logicaldisk의 정보를 확인해야 합니다. WMI는 WMIC 라는 명령을 사용해서 확인할 수도 있고 PowerShell을 사용할 수도 있습니다. 안타깝게도 Windows 에서는 사용률을 %로 보여주지는 않습니다.


디스크 공간이 많이 사용되었을 때 du 명령을 사용하여 어떤 디렉토리나 파일이 공간을 차지하는지 확인할 수 있는데 Windows에 기본 명령에는 du가 없고 sysinternals에서 du 를 다운 받아야 합니다.


https://docs.microsoft.com/en-us/sysinternals/downloads/du


sysinternals의 du 는 리눅스의 du 와는 다르게 동작하고 리눅스에 있는 sort, tail 등의 명령이 Windows에는 없기 때문에 PowerShell을 사용해서 비슷하게 만들어 보았습니다. (du 에서 배너를 없애는 -q 를 사용했지만 배너가 출력되고 있습니다. )


Windows 에서 Disk 공간이 부족할 때 확인해봐야 할 것은 2가지가 있습니다. 첫째 백업을 위해 사용되는 새도 복사본 저장소의 사용률 입니다. 새도 복사본은 각 디스크에 "System Volume Information" 이라는 디렉토리 아래에 있는데 이 디렉토리는 System 만 접근할 수 있게 설정되어 있어 du가 크기를 확인할 수 없습니다. (vssadmin 명령으로 사용량을 확인해야 합니다.), 둘째 du를 사용하는 계정이 접근할 수 없는 디렉토리 (Admin도 사용자 전용으로 설정된 디렉토리에 접근할 수 없습니다.) 또는 디렉토리 또는 파일이 배타적인 접근 속성을 가지고 있는 경우 크기를 확인할 수 없습니다.


Windows 에서 사용하는 NTFS에는 inode와 같은 개념이 없고 최대 4,294,967,295 개까지 파일, 디렉토리를 만들 수 있습니다.

http://www.ntfs.com/ntfs_vs_fat.htm


Windows에서도 부트 시점에 autochk 가 실행되어 손상된 파일 시스템을 치료할 수 있습니다. 그리고 chkdsk 명령을 사용해서 볼륨를 검사 및 오류를 수정할 수 있습니다. /F 옵션을 사용해서 오류를 수정하려고 할 경우 볼륨을 분리 한 후 실행할 수 있습니다. 



볼륨의 크기가 클 경우 chkdsk를 실행하여 오류를 수정하는데 많은 시간이 걸리는데 Windows 2008 부터 Self-healing, Spot fix 라는 기능이 들어가서 오류가 발생할 경우 바로 fix를 하고 있습니다. (새로운 파일 시스템인 REFS에는 Chkdsk가 필요 없다고 합니다.)

https://blogs.technet.microsoft.com/doxley/2008/10/29/self-healing-ntfs/

https://blogs.msdn.microsoft.com/b8/2012/05/09/redesigning-chkdsk-and-the-new-ntfs-health-model/


감사합니다.




'Windows & (Linux | vSphere)' 카테고리의 다른 글

Spinlock dump 분석 (기초)  (0) 2019.01.26
ESXi 패치 설치 vs Windows 패치 설치  (0) 2018.12.22
부팅 과정 및 복구 (Grub)  (0) 2018.06.17
성능 모니터링 (sysstat, sar)  (0) 2018.06.16
IO 부하 (iostat, iotop)  (0) 2018.06.06



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

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

리눅스와 윈도우 모두 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


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

'Windows & (Linux | vSphere)' 카테고리의 다른 글

ESXi 패치 설치 vs Windows 패치 설치  (0) 2018.12.22
디스크가 가득 차는 경우  (0) 2018.12.15
성능 모니터링 (sysstat, sar)  (0) 2018.06.16
IO 부하 (iostat, iotop)  (0) 2018.06.06
시스템 부하 (top)  (0) 2018.06.03

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

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에 대한 비교를 마칩니다. 두 도구가 완전히 동일하다고 할 수는 없겠지만 주기적으로 시스템 성능 정보를 수집할 수 있다는 점에서 유용합니다.








'Windows & (Linux | vSphere)' 카테고리의 다른 글

디스크가 가득 차는 경우  (0) 2018.12.15
부팅 과정 및 복구 (Grub)  (0) 2018.06.17
IO 부하 (iostat, iotop)  (0) 2018.06.06
시스템 부하 (top)  (0) 2018.06.03
시스템 부하 확인 (uptime)  (2) 2018.06.02

오늘은 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를 선택하면 됩니다. 아쉬운 것은 보고서 형식을 선택할 경우 프로세스 들이 가로로 나열되어 스크롤바를 이동해서 정보를 확인하는 것이 좀 불편합니다. 








'Windows & (Linux | vSphere)' 카테고리의 다른 글

디스크가 가득 차는 경우  (0) 2018.12.15
부팅 과정 및 복구 (Grub)  (0) 2018.06.17
성능 모니터링 (sysstat, sar)  (0) 2018.06.16
시스템 부하 (top)  (0) 2018.06.03
시스템 부하 확인 (uptime)  (2) 2018.06.02

첫 번째 글을 올리고 나서 이 블로그 내용은 리눅스 전문가 분들이 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 에서도 가능한한 물리 메모리를 많이 사용하려고 캐시를 많이 사용하고 있습니다. 하지만 캐시 메모리는 언제든지 제거할 수 있는 것이기 때문에 사용 가능한 메모리로 계산 됩니다.


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




'Windows & (Linux | vSphere)' 카테고리의 다른 글

디스크가 가득 차는 경우  (0) 2018.12.15
부팅 과정 및 복구 (Grub)  (0) 2018.06.17
성능 모니터링 (sysstat, sar)  (0) 2018.06.16
IO 부하 (iostat, iotop)  (0) 2018.06.06
시스템 부하 확인 (uptime)  (2) 2018.06.02

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 & (Linux | vSphere)' 카테고리의 다른 글

디스크가 가득 차는 경우  (0) 2018.12.15
부팅 과정 및 복구 (Grub)  (0) 2018.06.17
성능 모니터링 (sysstat, sar)  (0) 2018.06.16
IO 부하 (iostat, iotop)  (0) 2018.06.06
시스템 부하 (top)  (0) 2018.06.03

+ Recent posts