니스 다시 시작 추적

우리 니스 인스턴스니스 다시 시작 추적

/usr/sbin/varnishd -P /var/run/varnish.pid -a :6081 -f /etc/varnish/cm-varnish.vcl -T 127.0.0.1:6082 -t 1h -u varnish -g varnish -S /etc/varnish/secret -s malloc,24G -p shm_reclen 10000 -p http_req_hdr_len 10000 -p thread_pool_add_delay 2 -p thread_pools 8 -p thread_pool_min 500 -p thread_pool_max 4000 -p sess_workspace 1073741824

32G 램, 16 코어 프로세서와 우리는 우리의 광택 인스턴스의

평균 가동 시간은 매우 낮은 인 3 시간을 유지 니스 메모리의 24기가바이트를 할당합니다. 캐시 TTL은 1Hr이고 유예 시간은 2Hrs입니다. 일단 5 분마다 우리는 일반적으로 자바 프로세스를 통해 캐시 내용을 [n 개 이상의 히트와 함께] 새로 고칩니다. 우리는 꾸준히 폴링 varnishncsa 출력 폴링하여 니스의 안타를 추적합니다.

나는 varnishadm panic.show

Last panic at: Thu, 23 May 2013 09:14:42 GMT 
Assert error in WSLR(), cache_shmlog.c line 220: 
    Condition(VSL_END(w->wlp, l) < w->wle) not true. 
thread = (cache-worker) 
ident = Linux,2.6.18-238.el5,x86_64,-smalloc,-smalloc,-hcritbit,epoll 
Backtrace: 
    0x42dc76: /usr/sbin/varnishd [0x42dc76] 
    0x432d1f: /usr/sbin/varnishd(WSLR+0x27f) [0x432d1f] 
    0x42a667: /usr/sbin/varnishd [0x42a667] 
    0x42a89e: /usr/sbin/varnishd(http_DissectRequest+0xee) [0x42a89e] 
    0x4187d1: /usr/sbin/varnishd(CNT_Session+0x741) [0x4187d1] 
    0x42f706: /usr/sbin/varnishd [0x42f706] 
    0x3009c0673d: /lib64/libpthread.so.0 [0x3009c0673d] 
    0x30094d40cd: /lib64/libc.so.6(clone+0x6d) [0x30094d40cd]

우리는 그리워 것에 대한 모든 입력을 시도?

출처

2013-05-23 Tamil

기본 고급 값으로 바니시를 사용해 보았습니까? 나는'-p shm_reclen 10000 -p http_req_hdr_len 10000 -p thread_pool_add_delay 2 -p thread_pools 8 -p thread_pool_min 500 -p thread_pool_max 4000 -p sess_workspace 1073741824' – NITEMAN

이 값은 http://kly.no/posts/를 기준으로 선택했습니다. 2010_01_26__Varnish_best_practices __html. html에는 어설 션과 관련된 것이 있습니까 – Tamil

그 게시물은 상당히 오래된 것입니다 (Varnish 2.x AFAIK 참조). 명확하게 "필요에 따라 조정"이라고 명시되어 있습니다. 저에게있어서, 이런 종류의 문제를 디버깅/추적 할 때 가장 먼저하는 일은 기본 설정에 충실합니다. – NITEMAN

http_req_hdr_len을 오버플로하도록 매우 긴 쿠키 문자열 (또는 다른 사용자 정의 헤더)을 사용하는 것이 가장 좋습니다. 고정 된 버그에 대해서는 afaik가 안정 버전으로 공개하지 않은 것을 읽은 것을 기억합니다. 나는 내 자신의 기억보다 더 좋은 소식통을 갖고 있지 않다.

sess_workspace 및 가능한 총 스레드 수 또한 매우 높습니다. 이는 대부분의 설정에서 스와핑을 위험에 빠뜨리는 것보다 성능면에서 적습니다.

출처

2013-07-01 11:50:41 Clarence

니스 다시 시작 추적

답변

관련 문제