memcached에서 예기치 않은 (?) 높은 '폐기'메모리


18

업데이트되었습니다. 긴 (죄송한) 질문의 하단을 참조하십시오.

memcached 통계를 보면 이전에 알지 못했던 문제를 발견 한 것 같습니다. 우리는 이상하게도 낭비되는 공간이 많은 것 같습니다. phpmemcacheadmin 에서 변경 사항을 확인한 후이 이미지가 나를 응시하는 것을 발견했습니다.

memcached 캐시 크기 그래픽

이제 최악의 시나리오는 50 %의 낭비가있을 것이라는 인상을 받았지만, 모든 세부 사항을 모르는 것은 처음입니다. 나는 다른 것들 중에서도 실제로 오래된 페이지 를 읽었 지만 memcached 버전 도 읽었습니다 . 시스템이 어떻게 작동하는지 이해한다고 생각하지만 ( :) 76 % 낭비되는 공간을 얻는 방법을 이해하기가 어렵습니다.

phpmemcacheadmin이 표시하는 제거율은입니다 2 ev/s. 여기에 몇 가지 문제가 있습니다.

  • 주요 질문은 이 문제를 해결하기 위해 어떻게해야합니까 ? 나는 그것에 더 많은 메모리를 던질 수있다. (내가 생각할 수있는 여분의 것이있다.) 아마도 슬래브 구성으로 바이올린을 사용해야한다. (이 버전에서도 가능합니까?) 어쩌면 다른 옵션이 있습니까? memcached 버전을 업그레이드하는 것은 빠른 옵션이 아닙니다.

  • 호기심에서 2 층 문제는 물론 75 % (및 상승)의 공간 낭비가 예상된다면, 왜 그런가?

시스템 : 이것은 현재 내가 할 수있는 일이 아니며 memcached 버전이 최신이 아니라는 것을 알고 있지만 이것들은 내가 처리 한 카드입니다.

  • Memcached 1.4.5
  • 아파치 2.2.17
  • PHP 5.3.5

@DavidSchwartz의 답변에 대한 응답으로 다음은 phpmemcacheadmin이 생성하는 슬래브 통계입니다. (다음보다 더 많은 슬래브가 있습니다)

( 나는 또한 나중에 텍스트 형식으로 통계를 붙여 넣었습니다 )

석판 세부 사항

최신 정보

-f 1.5로 데몬을 다시 시작했는데 정말 좋아 보입니다. 약간의 온난화 후 우리는 50/50의 사용 / 폐기물을 얻었습니다. 그러나 이전과 마찬가지로 낮에 더 길어지면 (낮에는 더 바 빠지고) 현재의 30/70으로 떨어지기 시작했지만 낭비는 계속 증가하고 있습니다. 그 외에도, '폐기물'이 어디에서 오는지 아직도 모른다. 이 슬래브를 봅니다.

**Slab 5 Stats**
Chunk Size  496.0 Bytes
Used Chunk  77502 [24.6 %]
Total Chunk 314986
Total Page  149
Wasted      117.3 MBytes
Hits        30.9 Request/sec
Evicted     0

꽉 차 있지 않고 추방되지는 않았지만 117.3MB를 낭비하고 있습니다. 내가 한 빠른 계산 (잘못된 경우 수정)은 다음과 같습니다.

  • 이전 슬래브의 청크 크기는 328이므로 최악의 경우이 슬래브는 329 바이트 청크로 채워집니다.
  • 이는 사용 된 청크 당 167 바이트를 낭비하고 있음을 의미합니다. = 12942834 바이트 = 12.3MB

그렇다면 나머지 105MB 는 어디서 비롯 되었습니까? 바로 옆에있는 더 큰 형제입니다.

**Slab 6 Stats** 
Chunk Size  744.0 Bytes
Used Chunk  17488 [31.0 %]
Total Chunk 56360
Total Page  40
Wasted      31.1 MBytes
Hits        107.7 Request/sec
Evicted     1109

문제는 다른 슬래브에 사용되지 않은 공간이 너무 많지만 슬래브 3이 100 % 가득 차서 제거하는 것입니다.
David Schwartz

좋은 점은 퇴거를 설명 할 것이지만 실제로 '폐기물'수를 계산하는 방법을 잘 모르겠습니다. 슬래브 8에 13.9 % 만 사용 된 경우 "여유"공간이 남아 있어야합니까?
Nanne

네, 그 석판에는 여유 공간이 있습니다. 그러나 퇴거되는 물체가 해당 슬래브에 들어 가지 않으면 도움이되지 않습니다.
David Schwartz 2016 년

그게 내가 당신의 대답에서 얻은 것인데, 여유 공간이없는 이유는 무엇입니까? 내가 생각 무엇을 그 공간은 적어도 왼쪽 여전히 존재하는 경우 (내 테스트 설치에로) 그 파이 차트 흰색의 일부가되어야합니다
Nanne

답변:


10

이 질문 이후 1 년이 지났는데, 당신이 답을 찾았는지 모르겠지만“폐기”에 대한 당신의 인식이 잘못되었다고 말할 것입니다.

