[CBRD-26528] change to the criteria for restarting the CAS process

[mhoh3963]

http://jira.cubrid.org/browse/CBRD-26528

• change in CAS process memory measurement : from virtual memory size to resident and swap memory size

[mhoh3963]

/run all

[mhoh3963]

/run sql

[airnet73]

Chatgpt로 확인 결과 프로세스의 실제 사용 메모리 사이즈를 확인 하는 방법으로 RSS + SWAP 보다는 PSS 가 더 정확하다고 합니다. 혹시 PSS를 적용하는 것은 어떤지요?

참고로, 아래의 내용은 IDLE 상태의 CAS 메모리 사이즈 입니다.

• RSS + RWAP
  $ cat /proc/1300105/status
  Name: cub_cas
  .
  VmRSS: 10712 kB
  .
  VmSwap: 0 kB

• PSS
  $ cat /proc/1300105/smaps | grep -i pss | awk '{sum+=$2} END {print sum " kB"}'
  2198 kB

[mhoh3963]

Chatgpt로 확인 결과 프로세스의 실제 사용 메모리 사이즈를 확인 하는 방법으로 RSS + SWAP 보다는 PSS 가 더 정확하다고 합니다. 혹시 PSS를 적용하는 것은 어떤지요?

참고로, 아래의 내용은 IDLE 상태의 CAS 메모리 사이즈 입니다.

• RSS + RWAP
  $ cat /proc/1300105/status
  Name: cub_cas
  .
  VmRSS: 10712 kB
  .
  VmSwap: 0 kB
• PSS
  $ cat /proc/1300105/smaps | grep -i pss | awk '{sum+=$2} END {print sum " kB"}'
  2198 kB

두호님의 comment를 가지고 확인해보니, rss에는 shared library에 대한 전체 메모리 크기를 포함하고 pss에서는 shared library에 대한 메모리 크기를 사용하는 프로세스 수로 나눈 크기를 포함하게 되어 있어. pss가 프로세스의 실 메모리값이 좀 더 정확해보입니다.
하지만, status와 smaps을 읽기 성능 비교시 status는 메모리 구조의 값(snapshot)을 가지고 오는데, smaps에서 pss를 구하는 것은 실제 사용하고 있는 메모리를 계산을 통해 크기를 구하고 있어, cpu 부하를 많이 준다고 합니다.
제 생각에는 정확도도 중요하지만 cpu 부하를 최소하는 것이 좋을 것 같습니다.
참고로, 커널 4.14 이후에는 smaps_rollup를 사용하면 pss를 부하없이 구할 수 있다고 하는데, 아직 커널 4.X 아래 버전을 많이 사용하고 있어, 호환성때문에 검토하지 않겠습니다.

[mhoh3963]

/run all

[tw-kang]

/run all

[tw-kang]

/run sql

[tw-kang]

/run all

[mhoh3963]

appl_server_max_size가 default 값 (0)인 경우 getsize() * 2 를 최대치로 보는데, vmsize에서 rss+swap로 변경하면서 최대치가 너무 작아 잦은 cas restart가 발생한다. 이에 2배에서 10배로 변경한다. release와 debug mode에 따라 달라지지만, 대략 최대치는 60M ~ 80M로 설정됨. (예전 코드에서는 대략 90M ~ 100M로 설정되었음)

[mhoh3963]

/run all

[mhoh3963]

/run all