root@tymin:/var/discourse# swapon
NAME TYPE SIZE USED PRIO
/dev/dm-0 partition 1.9G 1G -1
root@tymin:/var/discourse# df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
udev devtmpfs 2008928 0 2008928 0% /dev
tmpfs tmpfs 404176 41336 362840 11% /run
/dev/mapper/VolGroup-root ext4 59629100 50018424 6991008 88% /
tmpfs tmpfs 2020876 0 2020876 0% /dev/shm
tmpfs tmpfs 5120 0 5120 0% /run/lock
tmpfs tmpfs 2020876 0 2020876 0% /sys/fs/cgroup
/dev/sda1 ext2 240972 226212 2319 99% /boot
tmpfs tmpfs 404172 0 404172 0% /run/user/1001
tmpfs tmpfs 404172 0 404172 0% /run/user/1000
/dev/loop0 btrfs 10485760 4250700 4424308 49% /chroot/compile
overlay overlay 59629100 50018424 6991008 88% /var/lib/docker/overlay2/4e9863e34f958e15f57c752fda2057b88f2aa03afaca82e0651f3aa23e56f795/merged
트래픽량이 어느 정도인가요? 포럼이 이 같은 문제를 겪을 정도로 크게 작아 보이진 않습니다.
공식 설치 버전인가요? 어떤 종류의 VPS에서 포럼을 실행 중인가요?
관리자 페이지에 따르면 지난 30일 동안 페이지뷰가 50,000회였습니다.
그렇지 않을까요? 당시 찾을 수 있었던 지침들을 따라 설치했습니다.
설치를 크게 커스터마이징하지는 않았습니다.
정확히는 모르겠습니다. cari.net의 2코어 4GB 가상 서버입니다.
현재 포럼은 6년 이상 된 nginx 1.10.3을 사용 중이므로, 뭔가 이상한 일이 일어나고 있는 것으로 보입니다.
그것을 제외하고도, 제가 지금까지 본 Discourse 설치 환경 중 성능이 가장 나쁜 것 중 하나라고 할 수 있습니다. 저희 호스팅 서비스를 홍보하려는 것은 아니지만, 다른 호스팅 업체로 전환하는 것을 고려해 본 적은 없으신가요? 이 정도 규모와 트래픽을 가진 포럼이라면 아주 작은 서버에서도 충분히 원활하게 작동할 수 있어야 합니다.
공유해 주신 미니프로파일러 정보에서 많은 것을 배울 수 있을 것 같습니다. 현재 눈에 띄는 점은 하나인데, 혹시 초안 상태의 게시글이 엄청나게 많으신 건 아닌가요?
/my/activity/drafts
아마도 초안이 3개 있는 것 같습니다.
Debian 9을 사용하고 있습니다. 
nginx는 정상적으로 작동하는 것 같고, 제 사이트의 나머지 부분(https://fredrik.hubbe.net/)은 느리지 않습니다.
하지만 어떤 기준으로 그렇다는 건가요?
Discourse 자체에서 메모리, I/O 또는 CPU를 많이 사용하나요? (그렇다면 왜 그런가요? 저는 실제로 그 부분에 대해 아무것도 하지 않았는데…)
아니면 시스템이 느린 건가요? 그렇다면 cari.net 측에 그 문제를 제기할 수 있습니다.
오늘 저녁쯤 재부팅을 해보고 효과가 있는지 확인해볼 것 같습니다.
약 2년 정도 됐으니, 때가 된 걸까요?
잠깐만:
$ expr 0 `ps auxwww | tail +2 | awk '{ print " + " $6}'`
787952
모든 프로세스의 총 레지던트 메모리가 800Mb보다 적다면, 나머지 메모리는 대체 어디에 쓰이는 걸까?
/proc/meminfo도 별로 도움이 되지 않는 것 같다:
root@tymin:/# cat /proc/meminfo
MemTotal: 4041756 kB
MemFree: 122852 kB
MemAvailable: 53388 kB
Buffers: 15300 kB
Cached: 87636 kB
SwapCached: 125192 kB
Active: 314348 kB
Inactive: 300988 kB
Active(anon): 270652 kB
Inactive(anon): 276288 kB
Active(file): 43696 kB
Inactive(file): 24700 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 1949692 kB
SwapFree: 921348 kB
Dirty: 144 kB
Writeback: 0 kB
AnonPages: 484704 kB
Mapped: 72596 kB
Shmem: 34520 kB
Slab: 319792 kB
SReclaimable: 26836 kB
SUnreclaim: 292956 kB
KernelStack: 6272 kB
PageTables: 19484 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 3970568 kB
Committed_AS: 4146996 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 4001728 kB
DirectMap2M: 192512 kB
아마도 내가 생각한 것보다 리부트가 더 필요할지도 모르겠다… 2년 동안 커널 메모리 누수가 있었던 걸까?
재부팅 후 현재 2GB의 메모리가 비어 있습니다.
이 정도가 유지될지 지켜보겠습니다.
Discourse를 한동안 사용하다 보면 하드디스크 용량이 상당히 커지는 것을 확인할 수 있습니다.
주요 원인은 Docker 이미지 문제로, 업그레이드를 할수록 더 많은 용량이 차지됩니다.
아래 명령어를 실행하세요.
./launcher cleanup
이 명령어는 Discourse가 차지하는 공간을 정리하는 데 도움이 됩니다.
디스크 공간 사용량을 줄이는 데 도움이 될 것입니다. 불행히도 이 경우:
성능을 크게 저하시키는 상당한 스왑이 발생하고 있습니다.
모든 작업이 디스크를 기다리고 있어, 이는 매우 좋지 않은 상태입니다.
잘 작동하지 않는다는 문제가 아니라, 제 경우엔 뭔가 업데이트가 필요하거나 표준 설치 방식이 아닐 수 있다는 신호로 받아들였습니다.
아직까지는 재부팅이 잘 작동하는 것 같다.
그래도 왜 그런지는 아직 확신이 안 선다.
재시동이 도움이 된 것 같아 다행입니다!
정보를 제공할 수 있을지도 모릅니다. 제 것은 훨씬 더 작은 시스템이지만 공유해 보겠습니다.
하지만 한 가지 생각나는 것이 있습니다. 성능에 영향을 줄 수 있는 커널 설정인데, 투명 거대 페이지(transparent huge pages)가 활성화되어 있는지 확인해 보셨나요? 저는 비활성화되어 있습니다:
# cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]
자세한 조언은 MKJ’s Opinionated Discourse Deployment Configuration을 참고하세요!
아래는 잘 작동하는 훨씬 더 작은 시스템의 meminfo입니다:
# cat /proc/meminfo
MemTotal: 1009140 kB
MemFree: 91888 kB
MemAvailable: 88692 kB
Buffers: 7644 kB
Cached: 137040 kB
SwapCached: 144884 kB
Active: 418972 kB
Inactive: 380324 kB
Active(anon): 345300 kB
Inactive(anon): 345852 kB
Active(file): 73672 kB
Inactive(file): 34472 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 2097144 kB
SwapFree: 1049764 kB
Dirty: 400 kB
Writeback: 0 kB
AnonPages: 620688 kB
Mapped: 67192 kB
Shmem: 36536 kB
Slab: 67768 kB
SReclaimable: 27832 kB
SUnreclaim: 39936 kB
KernelStack: 3804 kB
PageTables: 14968 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 2601712 kB
Committed_AS: 3784772 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 460652 kB
DirectMap2M: 587776 kB
좋아요, 이 문제에 대해 마무리를 하고 싶어요.
재부팅이 도움이 되었고, 여전히 도움이 되고 있어요.
메모리 누수의 원인은 모르겠지만, 상황이 바뀌지 않는 한 아마도 1년에 한 번 정도는 다시 재부팅해야 할 것 같아요. 그 정도는 괜찮아요.