3.3.0-beta1의 릴리스를 발견한 직후, 웹 인터페이스를 통해 Discourse 인스턴스를 업데이트했습니다.
그러나 업데이트 과정 중 웹 인터페이스 로그가 추가 출력 없이 15분 이상 멈춰 있었습니다(마지막 출력이 점진적으로 늘어나는 점(…) 이었는지 기억이 가물가물합니다). 약 2시간 후 클라우드 플랫폼에서 서버 상태를 확인했을 때 서버가 동결된 것으로 의심되어, 클라우드 플랫폼에서 소프트 리부트를 수행했습니다.
리부트 직후 커맨드 라인에서 Discourse 백업을 실행하고, 백업 파일과 app.yml을 로컬로 다운로드한 뒤 Discourse를 완전히 재설치했습니다(물론 최신 버전으로요). 이후 백업을 업로드하고 커맨드 라인에서 복원 과정을 시작했습니다.
복원은 성공적으로 완료되었지만, 현재 제 Discourse는 심각한 성능 문제를 겪고 있습니다. 이전에는 정상 사용 시 CPU 사용률이 10%를 넘지 않았는데, 지금은 오프피크 시간대에도 30%까지 치솟고 디스크 읽기 속도도 상당히 높습니다. 더糟糕한 것은 서버가 이유 없이 크래시하는 경우가 있다는 점입니다. 이때 디스크 읽기 속도는 초당 약 1,900회(제 클라우드 서버의 한계치)까지 올라가고, CPU는 40% 이상을 웨이트 상태(Wait State)로 유지합니다. 웹페이지가 로드되지 않고 연결 타임아웃이 발생합니다. 현재 vmstat와 top을 실행 중이지만 불행히도 출력을 저장해 두지 않았습니다. 스왑 I/O가 거의 0에 가까웠던 것으로 기억하며, 이는 순수한 디스크 읽기임을 의미합니다. 차단된 스레드 수가 100개를 초과했습니다.
이 실패한 업데이트가 소프트웨어 자체보다는 백업 내 데이터에 손상을 입혔을 가능성이 있다고 의심됩니다. 캐시를 새로고침하거나 삭제하는 등의 작업을 수행할 수 있는 방법이 있을까요? 아니면… 업데이트를 다시 실행해 볼까요?(결국 Discourse 업데이트는 매우 잦고, 거의 언제든지 업데이트할 수 있으니까요.)
임시 해결책으로, 높은 부하 시 자동으로 리부트하도록 소프트웨어 워치독을 설치했습니다. 하지만 이는 궁극적인 장기 해결책이 아니며, 여기서 비슷한 문제를 찾지 못했으므로 명백히 Discourse 소프트웨어 자체의 문제는 아닌 것 같습니다. 이 문제를 어떻게 해결해야 할지 고민입니다.
높은 부하 상태의 서버 상태를 확인하기 위해 서버에서 특정 명령어를 실행해 달라고 요청하시면 주저하지 마세요. 리부트 없이 SSH 연결을 유지하고 해당 데이터를 확보하는 데 최선을 다하겠습니다.
sidekiq 큐가 어떻게 구성되어 있나요? 모든 게시물을 다시 처리(rebake)하는 중일 수 있고, 백로그가 처리되면 부하가 점차 줄어든다는 뜻일 수도 있습니다. 즉, 일시적인 상황일 가능성이 높습니다.
최근 몇 번이나 이런 일이 발생했습니다. 매번 수동 재부팅 후 커맨드 라인으로 재빌드(rebuild)를 수행했습니다. 물론 장기적으로는 좋은 해결책이 아니며 위험한 방법입니다.
이것은 기기에 더 이상 충분한 메모리가 없다는 신호입니다. 부하 스파이크에 대응할 수 있도록 스왑(swap) 용량을 늘리는 것을 고려해 보세요.
온라인 업데이트를 실행하려면 이제 4GB 메모리와 3GB 스왑이 필요하다는 것을 발견했습니다. 여러분은 얼마의 메모리를 가지고 계신가요?
음… 실제로는 복원 직후 극도로 높은 부하를 겪지는 않았던 것 같습니다. 아마도 이는 정상적인 현상일 것입니다. 하지만 제 경우, 복원 후 부하가 약 2% 수준까지 내려간 상태에서 웹 인터페이스에서 몇 가지 수정 작업을 하던 중, 한 번의 작업 후에 갑자기 페이지가 로드되지 않았습니다. 클라우드 서버 플랫폼을 확인해 보니 CPU와 디스크 읽기 부하가 매우 높게 나타나고 있었습니다. 이 문제는 모든 게시물을 다시 처리(rebake)하는 것 때문이라고 생각하지 않습니다.
현재 제 서버는 정상적인 상태이므로, Sidekiq 인터페이스를 공유합니다:
Robert:
메모리가 얼마나 있나요?
물리적 메모리가 2GB이고 스왑이 2GB입니다. Discourse 설치 과정에서 스왑이 자동으로 활성화된 것 같은데, 어쨌든 저는 수동으로 설정하지 않았습니다.
지금 스왑을 수동으로 총 6GB로 추가했습니다.
네, 그게 바로 문제의 원인이네요.
최근 경험을 보면 웹 컴파일 과정이 훨씬 더 많은 리소스를 요구하는 것 같고, 더 큰 스왑 공간을 설정하거나 더 큰 서버로 이전해 볼 수 있습니다.
참고로, 이전에 웹 인터페이스를 통해 백업을 시도했을 때 로그가 가끔 멈추는 현상이 있었습니다. 지금은 모든 백업과 복구를 명령줄에서 실행하고 있습니다(자동 백업은 제외하며, 자동 백업은 한 번도 실패한 적 없이 정상 작동하고 있습니다). 이것이 일반적인 문제인지 궁금합니다. 업데이트를 수행하는 명령이 있나요? 앞으로 업데이트도 계속 명령줄을 통해 진행하는 것이 좋을까요? 이렇게 하면 성공률이 높아질 가능성이 있을까요?
일상적인 사용에서도 이전보다 웹페이지 로딩 지연이 상당히 증가한 것을 확인할 수 있습니다. 이는 네트워크 문제보다는 성능 문제일 가능성이 높습니다. 홈페이지를 로딩할 때의 성능 데이터는 다음과 같습니다:
서버가 다시 멈췄습니다. (재부팅 없이 전체 로그를 확보하기 위해 워치독을 수동으로 중지했습니다) 아래는 top과 vmstat 출력 결과입니다:
top 출력은 서버가 멈춘 이후로 크게 업데이트되지 않았음을 유의하십시오. vmstat와 달리 최신 데이터를 반영하지 못할 수 있습니다.
top - 21:53:16 up 2:19, 3 users, load average: 19.20, 4.89, 1.90
Tasks: 164 total, 1 running, 163 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.7 us, 7.2 sy, 0.0 ni, 0.0 id, 91.8 wa, 0.0 hi, 0.4 si, 0.0 st
MiB Mem : 1668.6 total, 75.9 free, 1473.1 used, 119.6 buff/cache
MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 36.8 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
92 root 20 0 0 0 0 S 2.8 0.0 0:08.01 kswapd0
2504 root 10 -10 123496 6932 0 D 1.6 0.4 2:59.44 AliYunDunMonito
90 root 0 -20 0 0 0 I 1.0 0.0 0:01.10 kworker/1:1H-kblockd
1320 root 20 0 1236124 2116 0 S 0.8 0.1 0:00.96 containerd-shim
2493 root 10 -10 87652 1744 0 S 0.6 0.1 0:44.69 AliYunDun
1008 root 20 0 1276372 2160 0 S 0.5 0.1 0:43.62 argusagent
725 root 20 0 689584 3860 0 S 0.3 0.2 0:08.16 aliyun-service
1964 message+ 20 0 74800 12512 0 D 0.3 0.7 0:19.97 redis-server
1973 www-data 20 0 56840 4872 472 D 0.3 0.3 0:01.36 nginx
2081 admin 20 0 519788 263284 4 S 0.3 15.4 0:07.88 ruby
2214 admin 25 5 5338856 495356 0 S 0.3 29.0 0:31.95 ruby
2227 admin 20 0 5246956 484488 4 S 0.3 28.4 0:33.31 ruby
2467 systemd+ 20 0 215196 15052 11348 D 0.3 0.9 0:00.45 postmaster
785 root 20 0 42256 748 0 S 0.2 0.0 0:07.58 AliYunDunUpdate
805 root 20 0 1798676 11832 0 S 0.2 0.7 0:02.24 containerd
1027 root 20 0 2281464 29296 0 S 0.2 1.7 0:01.96 dockerd
2056 systemd+ 20 0 67872 2192 0 D 0.2 0.1 0:00.39 postmaster
2243 root 20 0 17204 5068 2592 S 0.2 0.3 0:00.34 sshd
2555 root 20 0 10496 2736 1916 R 0.2 0.2 0:11.41 top
9998 admin 20 0 5057740 313028 4 S 0.2 18.3 0:04.83 ruby
11658 admin 20 0 10944 252 0 D 0.2 0.0 0:00.09 sleep
1 root 20 0 166776 6568 2808 D 0.1 0.4 0:01.42 systemd
22 root 20 0 0 0 0 S 0.1 0.0 0:00.31 ksoftirqd/1
149 root 0 -20 0 0 0 I 0.1 0.0 0:00.17 kworker/0:1H-kblockd
707 systemd+ 20 0 16260 2296 1212 D 0.1 0.1 0:00.16 systemd-network
723 root 20 0 19424 984 0 S 0.1 0.1 0:01.58 assist_daemon
1965 root 20 0 6680 280 0 D 0.1 0.0 0:00.05 cron
1974 www-data 20 0 55912 3996 472 D 0.1 0.2 0:00.98 nginx
2054 systemd+ 20 0 213244 6344 4384 S 0.1 0.4 0:02.02 postmaster
2055 systemd+ 20 0 213780 3208 924 D 0.1 0.2 0:00.12 postmaster
2270 root 20 0 17204 3880 1404 D 0.1 0.2 0:00.67 sshd
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 71456 624 134980 0 0 11302 4 2209 3766 1 1 96 2 0
0 1 0 72756 1452 132412 0 0 15250 12 2418 3969 1 2 94 4 0
0 0 0 67724 1244 137444 0 0 4485 2 2083 3700 1 1 98 1 0
0 0 0 80388 928 124660 0 0 26388 10 2650 4018 1 2 92 4 0
0 0 0 78256 696 126228 0 0 14752 6 2286 3792 1 1 95 3 0
0 0 0 72252 1680 130784 0 0 40334 41 2938 4212 1 2 89 7 0
0 0 0 74812 712 128588 0 0 15904 34 2309 3839 1 1 95 3 0
2 0 0 71120 856 132224 0 0 54282 5 3292 4382 1 3 85 10 0
0 0 0 73668 600 128232 0 0 30135 35 2795 4212 1 2 92 5 0
0 0 0 65160 1524 135636 0 0 30239 6 2842 4247 1 2 90 7 0
0 0 0 74480 1416 126484 0 0 11761 8 2254 3793 1 2 95 2 0
1 0 0 80096 1188 120752 0 0 37110 2 2907 4163 1 4 88 7 0
0 0 0 77880 688 122928 0 0 8439 5 2151 3719 1 1 97 2 0
0 8 0 76744 1256 122536 0 0 110986 14 4410 4860 1 6 34 59 0
0 13 0 71776 244 128496 0 0 126111 21 4386 4699 1 7 0 91 0
1 30 0 71860 356 127916 0 0 125040 21 4634 7331 1 7 0 91 0
3 31 0 77448 204 122688 0 0 125980 10 4167 8370 1 5 0 94 0
3 44 0 68184 168 132192 0 0 150011 0 4296 9015 0 7 0 93 0
1 44 0 74812 216 124700 0 0 204040 0 4949 10108 1 6 0 93 0
6 35 0 66588 244 133160 0 0 131782 2 6238 12786 1 7 0 93 0
1 39 0 68156 556 130996 0 0 144440 11 4608 9622 1 8 0 92 0
0 71 0 72256 212 126520 0 0 169879 12 4780 10242 1 10 0 89 0
0 91 0 66752 112 132476 0 0 542955 18 7422 17564 0 52 0 48 0
6 89 0 70324 172 129516 0 0 404754 21 6033 14379 0 52 0 48 0
3 87 0 60468 156 138060 0 0 499604 1 10640 26065 0 56 0 44 0
5 91 0 63456 152 135588 0 0 725747 11 10827 25806 0 55 0 45 0
4 101 0 69596 168 129132 0 0 558872 8 7755 18745 0 56 0 44 0
6 93 0 66516 156 132772 0 0 394003 3 12549 30622 0 54 0 46 0
4 94 0 62872 152 135976 0 0 656057 0 7790 18800 0 52 0 48 0
2 95 0 57072 156 141552 0 0 347776 0 10390 25943 0 56 0 44 0
4 97 0 66308 164 132964 0 0 641920 0 9963 24307 0 55 0 45 0
13 90 0 75620 152 123836 0 0 658883 0 7870 19260 0 55 0 45 0
2 96 0 66244 152 131496 0 0 764233 0 16078 40498 0 55 0 45 0
1 102 0 60156 224 137440 0 0 542241 0 10243 24560 0 54 0 46 0
13 90 0 62488 164 135548 0 0 671301 0 13771 34230 0 55 0 45 0
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 101 0 61812 100 136048 0 0 548615 0 10328 26305 0 55 0 45 0
2 102 0 61412 92 135928 0 0 1003845 0 17283 42751 0 56 0 44 0
8 98 0 60408 152 136896 0 0 662925 0 11369 29130 0 55 0 45 0
2 104 0 68292 152 129552 0 0 628286 0 13772 34122 0 56 0 44 0
2 99 0 65352 152 132436 0 0 494863 5 8766 21559 0 54 0 46 0
10 94 0 58344 96 138800 0 0 669390 0 9294 22968 0 56 0 44 0
3 95 0 61180 100 135444 0 0 598622 0 13342 32430 0 57 0 43 0
8 96 0 59444 160 137584 0 0 720255 0 10812 25735 0 57 0 43 0
14 89 0 66844 160 130072 0 0 665390 0 17496 43187 0 56 0 44 0
1 98 0 64668 152 132756 0 0 498328 0 7262 18622 0 55 0 45 0
1 98 0 61848 172 135060 0 0 438272 0 7693 19947 0 56 0 44 0
3 102 0 60636 152 136548 0 0 1020531 0 17162 43981 0 55 0 45 0
2 93 0 55096 164 141908 0 0 595678 0 14379 37088 0 55 0 45 0
9 100 0 61704 152 134692 0 0 368380 0 10621 27539 0 55 0 45 0
2 104 0 63784 148 132620 0 0 767905 8 11090 28866 0 56 0 44 0
2 110 0 60124 232 135636 0 0 882479 0 14778 38194 0 55 0 45 0
3 109 0 64632 156 131448 0 0 489138 0 11521 30264 0 56 0 44 0
2 107 0 65852 36 130592 0 0 1214409 0 17572 45932 0 55 0 45 0
2 97 0 60260 96 135668 0 0 559811 0 14592 37198 0 56 0 44 0
1 103 0 56064 104 139668 0 0 514522 0 11059 26834 0 57 0 43 0
7 97 0 62624 160 133492 0 0 646888 4 7819 19552 0 57 0 43 0
8 102 0 65404 152 130172 0 0 526268 0 11623 29396 0 56 0 44 0
재부팅 없이 서버가 멈춘 상태를 유지하겠습니다. 높은 부하 상태에서 서버 상태를 확인하기 위해 명령어를 실행해야 한다면 요청해 주세요. SSH 연결을 유지하고 재부팅 없이 모든 데이터를 수집하는 데 최선을 다하겠습니다.
클라우드 서버 플랫폼에서 가져온 기타 데이터:
Ed_S
3월 29, 2024, 4:10오후
9
tumbleweed:
AliYunDunMonito
이것은 의심스럽습니다. 원인이 될 수도 있고 아닐 수도 있습니다. 무언가(아마도) 대량의 디스크 읽기 작업을 수행하고 있습니다. AliYunDun은 클라우드 제공업체의 도구인 것 같습니다. AliYunDunMonitor는 (아마도) 디스크 대기 상태에 막혀 있으며, 높은 우선순위로 실행되고 있고, 상당한 CPU 시간을 기록하고 있습니다.
어딘가에서 이러한 프로세스를 종료하는 스크립트를 작성 한 사람이 있습니다. 그 톤은 화가 난 상태입니다. (해당 스크립트가 안전한지, 좋은 아이디어인지는 단정할 수 없습니다.)
하지만 모든 디스크 읽기 작업을 Discourse 프로세스가 수행하고 있을 수도 있습니다.
아마도 다음을 시도해 보세요.
apt-get install iotop
iotop -b -d 15 -P -o
그리고 시스템이 동결될 때까지 관찰해 보세요.
좋아요, 그리고 이것이 프리징 상태에서의 iotop 출력입니다:
Total DISK READ: 7.92 M/s | Total DISK WRITE: 11.70 K/s
Current DISK READ: 12.14 M/s | Current DISK WRITE: 17.29 K/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
1 be/4 root 6.12 K/s 0.00 B/s ?unavailable? init noibrs
300 be/3 root 0.00 B/s 2.93 K/s ?unavailable? [jbd2/vda3-8]
374 be/3 root 10.64 K/s 0.00 B/s ?unavailable? systemd-journald
709 be/4 systemd- 3.99 K/s 0.00 B/s ?unavailable? systemd-resolved
723 be/4 root 51.07 K/s 0.00 B/s ?unavailable? assist_daemon
725 be/4 root 856.83 K/s 272.40 B/s ?unavailable? aliyun-service
770 be/4 root 63.31 K/s 0.00 B/s ?unavailable? python3 -Es /usr/sbin/tuned -l -P
785 be/4 root 12.77 K/s 0.00 B/s ?unavailable? AliYunDunUpdate
805 be/4 root 389.98 K/s 0.00 B/s ?unavailable? containerd
1008 be/4 root 242.60 K/s 544.80 B/s ?unavailable? argusagent
1027 be/4 root 690.31 K/s 0.00 B/s ?unavailable? dockerd -H fd:// --containerd=/run/containerd/containerd.sock
1320 be/4 root 241.01 K/s 0.00 B/s ?unavailable? containerd-shim-runc-v2 -namespace moby -id 6e9880833995c5e2a295ed6571129387036824d304e09f43d5e1333ebd7fdbd5 -address /run/containerd/containerd.sock
1953 be/4 root 1906.79 B/s 0.00 B/s ?unavailable? runsvdir -P /etc/service
1962 be/4 admin 85.12 K/s 0.00 B/s ?unavailable? bash config/unicorn_launcher -E production -c config/unicorn.conf.rb
1964 be/4 messageb 611.83 K/s 0.00 B/s ?unavailable? redis-server *:6379
1973 be/4 www-data 530.17 K/s 272.40 B/s ?unavailable? nginx: worker process
2054 be/4 systemd- 8.78 K/s 7.45 K/s ?unavailable? postgres: 13/main: walwriter
2056 be/4 systemd- 102.42 K/s 0.00 B/s ?unavailable? postgres: 13/main: stats collector
2081 be/4 admin 817.20 B/s 0.00 B/s ?unavailable? unicorn master -E production -c config/unicorn.conf.rb
2493 ?dif root 132.21 K/s 0.00 B/s ?unavailable? AliYunDun
2504 be/2 root 740.32 K/s 0.00 B/s ?unavailable? AliYunDunMonitor
45686 be/4 root 47.62 K/s 0.00 B/s ?unavailable? sshd: root@pts/0
45816 be/4 root 36.98 K/s 0.00 B/s ?unavailable? top
46146 be/4 root 357.52 K/s 0.00 B/s ?unavailable? python3 /usr/sbin/iotop -b -d 15 -P -o
46160 be/4 root 267.34 K/s 0.00 B/s ?unavailable? sshd: root@pts/2
46232 be/4 root 174.24 K/s 0.00 B/s ?unavailable? vmstat 5
51903 be/4 admin 1569.22 K/s 272.40 B/s ?unavailable? unicorn worker[0] -E production -c config/unicorn.conf.rb
51972 be/4 admin 175.84 K/s 0.00 B/s ?unavailable? unicorn worker[1] -E production -c config/unicorn.conf.rb
60365 be/4 root 272.40 B/s 0.00 B/s ?unavailable? [kworker/u4:0-writeback]
63081 be/4 root 272.40 B/s 0.00 B/s ?unavailable? [kworker/u4:4-events_unbound]
63825 be/4 systemd- 673.02 K/s 0.00 B/s ?unavailable? postgres: 13/main: discourse discourse [local] idle
64191 be/4 root 23.14 K/s 0.00 B/s ?unavailable? -bash
실제로 F5 키를 여러 번 빠르게 눌러 홈페이지를 새로고침하는 방식으로 웹사이트를 크래시 시키는 데 성공했습니다… 따라서 이것이 Discourse의 문제일 가능성이 매우 높다고 생각합니다.
현재 top 출력:
top - 13:36:47 up 18:03, 4 users, load average: 86.10, 47.87, 19.63
Tasks: 174 total, 4 running, 170 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.2 us, 21.1 sy, 0.0 ni, 0.0 id, 76.3 wa, 0.0 hi, 0.4 si, 0.0 st
MiB Mem : 1668.6 total, 69.6 free, 1413.6 used, 185.4 buff/cache
MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 36.9 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
92 root 20 0 0 0 0 S 37.8 0.0 100:17.66 kswapd0
1320 root 20 0 1236124 2320 0 S 4.0 0.1 4:18.47 containerd-shim
1027 root 20 0 2281464 29160 0 S 2.6 1.7 2:25.38 dockerd
805 root 20 0 1798676 11844 0 S 2.5 0.7 2:28.22 containerd
2504 root 10 -10 129972 11660 0 D 2.1 0.7 27:34.39 AliYunDunMonito
90 root 0 -20 0 0 0 R 1.5 0.0 1:58.75 kworker/1:1H-kblockd
2493 root 10 -10 88144 2244 0 D 1.1 0.1 10:49.21 AliYunDun
51989 root 20 0 1318960 8980 0 S 0.8 0.5 0:46.15 snapd
1008 root 20 0 1276372 2584 0 S 0.7 0.2 11:16.56 argusagent
46146 root 20 0 22320 9516 1908 D 0.5 0.6 0:23.57 iotop
46160 root 20 0 17200 4968 2496 D 0.3 0.3 0:03.41 sshd
45686 root 20 0 17200 5188 2716 D 0.3 0.3 0:04.21 sshd
785 root 20 0 42324 876 0 S 0.2 0.1 3:41.24 AliYunDunUpdate
45816 root 20 0 10500 3352 2544 R 0.2 0.2 0:26.01 top
51903 admin 20 0 845708 458296 4 S 0.2 26.8 0:32.36 ruby
53938 admin 25 5 5285240 378040 0 S 0.2 22.1 0:33.50 ruby
723 root 20 0 19424 996 0 S 0.2 0.1 1:57.31 assist_daemon
725 root 20 0 689584 3800 0 S 0.2 0.2 3:06.25 aliyun-service
1964 message+ 20 0 74800 13944 0 D 0.2 0.8 2:51.80 redis-server
1974 www-data 20 0 57696 6136 772 R 0.2 0.4 0:36.37 nginx
1975 www-data 20 0 53508 1520 72 S 0.2 0.1 0:45.76 nginx
2053 systemd+ 20 0 213244 6952 4988 D 0.2 0.4 0:27.47 postmaster
51972 admin 20 0 5139692 329104 4 S 0.2 19.3 0:08.21 ruby
64309 systemd+ 20 0 213244 1956 0 D 0.2 0.1 0:00.15 postmaster
22 root 20 0 0 0 0 S 0.1 0.0 0:09.66 ksoftirqd/1
149 root 0 -20 0 0 0 I 0.1 0.0 0:06.26 kworker/0:1H-kblockd
1973 www-data 20 0 56576 5088 768 D 0.1 0.3 0:35.23 nginx
2052 systemd+ 20 0 213468 34408 32340 D 0.1 2.0 0:30.59 postmaster
2055 systemd+ 20 0 213780 3244 932 D 0.1 0.2 0:29.32 postmaster
2056 systemd+ 20 0 68132 2256 0 D 0.1 0.1 0:15.54 postmaster
2081 admin 20 0 585324 280488 4 S 0.1 16.4 0:57.44 ruby
아래는 vmstat 출력입니다:
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 80348 884 230624 0 0 538 6 1980 3661 1 1 99 0 0
0 0 0 78232 2780 226576 0 0 17644 20 2510 4063 3 1 93 2 0
3 0 0 93580 176 186012 0 0 34986 19 3329 4751 13 4 78 6 0
0 29 0 82988 192 177628 0 0 127805 10 4930 6456 5 7 34 54 0
0 30 0 85520 204 175124 0 0 120935 6 3768 6887 1 5 0 94 0
3 37 0 89408 232 170836 0 0 122472 35 3876 7157 1 7 0 92 0
10 80 0 74004 220 186372 0 0 476674 36 4532 10212 0 35 0 64 0
11 89 0 71564 160 190284 0 0 388222 0 11098 27886 0 53 0 47 0
0 100 0 73508 160 188484 0 0 209539 4 4726 11652 0 32 0 68 0
저는 리눅스에 대한 전문가가 아니지만, kswapd0 프로세스가 메모리와 스왑 교환을 관리하는 책임이 있는 것 아닌가요? vmstat에서 swpd, si, so가 모두 0인데 왜 sy CPU 사용량이 이렇게 높은 것일까요? 완전히 혼란스럽습니다.
Ed_S
3월 30, 2024, 8:36오전
11
스왑이 2GB 있는데도 스왑 사용량도, 스왑 활동도 전혀 없다는 것은 매우 의심스럽습니다. 커널 설정을 의심해 보겠습니다. 제 설정은 다음과 같습니다. 모든 설정을 보여주세요. 일부만 골라서 보여주시지 마세요!
head /proc/sys/vm/*
==> /proc/sys/vm/admin_reserve_kbytes <==
8192
==> /proc/sys/vm/block_dump <==
0
head: cannot open '/proc/sys/vm/compact_memory' for reading: Permission denied
==> /proc/sys/vm/compact_unevictable_allowed <==
1
==> /proc/sys/vm/dirty_background_bytes <==
0
==> /proc/sys/vm/dirty_background_ratio <==
10
==> /proc/sys/vm/dirty_bytes <==
0
==> /proc/sys/vm/dirty_expire_centisecs <==
3000
==> /proc/sys/vm/dirty_ratio <==
20
==> /proc/sys/vm/dirty_writeback_centisecs <==
500
==> /proc/sys/vm/dirtytime_expire_seconds <==
43200
==> /proc/sys/vm/drop_caches <==
0
==> /proc/sys/vm/extfrag_threshold <==
500
==> /proc/sys/vm/hugepages_treat_as_movable <==
0
==> /proc/sys/vm/hugetlb_shm_group <==
0
==> /proc/sys/vm/laptop_mode <==
0
==> /proc/sys/vm/legacy_va_layout <==
0
==> /proc/sys/vm/lowmem_reserve_ratio <==
256 256 32 1
==> /proc/sys/vm/max_map_count <==
65530
==> /proc/sys/vm/memory_failure_early_kill <==
0
==> /proc/sys/vm/memory_failure_recovery <==
1
==> /proc/sys/vm/min_free_kbytes <==
45056
==> /proc/sys/vm/min_slab_ratio <==
5
==> /proc/sys/vm/min_unmapped_ratio <==
1
==> /proc/sys/vm/mmap_min_addr <==
65536
==> /proc/sys/vm/mmap_rnd_bits <==
28
==> /proc/sys/vm/mmap_rnd_compat_bits <==
8
==> /proc/sys/vm/nr_hugepages <==
0
==> /proc/sys/vm/nr_hugepages_mempolicy <==
0
==> /proc/sys/vm/nr_overcommit_hugepages <==
0
==> /proc/sys/vm/numa_stat <==
1
==> /proc/sys/vm/numa_zonelist_order <==
Node
==> /proc/sys/vm/oom_dump_tasks <==
1
==> /proc/sys/vm/oom_kill_allocating_task <==
0
==> /proc/sys/vm/overcommit_kbytes <==
0
==> /proc/sys/vm/overcommit_memory <==
1
==> /proc/sys/vm/overcommit_ratio <==
50
==> /proc/sys/vm/page-cluster <==
3
==> /proc/sys/vm/panic_on_oom <==
0
==> /proc/sys/vm/percpu_pagelist_fraction <==
0
==> /proc/sys/vm/stat_interval <==
1
==> /proc/sys/vm/stat_refresh <==
==> /proc/sys/vm/swappiness <==
60
==> /proc/sys/vm/user_reserve_kbytes <==
29305
==> /proc/sys/vm/vfs_cache_pressure <==
100
==> /proc/sys/vm/watermark_scale_factor <==
10
==> /proc/sys/vm/zone_reclaim_mode <==
0
수정: 이것들도 실행해서 출력을 올려주세요
swapon
free
uname -a
df -T
root@iZj6cgi365ov99veqodfgnZ:~# head /proc/sys/vm/*
==> /proc/sys/vm/admin_reserve_kbytes <==
8192
==> /proc/sys/vm/compaction_proactiveness <==
20
head: cannot open '/proc/sys/vm/compact_memory' for reading: Permission denied
==> /proc/sys/vm/compact_unevictable_allowed <==
1
==> /proc/sys/vm/dirty_background_bytes <==
0
==> /proc/sys/vm/dirty_background_ratio <==
10
==> /proc/sys/vm/dirty_bytes <==
0
==> /proc/sys/vm/dirty_expire_centisecs <==
3000
==> /proc/sys/vm/dirty_ratio <==
30
==> /proc/sys/vm/dirtytime_expire_seconds <==
43200
==> /proc/sys/vm/dirty_writeback_centisecs <==
500
head: cannot open '/proc/sys/vm/drop_caches' for reading: Permission denied
==> /proc/sys/vm/extfrag_threshold <==
500
==> /proc/sys/vm/hugetlb_shm_group <==
0
==> /proc/sys/vm/laptop_mode <==
0
==> /proc/sys/vm/legacy_va_layout <==
0
==> /proc/sys/vm/lowmem_reserve_ratio <==
256 256 32 0 0
==> /proc/sys/vm/max_map_count <==
65530
==> /proc/sys/vm/memory_failure_early_kill <==
0
==> /proc/sys/vm/memory_failure_recovery <==
1
==> /proc/sys/vm/min_free_kbytes <==
45056
==> /proc/sys/vm/min_slab_ratio <==
5
==> /proc/sys/vm/min_unmapped_ratio <==
1
==> /proc/sys/vm/mmap_min_addr <==
65536
==> /proc/sys/vm/mmap_rnd_bits <==
28
==> /proc/sys/vm/mmap_rnd_compat_bits <==
8
==> /proc/sys/vm/nr_hugepages <==
0
==> /proc/sys/vm/nr_hugepages_mempolicy <==
0
==> /proc/sys/vm/nr_overcommit_hugepages <==
0
==> /proc/sys/vm/numa_stat <==
1
==> /proc/sys/vm/numa_zonelist_order <==
Node
==> /proc/sys/vm/oom_dump_tasks <==
1
==> /proc/sys/vm/oom_kill_allocating_task <==
0
==> /proc/sys/vm/overcommit_kbytes <==
0
==> /proc/sys/vm/overcommit_memory <==
0
==> /proc/sys/vm/overcommit_ratio <==
50
==> /proc/sys/vm/page-cluster <==
3
==> /proc/sys/vm/page_lock_unfairness <==
5
==> /proc/sys/vm/panic_on_oom <==
0
==> /proc/sys/vm/percpu_pagelist_high_fraction <==
0
==> /proc/sys/vm/stat_interval <==
1
==> /proc/sys/vm/stat_refresh <==
==> /proc/sys/vm/swappiness <==
0
==> /proc/sys/vm/unprivileged_userfaultfd <==
0
==> /proc/sys/vm/user_reserve_kbytes <==
50778
==> /proc/sys/vm/vfs_cache_pressure <==
100
==> /proc/sys/vm/watermark_boost_factor <==
15000
==> /proc/sys/vm/watermark_scale_factor <==
10
==> /proc/sys/vm/zone_reclaim_mode <==
0
root@iZj6cgi365ov99veqodfgnZ:~# swapon
NAME TYPE SIZE USED PRIO
/swapfile file 2G 0B -2
root@iZj6cgi365ov99veqodfgnZ:~# free
total used free shared buff/cache available
Mem: 1708636 984352 79376 38344 644908 490004
Swap: 2097148 0 2097148
root@iZj6cgi365ov99veqodfgnZ:~# uname -a
Linux iZj6cgi365ov99veqodfgnZ 5.15.0-86-generic #96-Ubuntu SMP Wed Sep 20 08:23:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
root@iZj6cgi365ov99veqodfgnZ:~# df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
tmpfs tmpfs 170864 1164 169700 1% /run
/dev/vda3 ext4 61540412 19791160 39020044 34% /
tmpfs tmpfs 854316 0 854316 0% /dev/shm
tmpfs tmpfs 5120 0 5120 0% /run/lock
/dev/vda2 vfat 201615 6186 195429 4% /boot/efi
tmpfs tmpfs 170860 4 170856 1% /run/user/0
overlay overlay 61540412 19791160 39020044 34% /var/lib/docker/overlay2/7754829d0ad68c8acc8b50ed96ae87d8d882a996b87fe0b6821827e527487b62/merged
Ed_S
3월 30, 2024, 9:50오전
13
감사합니다. 정말 좋습니다. 어째서인지 swappiness가 0으로 설정되어 있는데, 이것이 거의 확실하게 문제의 대부분을 차지할 것입니다.
하지만 올바르게 설정해야 할 세 가지 항목이 있습니다. 하나는 swappiness이고, 나머지 두 개는 MKJ’s Opinionated Discourse Deployment Configuration 에서 언급됩니다.
이 값들을 한 번만 설정할 수 있지만, 부팅 시에도 설정되어 있는지 확인해야 합니다. MJK의 게시글을 참고하고, 덮어쓰기 전에 해당 파일들을 확인하십시오.
부팅 시에 swappiness를 0으로 설정하는 어떤 일이 일어나고 있다고 의심됩니다. 호스팅 제공업체가 SSD 스왑을 지양하려는 것일 수도 있습니다. 하지만 스왑이 반드시 있어야 하며, 그렇지 않다면 최소한 4GB RAM으로 업그레이드해야 합니다.
어디서 설정되는지 찾기 위해 다음을 시도해 보십시오.egrep -r swappiness /etc/
이 포럼의 다른 곳에는 swappiness를 10으로 설정하라는 조언이 있습니다. 저는 기본값인 60으로 두는 것을 선호합니다.
죄송합니다… 저는 리눅스에 아주 능숙하지 않습니다. 구체적으로 어떻게 설정해야 하는지 알려주실 수 있을까요?
이러한 작업을 수행하면 언급하신 설정이 영구적으로 변경될 수 있나요?
실행:
echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
그리고 /etc/sysctl.conf에서 vm.swapiness = 60으로 변경
현재 상태: (모든 설정을 변경한 후 재부팅했습니다. 아래 명령어는 재부팅 후 실행된 것입니다)
root@iZj6cgi365ov99veqodfgnZ:~# head /proc/sys/vm/*
==> /proc/sys/vm/admin_reserve_kbytes <==
8192
==> /proc/sys/vm/compaction_proactiveness <==
20
head: cannot open '/proc/sys/vm/compact_memory' for reading: Permission denied
==> /proc/sys/vm/compact_unevictable_allowed <==
1
==> /proc/sys/vm/dirty_background_bytes <==
0
==> /proc/sys/vm/dirty_background_ratio <==
10
==> /proc/sys/vm/dirty_bytes <==
0
==> /proc/sys/vm/dirty_expire_centisecs <==
3000
==> /proc/sys/vm/dirty_ratio <==
30
==> /proc/sys/vm/dirtytime_expire_seconds <==
43200
==> /proc/sys/vm/dirty_writeback_centisecs <==
500
head: cannot open '/proc/sys/vm/drop_caches' for reading: Permission denied
==> /proc/sys/vm/extfrag_threshold <==
500
==> /proc/sys/vm/hugetlb_shm_group <==
0
==> /proc/sys/vm/laptop_mode <==
0
==> /proc/sys/vm/legacy_va_layout <==
0
==> /proc/sys/vm/lowmem_reserve_ratio <==
256 256 32 0 0
==> /proc/sys/vm/max_map_count <==
65530
==> /proc/sys/vm/memory_failure_early_kill <==
0
==> /proc/sys/vm/memory_failure_recovery <==
1
==> /proc/sys/vm/min_free_kbytes <==
45056
==> /proc/sys/vm/min_slab_ratio <==
5
==> /proc/sys/vm/min_unmapped_ratio <==
1
==> /proc/sys/vm/mmap_min_addr <==
65536
==> /proc/sys/vm/mmap_rnd_bits <==
28
==> /proc/sys/vm/mmap_rnd_compat_bits <==
8
==> /proc/sys/vm/nr_hugepages <==
0
==> /proc/sys/vm/nr_hugepages_mempolicy <==
0
==> /proc/sys/vm/nr_overcommit_hugepages <==
0
==> /proc/sys/vm/numa_stat <==
1
==> /proc/sys/vm/numa_zonelist_order <==
Node
==> /proc/sys/vm/oom_dump_tasks <==
1
==> /proc/sys/vm/oom_kill_allocating_task <==
0
==> /proc/sys/vm/overcommit_kbytes <==
0
==> /proc/sys/vm/overcommit_memory <==
1
==> /proc/sys/vm/overcommit_ratio <==
50
==> /proc/sys/vm/page-cluster <==
3
==> /proc/sys/vm/page_lock_unfairness <==
5
==> /proc/sys/vm/panic_on_oom <==
0
==> /proc/sys/vm/percpu_pagelist_high_fraction <==
0
==> /proc/sys/vm/stat_interval <==
1
==> /proc/sys/vm/stat_refresh <==
==> /proc/sys/vm/swappiness <==
60
==> /proc/sys/vm/unprivileged_userfaultfd <==
0
==> /proc/sys/vm/user_reserve_kbytes <==
50778
==> /proc/sys/vm/vfs_cache_pressure <==
100
==> /proc/sys/vm/watermark_boost_factor <==
15000
==> /proc/sys/vm/watermark_scale_factor <==
10
==> /proc/sys/vm/zone_reclaim_mode <==
0
root@iZj6cgi365ov99veqodfgnZ:~# cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
정상적으로 실행되는 것 같습니다! 도움을 주신 모든 분들께 진심으로 감사드립니다!
Ed_S
3월 30, 2024, 12:38오후
15
좋은 진행입니다! 다음을 권장합니다.
# cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]
