이상한 G-WAN 응답 속도 차이

Question

나는 G-WAN 웹 서버를 구현하고 내 코드를 테스트했지만 서버 응답이 매우 빠르게 (20ms), 때로는 몇 초 (6 -7 초) 또는 심지어 시간 초과 ...

내 코드를 단순화하고 클라이언트에 문자열을 반환하려고하면 문제가 여전히 발생합니다. 게다가 코드를 사용하여 시간을 기록했습니다. 1 초 이상, 무슨 문제가 발생 했나요?!

나는 네트워크 지연으로 인한이 같은 추측과 같은 서버의 네트워크 속도를 테스트, 아주 빨리, 어떤 생각? (으로 인한 문제는 MySQL은 같은 일부 타사 라이브러리를 포함 할 것인가?) 여기

내 G-WAN 로그입니다 :

*------------------------------------------------ 
*G-WAN 4.3.14 64-bit (Mar 14 2013 07:33:12) 
* ------------------------------------------------ 
* Local Time: Mon, 29 Jul 2013 10:09:05 GMT+8 
* RAM: (918.46 MiB free + 0 shared + 222.81 MiB buffers)/1.10 GiB total 
* Physical Pages: 918.46 MiB/1.10 GiB 
* DISK: 3.27 GiB free/6.46 GiB total 
* Filesystem Type Size Used Avail Use% Mounted on 
* /dev/mapper/vg_centos6-root 
*    ext4 6.5G 3.2G 3.0G 52%/ 
* tmpfs  tmpfs 1004M 8.2M 995M 1% /dev/shm 
* /dev/xvda1 ext4 485M 129M 331M 28% /boot 
* 105 processes, including pid:10874 '/opt/gwan/gwan' 
* Page-size:4,096 Child-max:65,535 Stream-max:16 
* CPU: 1x Intel(R) Xeon(R) CPU E5506 @ 2.13GHz 
* 0 id: 0  0 
* Cores: possible:0-14 present:0 online:0 
* L1d cache: 32K line:64  0 
* L1i cache: 32K line:64  0 
* L2 cache: 256K line:64  0 
* L3 cache: 4096K line:64  0 
* NUMA node #1 0 
* CPU(s):1, Core(s)/CPU:0, Thread(s)/Core:2 
* Bogomips: 4,256.14 
* Hypervisor: XenVMMXenVMM 
* using 1 workers 0[1]0 
* among 2 threads 0[]1 
* 64-bit little-endian (least significant byte first) 
* CentOS release 6.3 (Final) (3.5.5-1.) 64-bit 
* user: root (uid:0), group: root (uid:0) 
* system fd_max: 65,535 
* program fd_max: 65,535 
* updated fd_max: 500,000 
* Available network interfaces (3): 
* 127.0.0.1 
* 192.168.0.1 
* xxx.xxx.xxx.xxx 
* memory footprint: 1.39 MiB. 
* Host /opt/gwan/0.0.0.0_8080/#0.0.0.0 
* loaded index.c      3.46 MiB MD5:afb6c263-791c706a-598cc77b-e0873517 
* memory footprint: 3.40 MiB. 

Answer 1

내가 -g 모드를 사용, 최대 근로자의 수를 늘리면 서버의 CPU 수에이 문제가 해결 된 것 같습니다.

그런 다음 CPU 검색 문제 인 것 같습니다. gwan.log 파일 헤더 (CPU 탐지)의 관련 부분을 덤프하여보십시오.

검색 및 링크해야하는 외부 라이브러리를 사용하여 G-WAN을 다시 컴파일해야하는 경우 (특히 작업자가 하나이고 다른 요청이 대기중인 경우)에는 시간이 걸릴 수 있습니다.

---

UPDATE :

CPU: 1x Intel(R) Xeon(R) CPU E5506 @ 2.13GHz 
    0 id: 0  0 
Cores: possible:0-14 present:0 online:0 
CPU(s):1, Core(s)/CPU:0, Thread(s)/Core:2 
Hypervisor: XenVMMXenVMM 
    using 1 workers 0[1]0 
    among 2 threads 0[]1 

인텔 E5506은 4 코어 CPU입니다 ...하지만 Xen Hypervisor 1 개 CPU 및 를보고 : 당신의 gwan.log 파일 덤프 다음, 여기에 중요한 것입니다 0 코어 (그리고 하이퍼 스레딩이 활성화되어있어 어떤 CPU 코어도 없이는 의미가 없습니다.)

왜 Xen은 완전한 논란이있는 CPU에 대한 진짜이고 올바른 정보를 손상시키는 것이이 토론의 목적을 넘어서는 것입니다.

내가 말할 수

이가 (손상된 리눅스 커널 /proc과 CPUID 명령에 의해보고 된 잘못된 정보를 우회하는 ./gwan -g -w 4에 따라서 '수정') '모리'가 경험 한 문제의 원인이라는 것이다.

CPU 토폴로지를 감지하는 두 가지 표준 방법 : Linux 커널/proc 구조 및 CPUID 명령을 방해함으로써 G-WAN과 같은 멀티 코어 소프트웨어가 올바르게 실행되지 못하게하는 뇌 손상 하이퍼 바이저를 사용하지 않는 것이 좋습니다.