192.168.0.53

localhost

범주 = Synchronization
하위 범주 = Kernel Synch
지연 = 1008.351ms
ntoskrnl.exe!0x3ff293
ntoskrnl.exe!0x3feae6
ntoskrnl.exe!0x2550b0
ntoskrnl.exe!0x2545df
ntoskrnl.exe!0x257f13
ntoskrnl.exe!0x257948
ntoskrnl.exe!0x6b9b6d
ntoskrnl.exe!0x4096b8
ntdll.dll!0x9ce64
// Windows NT BASE API Client DLL.
kernelbase.dll!0x61a7f
// Microsoft .NET Runtime Common Language Runtime
coreclr.dll!0xe9773

원인

for문 안에서 출력을 찍었는데 출력도 딜레이 됨.
client.TestRun 은 async Task라서 딜레이가 발생할 수 없음? 아님 첫 await까지는 같은 스레드임.

여기서 TcpClient가 connection을 동기로 하고 있었음...
그래서 ThreadPool도 여유 있고 Task Queue가 쌓인 것도 없는데 딜레이가 있었던 거임.
근데 그럼 TcpClient에서 remotehost는 딜레이가 없고 localhost는 딜레이가 걸린다는 건데... 그것도 거의 정확히 1초씩... 이유가 뭐지

대응

TcpClient 생성을 비동기로 감싸버림. 근데 이러면 worker thread에서 IO를 하게 될텐데... 그냥 소켓을 직접 쓰는 게 나을 듯

또 한 가지 queue가 엄청 쌓이다가 한 번에 해소되는 현상 있음 (threadCount, pendingWorkerItemCount, tid)

다만 대응 이후 실제로 메시지 전송이 이루어졌는지는 확인하지 않음. (머리 자르러 가야 함)

발견

원인 파악 필요

메모리 사용량 증가

VIRT와 RES가 증가하는 양상이 확인됨

800명 + 종료 전

다시보니 종료하기 전부터 계속 증가하고 있었음

700명 + 종료 전

700명으로 봤을 때는 메모리 증가도 없고 종료도 잘 됨

백로그

DB (uid - user_info)
Redis (uid - session)

https://jsmun.com/50

송신 : 250000 / sec
메시지 크기: 38 byte
예상 : 9500000 byte / sec
실제 : 9793699 byte / sec