솔루션/시스템 성능저하¶
VM 환경¶
VM 성능때문에 M2서비스 성능저하가 발생하나요?¶
Hint
물론입니다.
Hypervisor의 VM 스케쥴링이 원활하지 않다면 OS 전반적인 성능이 저하됩니다. 몇 가지 전조증상이 있습니다.
서비스 품질이 저하되는데 CPU를 100%를 사용하지 못함
CPU 메트릭 중
stolen
이 증가함CPU 메트릭 중
context switches
가 감소함
VM 문제로 인해 원본서버 응답이 느려지나요?¶
Hint
가능합니다.
CPU 성능이 저하되면 네트워크 이벤트가 늦게 처리됩니다. 원본이 응답을 보냈다고 하더라도 CPU가 바빠서 늦게 확인하게 되면 마치 원본응답이 매우 늦는 것처럼 보일 수 있습니다.
왜 CPU를 100%를 사용하지 않지요?¶
Hint
부하량이 적거나 OS 점검이 필요합니다.
M2는 Single-Process, Multi-Threads로 CPU를 최대한 경쟁/사용하도록 개발되었습니다. IO-Wait이나 VM환경에서 CPU Stolen 지표가 상승하는 시스템적 이슈가 아닌 경우 환경적 요인을 검토해봐야 합니다.
메모리¶
서비스 중이 아닌데도 왜 메모리가 반납되지 않나요?¶
Note
정상입니다.
캐싱엔진은 LRU에 따라 최대한 많은 콘텐츠가 즉시 서비스 가능하도록 메모리에 캐싱함으로써 성능을 높입니다. 이는 Disk I/O를 절감하기 위한 기법입니다. 원하신다면 메모리 제한을 통해 일정용량 이상사용하지 않도록 구성이 가능합니다.
{
a: 1,
b: 2
}
Purge가 느려요¶
캐싱엔진은 다음과 같은 성격을 가집니다.
가능한 많은 데이터를 캐싱하기 위해 노력한다.
만료된 데이터라도 언제든 갱신 될 수 있기 때문에 삭제하지 않는다.
캐싱엔진의 인덱싱 구조는 클라이언트의 명확한 URL호출에 검색하는데 최적화되었습니다. 따라서 Purge도 명확한 URL에 대해서는 찰나 의 품질을 보장하지만 패턴 Purge는 그렇지 않습니다.
캐싱개수 튜닝¶
8GB장비에서 캐싱목적으로만 솔루션으로 운용한다면 기본 값으로 약 250만개
가 설정됩니다.
이때 /search/*.do
와 같은 조건으로 와일드 카드 *
가 포함된 패턴 Purge를 수행한다면 인덱싱된 모두 데이터를 탐색합니다.
특히 API처럼 304 Not Modified
로 갱신할 수 없는 데이터라면 더더욱 캐싱을 많이하는 것은 무의미합니다.
서비스가 패턴 Purge를 필연적으로 많이 사용할 수 밖에 없는 서비스라면 캐싱 개수를 줄이는 것이 효과적일 수 있습니다.
많이 캐싱한다고 능사는 아닙니다.
Note
유효개수는 단위 TTL 시간동안의 origin.log의 수의 2~3배수 정도를 산정합니다. 예를 들어 TTL이 10분이고 초당 원본 요청량이 100이라면 6만개면 충분합니다.
100 X 10분 = 60000
또는 원본부하가 가장 심한 시간대의 TTL 동안의 origin.log의 총 라인수를 카운팅해서 산정할 수 있습니다. 캐싱개수는 튜닝하는 방법은 아래와 같습니다.
properties 메모리 사용비율 및 객체크기 튜닝
가상호스트당 최대 캐싱개수 제한
비동기 방식으로 변경¶
동기방식 Purge는 즉시 수행됩니다. 예측할 수 없이 많은 패턴 Purge가 수행된다면 모든 쓰레드가 Purge를 수행하느라 바빠져 정작 서비스를 해야하는 쓰레드가 고갈되는 현상이 발생하게 됩니다. purge 설정을 통해 패턴 Purge의 기본 동작을 비동기( async )방식으로 변경하면 이런 문제가 없도록 큐잉하여 순차적으로 Purge를 수행하게 됩니다.
Note
대기 중인 Purge 명령이 아직 수행 전인 상태에서 대상 콘텐츠가 서비스가 될 우려가 있습니다. preCacheControl 은 이를 방지하여 Purge 예정 콘텐츠가 서비스되는 상황을 방지할 수 있습니다. 단, 이 개수가 너무 클 경우 되려 서비스에 영향을 줄 수 있음에 주의해서 설정해야 합니다.
기타¶
서비스의 성장에 걸맞는 방식의 변화가 필요함을 인지해야 합니다. API 방식은 간단하지만 관리가 어렵습니다. Purge가 서비스의 중요한 부분임을 인지하였다면 캐싱무효화 중 서비스에 적합한 형태로 구조 개선하는 것을 권장합니다.