재빌드(rebuild) 중에는 정상 운영 중보다 메모리 사용량이 훨씬 더 많이 증가합니다. 비슷하게, rebaking 역시 상당한 메모리 요구 사항을 발생시킵니다. 만약 그렇다면, 정기적인 모니터링은 큰 가치를 추가하지 못할 것입니다. 모니터링은 그러한 피크(peak) 시점에 필요하며, 다행히도 이는 관리자가 특정 작업을 수행할 때 발생합니다.
저는 더 작고 사양이 낮은 머신을 사용할 때, 두 번째 터미널 창을 열어 서버에 ssh로 접속하고 vmstat 5를 실행했습니다. 이 명령어는 메모리 사용량이 증감하는 과정을 기록해 줍니다. swpd 컬럼을 관찰하여 구성된 스왑 공간과 비교해 보세요. 일반적으로 장애는 점진적으로 발생하기보다는 갑자기 발생하므로, 단기적인 추이를 살펴보는 것만으로는 큰 도움이 되지 않습니다.
디스크 공간이 있다면, 스왑을 많이 두는 데는 전혀 해가 없습니다. RAM의 절반 정도, 또는 RAM과 같은 크기까지도 가능합니다. 이 경우 스왑은 피크를 감당하기 위해 존재합니다. 정상 사용 중에 스왑/페이지ング 활동이 나타나지 않는 것이 좋습니다. 마찬가지로, vmstat 5 5를 사용하여 페이지ング 활동의 단기적인 상황을 파악할 수 있습니다(si 및 so 컬럼).
다음은 예시입니다:
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 1392140 61200 11632 76432 41 32 117 93 0 1 2 1 97 0 0
1 1 1467220 63416 324 67284 8786 20499 13178 20567 2539 8924 77 13 0 10 0
0 2 1593340 57916 1096 53832 24262 46868 29986 46889 5377 18534 44 22 0 34 0
4 0 1155632 120680 2772 86280 39111 35424 54768 37824 6987 25174 38 27 0 35 0
3 0 1102988 74096 2852 85276 11261 246 12610 271 1879 6365 86 6 0 8 0
swpd 컬럼이 구성된 2.0G에 비해 1.5G를 초과하는 피크에 도달했음을 볼 수 있습니다. 스왑아웃(so) 활동이 같은 5초 창에서 피크에 도달했고, 스왑인(si)이 다음 창에서 피크에 도달했음을 볼 수 있습니다.
(편집: 이전에 free를 실행했기 때문에 2.0G의 스왑이 구성된 것을 알 수 있습니다:
# free
total used free shared buff/cache available
Mem: 1009140 696504 78544 51784 234092 118436
Swap: 2097144 154628 1942516
또한 당시 RAM 1G만으로 discourse를 실행하고 있었던 것도 볼 수 있습니다.)