낭비 된 메모리는 메모리에 할당되므로 다른 응용 프로그램에서 사용할 수 없지만 여전히 memcached에 사용할 수 있습니다.

설명을 단순화하기 위해 3 개의 슬래브가있는 3MB의 램이있는 memcache가 있다고 가정합니다.

slab class  1: chunk size     10485 perslab      100
slab class  2: chunk size    104857 perslab       10
slab class  3: chunk size   1048576 perslab        1

10k 크기의 단일 "세트"를 실행하십시오. 통계에서 대략적으로 볼 수 있습니다.

0.03% used
66.6% free
33% wasted

이것은 memcached가 "슬래브 클래스 1"에서 단일 청크를 할당하고 해당 슬래브에 대한 메모리의 99 %가 "소비"되고 1 %가 "사용"되었기 때문입니다. 이는 해당 슬래브에 할당 된 슬래브 및 메모리가 사라 졌음을 의미하지 않습니다.

10k 크기의 다른 단일 "세트"를 실행하십시오. 이번에는 다음을 볼 수 있습니다 :

0.06% used
66.6% free
32.7% wasted

이제 슬래브 1에 할당 된 100 개의 청크 중 2 개를 사용하고 "폐기"통계가 삭제되었으며 사용 된 통계가 증가했습니다.

사용한 % + 낭비 %가 100 %와 같은 것은 잘못된 것이 아닙니다. 즉, 더 이상 메모리가 남아 있지 않다는 의미는 아닙니다. 단순히 각 슬래브에서 하나 이상의 청크를 할당했음을 의미합니다.

이 문제를 보려면 100k 크기의 "세트"와 1000k 크기의 다른 세트를 확인하십시오.

이제 보자

36.6% used
   0% free
63.3% wasted

그 좋은 소리! 이것을 백업 할 수있는 링크가 있습니까? 그렇다면 내 memcache-server가 (성능이) 더 우수하다는 것을 의미합니다. 내가 당신을 올바르게 이해한다면 낭비는 그것이 할당되었지만 여전히 사용할 수 있음을 의미합니다. 이것은 비어있는 것이 없다면 더 많은 슬래브를 할당 할 수 없지만 문제가 있다는 의미는 아닙니다.
Nanne

1
머리 위에 링크가 없지만 테스트하기는 매우 쉽습니다. 명령 행을 누르고 샘플 소형 서버를 작성하여 작동 방식을 테스트하십시오. 상세 디버그 메시지에 -vv 옵션을 사용할 수 있습니다. 초기에 생성 된 슬래브가 표시됩니다. "memcached -vv -p 11500 -m 3 -n 10000 -f 10"은 청크 크기가 10k 100k 및 1000k 인 3 개의 슬래브를 생성합니다. 계속해서 "세트"를 발행하면 위에서 설명한대로 낭비 / 사용 된 통계가 변경되는 것을 볼 수 있습니다.
kali

좋은 지적. 지금 내가 당신을 위해이 답변에 약간의주의를 기울일 수있는 방법을 찾으려면 :)
Nanne

6

아마도 아주 작은 수의 아주 작은 물체가있을 것입니다. 일반적으로 가장 작은 슬래브에는 104 바이트 항목이 있습니다. 하나의 정수를 다른 정수에 매핑하는 항목이 많은 경우 폐기물을 85 %까지 높일 수 있습니다.

작은 개체에 대한 Memcached 문서에서이를 조정하는 방법에 대한 정보를 찾을 수 있습니다 .


통계 페이지를 올바르게 읽으면 그렇지 않습니다. 대부분의 폐기물은 480.0 바이트 청크가있는 슬래브에 있습니다. 통계를 보여줄 수 있는지 확인해 보겠습니다.
Nanne

아, 그러면 이것은 괜찮고 정상이며 걱정할 것이 없습니다. 데이터가 적습니다. (공지 사항, 예를 들어, 그 슬래브는 14 %를 사용하고 있는지.)
데이비드 슈워츠

그러나 75 %는 어떻게 정상적인 낭비입니까? 이 숫자에 사용되지 않은 공간이 포함됩니까? "무료"로 계산 될 것으로 예상됩니다. 또한 우리는 하루가 지남에 따라 사용 된 메모리가 줄어들고 // 사이트가 더 바빠지는 것을 볼 수 있습니다. 그리고 우리가 퇴거를한다는 사실은 무엇을 할 수 있는지 궁금하게 만듭니다.
Nanne

슬래브가 적 으면 잘못된 슬래브에 너무 많은 메모리가 걸리는 문제를 피하는 데 도움이 될 수 있습니다. 예를 들어 -f 1.5 -I 2800도움이 될 수 있습니다.
David Schwartz

맨 페이지가 너무 명확하지 않습니다 -I 2800. 1M 기본값과 달리 2800K를 의미합니까?
Nanne

-1

나는이 문제가 있었고 memcached에서 redis로 옮겼다 (디스크 기반 저장하지 않고). 나는 이것이 가능하지 않을 수도 있지만 옵션으로 시도해보고 메모리 조각화를 계속 볼 수 있습니다. 재시작시 "이전 캐시"문제를 해결하기 위해 지속성을 설정할 수도 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.