728x90
반응형
iowait 원인파악
Rocky Linux 8.8에 올라가있는 k8s 클러스터에서 iowait가 발생하거나 Load가 치는 경우가 발생했다.
원인 파악하기 위한 해결 내용을 정리한다.
iostat 으로 어느 볼륨에서 io를 사용하는지 지켜본다.
root # iostat -dx -c 1 Linux 4.18.0-477.10.1.el8_8.x86_64 (dyms-kube-dev2) 2023년 08월 04일 _x86_64_ (16 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 1.13 0.00 1.51 6.10 0.25 91.01 Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util xvda 0.00 12.00 0.00 32.00 0.00 0.00 0.00 0.00 0.00 0.17 0.00 0.00 2.67 0.33 0.40 xvdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 scd0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
xvda에서 io를 사용하고 있고 iowait 수치가 올라가 있는 것으로 보인다. xvda는 root 볼륨이다. 현재 k8s가 xvdb 에서 동작하고 있기 때문에 컨테이너의 영향이 아니라고 판단했다.
iotop으로 프로세스별 io 사용율을 본다.
Total DISK READ : 0.00 B/s | Total DISK WRITE : 101.20 K/s Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 97.46 K/s PID PRIO USER DISK READ DISK WRITE> COMMAND 759729 be/4 root 0.00 B 408.00 K etcd 949 be/4 root 0.00 B 16.00 K rsyslogd -n 895 be/4 root 0.00 B 4.00 K containerd 777256 be/4 root 0.00 B 0.00 B containerd-shim-runc-v2 -namespace k8s.io -id f4f8ff775ec9e2e752adaacafaa5e11ab09e1f5dcfe686712954fc6559a38276 -address /run/containerd/containerd.sock 803824 be/4 root 0.00 B 0.00 B [kworker/3:1-mm_percpu_wq]
etcd가 io를 지속적으로 사용하고 있는 것으로 보인다. 그렇다는거는 root 영역에서는 거의 io가 발생하고 있지 않다는 것을 의미하는거 같은데.. 무엇이 문제일까??
프로세스 상태 체크
root # ps -eo state,pid,cmd | grep D S PID CMD D 124 [khugepaged] S 856 /usr/sbin/sshd -D S 964068 grep --color=auto D D 2607233 ps -efL
프로세스의 S(state)를 보면 D인 프로세스를 발견했다.
프로세스상태 중 D는 중지되지 않고 계속 wait 하고 있는 상태를 말한다. (아래는 ps의 man page이다)
PROCESS STATE CODES Here are the different values that the s, stat and state output specifiers (header "STAT" or "S") will display to describe the state of a process: D uninterruptible sleep (usually IO) R running or runnable (on run queue) S interruptible sleep (waiting for an event to complete) T stopped by job control signal t stopped by debugger during the tracing W paging (not valid since the 2.6.xx kernel) X dead (should never be seen) Z defunct ("zombie") process, terminated but not reaped by its parent For BSD formats and when the stat keyword is used, additional characters may be displayed: < high-priority (not nice to other users) N low-priority (nice to other users) L has pages locked into memory (for real-time and custom IO) s is a session leader l is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
커널에서 사용 중인 PID 124인 khugepaged 프로세스가 계속 D 상태에 있는 것을 확인 하였다.
lsof도 한번 체크는 해본다.
root # lsof -p 124 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME khugepage 124 root cwd DIR 202,6 272 128 / khugepage 124 root rtd DIR 202,6 272 128 / khugepage 124 root txt unknown /proc/124/exe
hugepaged 프로세스는 THP(Transparent Huge Page)를 사용하기 위한 프로세스인데, 제대로 활용되지 못하고 있는 것으로 보이며, z커널단에서 프로세스가 Hang 걸린 것처럼 보인다. never로 변경 하도록 한다.
echo "never" > /sys/kernel/mm/transparent_hugepage/enabled echo "never" > /sys/kernel/mm/transparent_hugepage/defrag
THP를 비활성화 설정을 하는데 갑자기 서버 세션이 Hang 걸려버림 (해당 프로세스가 원인인 것으로 확실해짐)
다른 세션에서 확인 해보니 -bash 부분에서 또다시 D 상태로 확인 됨
root # ps -eo state,pid,cmd | grep D S PID CMD D 124 [khugepaged] S 856 /usr/sbin/sshd -D -oCiphers=aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc,aes128-gcm@openssh.com,aes128-ctr,aes128-cbc -oMACs=hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512 -oGSSAPIKexAlgorithms=gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-,gss-gex-sha1-,gss-group14-sha1- -oKexAlgorithms=curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1 -oHostKeyAlgorithms=ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com,ssh-rsa,ssh-rsa-cert-v01@openssh.com -oPubkeyAcceptedKeyTypes=ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com,ssh-rsa,ssh-rsa-cert-v01@openssh.com -oCASignatureAlgorithms=ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-256,rsa-sha2-512,ssh-rsa S 748475 kube-apiserver--allow-privileged=true --anonymous-auth=True --apiserver-count=3 --authorization-mode=Node,RBAC --bind-address=0.0.0.0 --client-ca-file=/etc/kubernetes/ssl/ca.crt --default-not-ready-toleration-seconds=300 --default-unreachable-toleration-seconds=300 --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=False --enable-bootstrap-token-auth=true --endpoint-reconciler-type=lease --etcd-cafile=/etc/ssl/etcd/ssl/ca.pem --etcd-certfile=/etc/ssl/etcd/ssl/node-dyms-kube-dev2.pem --etcd-keyfile=/etc/ssl/etcd/ssl/node-dyms-kube-dev2-key.pem --etcd- --event-ttl=1h0m0s --kubelet-client-certificate=/etc/kubernetes/ssl/apiserver-kubelet-client.crt --kubelet-client-key=/etc/kubernetes/ssl/apiserver-kubelet-client.key --kubelet-preferred-address-types=InternalDNS,InternalIP,Hostname,ExternalDNS,ExternalIP --profiling=False --proxy-client-cert-file=/etc/kubernetes/ssl/front-proxy-client.crt --proxy-client-key-file=/etc/kubernetes/ssl/front-proxy-client.key --request-timeout=1m0s --requestheader-allowed-names=front-proxy-client --requestheader-client-ca-file=/etc/kubernetes/ssl/front-proxy-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6443 --service-account-issuer=https://kubernetes.default.svc.dyms-dev.cluster.local --service-account-key-file=/etc/kubernetes/ssl/sa.pub --service-account-lookup=True --service-account-signing-key-file=/etc/kubernetes/ssl/sa.key --service-cluster-ip-range=10.233.0.0/18 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/etc/kubernetes/ssl/apiserver.crt --tls-private-key-file=/etc/kubernetes/ssl/apiserver.key D 870132 -bash
ioswait는 수치가 2배로 뛰었다.
avg-cpu: %user %nice %system %iowait %steal %idle 2.08 0.00 1.64 12.04 0.25 83.99 Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util xvda 0.00 58.00 0.00 206.50 0.00 0.00 0.00 0.00 0.00 0.24 0.01 0.00 3.56 0.28 1.60 xvdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 scd0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
강제 재부팅 하고 해당 THP를 never 설정을 해주었음
728x90
300x250
'IT > OS' 카테고리의 다른 글
| Linux Crontab 명령어로 등록하기 (0) | 2022.01.17 |
|---|---|
| 물리서버 NVMe SSD 세팅 (0) | 2021.08.19 |
| Windows에서 SSH 하는 법 (0) | 2021.08.19 |
| 네트워크 지연 발생 테스트 (0) | 2021.08.19 |
| Linux screen 설정과 사용 (0) | 2021.08.19 |