memcached를 사용하면 수백/수천 개의 TCP 소켓이 합리적입니까?

StackOverflow https://stackoverflow.com/questions/849717

문제

저는 txt/xml을 저장하기 위해 Merb::Cache를 사용하고 있으며, merb를 오래 놔둘수록 열려 있는 열린 tcp 소켓의 양이 더 많아진다는 사실을 발견했습니다. 이로 인해 몇 가지 주요 성능 문제가 발생한다고 생각합니다.

lsof | grep 11211 | wc -l
494

merb      27206       root   71u     IPv4   13759908                 TCP localhost.localdomain:59756->localhost.localdomain:11211 (ESTABLISHED)
merb      27206       root   72u     IPv4   13759969                 TCP localhost.localdomain:59779->localhost.localdomain:11211 (ESTABLISHED)
merb      27206       root   73u     IPv4   13760039                 TCP localhost.localdomain:59805->localhost.localdomain:11211 (ESTABLISHED)
merb      27206       root   74u     IPv4   13760052                 TCP localhost.localdomain:59810->localhost.localdomain:11211 (ESTABLISHED)
merb      27206       root   75u     IPv4   13760135                 TCP localhost.localdomain:59841->localhost.localdomain:11211 (ESTABLISHED)
merb      27206       root   76u     IPv4   13760823                 TCP localhost.localdomain:59866->localhost.localdomain:11211 (ESTABLISHED)
merb      27206       root   77u     IPv4   13760951                 TCP localhost.localdomain:52095->localhost.localdomain:11211 (ESTABLISHED)

등...

내 관련 코드는 다음과 같습니다

    if !exists?(:memcached) then
      register(:memcached, Merb::Cache::MemcachedStore, :namespace => 'mynamespace', :servers => ['127.0.0.1:11211'])
    end

&& 

    when :xml
      unless @hand_xml = Merb::Cache[:memcached].read("/hands/#{@hand.id}.xml")
        @hand_xml = display(@hand)
        Merb::Cache[:memcached].write("/hands/#{@hand.id}.xml", @hand_xml)
      end
      return @hand_xml

이 코드가 완전히 잘못된 건가요, 아니면 제가 잘못된 버전의 memcache를 사용하고 있는 건가요??

나는 1.2.8을 memcached했으며 다음과 같은 것을 가지고 있습니다.

libmemcached-0.25.14.tar.gz memcached-0.13.gem

이게 날 미치게 만드네요..

도움이 되었습니까?

해결책

K 나는 몇 가지를 알아 냈습니다 ..

1) epoll 또는 다른 것을 사용하는 라이브러리를 사용하고 있다고 가정 할 때 Memcached에 수백/수천 개의 소켓을 연결하는 것이 합리적 일 수 있습니다. select () 또는 poll () 이외의 다른 질문이 있습니다. 따라서 이것은이 질문에 맞습니다.

2) 당신이 나와 같은 경우, 당신은 지금 당장 멤버가 1 개의 멤버를 실행 중이며 요청을 돌보는 두 개의 몽 그렐/얇은 것들이 있습니다. 달리고있는 몽 그렐/얇은 수에 지나지 않아야합니다 (1 ~ 두 세트의 물건 만 캐싱한다고 가정) - 제 경우였습니다.

다음은 수정 사항입니다.

merb :: 캐시 대신 memcached gem을 통한 memcache 설정 (실제로 사용중인 Memcache Lib를 실제로 포장합니다.

MMCACHE = Memcached.new("localhost:11211")

값 가져 오기/설정 :

  @cache = MMCACHE.clone
  begin
    @hand_xml = @cache.get("/hands/#{@hand.id}.xml")
  rescue
    @hand_xml = display(@hand)
    @cache.set("/hands/#{@hand.id}.xml", @hand_xml)
  end
  @cache.quit

이렇게하면 앉아서 차가운 원인을 마시십시오.

lsof | grep 11211 | wc -l

2036 대신 2 또는 3과 같은 것을 볼 수 있습니다!

Memcache Connects가 처음부터 지속적이라는 것은 드문 일이 아니라는 점에서 나를 모호한 암초에 소비합니다.

다른 팁

제가 도울 수 있을지 모르지만 그러기 위해서는 이야기를 해야 합니다.여기있어.

옛날에는 각각 정확히 100개의 스레드를 갖도록 구성된 10개의 Apache(Ssl) 서버 클러스터가 있었습니다.또한 (동일한 상자에) 10개의 Memcached 서버 클러스터가 있었고 모두 보였다 평화롭게 살기 위해.Apache와 Memcached 모두 악마의 보호를 받았습니다. 모니터 데몬.

그런 다음 King은 11번째 Apache(Ssl) 서버를 설치했고 Memcached는 몇 시간마다 무작위로 다시 시작되었습니다!왕은 조사를 시작했고 무엇을 발견했습니까?Memcache 연결 객체의 기본 생성자가 다음과 같다고 말하는 PHP Memcache 모듈 문서에 버그가 있었습니다. ~ 아니다 끈질겼지만 분명히 그랬다.일어난 일은 모든 PHP 스레드(그리고 그 중 1000개 정도)가 필요할 때 풀에 있는 모든 memcached에 대한 연결을 열고 유지했다는 것입니다.모든 memcached 서버에는 10*100개의 연결이 있었고 괜찮았지만 11개의 서버에서는 1100이었고 1024<1100이었습니다.memcached의 최대 오픈 소켓 수는 1024개였습니다.모든 소켓이 확보되면 monit 데몬이 연결되지 않아 memcached를 다시 시작했습니다.

모든 이야기에는 도덕이 있어야 합니다.그러면 왕은 이 모든 일을 어떻게 하였습니까?그는 지속적인 연결을 비활성화했고 클러스터의 연결 수가 최대 5개로 늘어나 모두 행복하게 살았습니다.해당 서버는 엄청난 양의 데이터를 제공하고 있었기 때문에 1000개의 예비 소켓을 가질 수 없었고 모든 요청에 ​​대해 Memcache 연결을 협상하는 것이 더 저렴했습니다.

죄송하지만 루비는 잘 모르겠습니다. 스레드가 너무 많거나 캐싱을 잘못하신 것 같습니다.

행운을 빌어요!

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top