오늘은 Guest OS Disk timeout 설정에 대해서 정리해보고자 합니다.

 

Windows VM에서 Disk timeout 값이 작게 설정되어 있는 경우에 SAN datastore 를 사용하면 성능에 문제가 있다는 문서가 있습니다

Inconsistent Windows virtual machine performance when disks are located on SAN datastores (1014)

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

Windows VM이 위치한 SAN datastore 에서 오류가 발생해서 Retry, Link down timeout, Failover 등이 발생하는 경우 조치에 걸리는 시간보다 Disk의 Timeout이 길어야 ESXi 레이어에서 Storage에 대한 복구가 될 때 까지 Disk 가 오류가 발생하지 않게 됩니다. 문서에서는 일반적인 60초로 설정을 하도록 하였으나 정확한 값은 각 스토리지 업체의 값을 따라야 하고 Windows VM에서 실행되고 있는 Application의 특성을 따라야 합니다.

좀더 자세히 살벼보면 Windows WDK의 SCSI Miniport Driver 문서에는 Timeout을 설정하지 않을 경우 10초로 설정된다고 되고 Windows 8 (Windows Server 2012) 부터는 Miniport driver에 설정된 timeout 값이 적용됩니다.

https://docs.microsoft.com/en-us/windows-hardware/drivers/storage/registry-entries-for-scsi-miniport-drivers

하지만 아래 Microsoft 에서 나온 블로그 들을 보면 Timeout을 무조건 60 초로 설정하지는 말라고 되어 있습니다. Windows 에서는 Timeout이 발생하면 Storport 드라이버가 8번까지 재시도를 하게 되어 있어 만약 timeout이 60초로 설정되된 경우 최대 8분까지 (60초 x 8회) 재시도를 하는 것이 됩니다. SQL Server 나 Exchange Server와 같이 IO가 중요한 시스템들은 무조건 60초를 설정하기 보다는 Application 특성, 물리/가상머신 여부, Multipath, 스토리지 특성 등을 다 고려해서 적절한 값을 설정하는 것이 중요합니다.

Disk Timeout
https://blogs.technet.microsoft.com/hugofe/2011/09/07/disk-timeout/

Windows Disk Timeouts and Exchange Server 2010
https://blogs.technet.microsoft.com/exchange/2011/11/17/windows-disk-timeouts-and-exchange-server-2010/

 

Linux Guest OS의 Disk timeout도 설정되어야 합니다. 아래 문서를 보면 Linux Guest OS에서 SAN에서 IO retry, Path failover 등에 시간이 오래 걸려서 file system이 read-only로 설정되거나 Panic이 발생하는 경우가 있어 패치를 적용하고 Disk의 Timeout 값을 180으로 설정해야 합니다. (ESX 4 이후 부터는 VMware tools 를 설치한 경우 Timeout 값이 180으로 설정됩니다.)

Linux based file systems become read-only (51306)
https://kb.vmware.com/s/article/51306

Storage path failover might cause kernel panic in Linux kernels if using a virtual LSILogic adapter (Parallel or SAS) (1010759)
https://kb.vmware.com/s/article/1010759

Increasing the disk timeout values for a Linux 2.6 virtual machine (1009465)
https://kb.vmware.com/s/article/1009465

Filesystem on VMware Red Hat Enterprise Linux 4, 5, 6, & 7 guests went read-only
https://access.redhat.com/solutions/35329

 

Storage 업체의 권고를 확인해 보면 NetApp에서는 vSphere 환경에서 Linux 와 Windows 모두 60초를 설정할 것을 권장하고 있습니다.

What are the guest OS tunings needed for a VMware vSphere deployment?
https://kb.netapp.com/app/answers/answer_view/a_id/1001979/~/what-are-the-guest-os-tunings-needed-for-a-vmware-vsphere-deployment%3F-

 

결론은 Application/Storage 특성, ESXi 에서의 구성등을 모두 고려해서 Disk timeout을 설정해야 합니다.

 

'Virtualization' 카테고리의 다른 글

vSphere Performance Troubleshoooting and RCA  (0) 2019.03.10
VMware vCenter Performance  (0) 2019.02.23
ESXi Internal  (0) 2018.10.20

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


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


-------------------------------------------------------- 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