NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
Windows IOCP vs Linux EPOLL Performance ComparisonSeungmo Koo
1. The document compares the performance of IOCP and EPOLL for network I/O handling on Windows and Linux servers.
2. Testing showed that throughput was similar between IOCP and EPOLL, but IOCP had lower overall CPU usage without RSS/multi-queue enabled.
3. With RSS/multi-queue enabled on the NIC, CPU usage was nearly identical between IOCP and EPOLL.
NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
Windows IOCP vs Linux EPOLL Performance ComparisonSeungmo Koo
1. The document compares the performance of IOCP and EPOLL for network I/O handling on Windows and Linux servers.
2. Testing showed that throughput was similar between IOCP and EPOLL, but IOCP had lower overall CPU usage without RSS/multi-queue enabled.
3. With RSS/multi-queue enabled on the NIC, CPU usage was nearly identical between IOCP and EPOLL.
NHN NEXT 게임 서버 프로그래밍 강의 자료입니다. 최소한의 필요한 이론 내용은 질문 위주로 구성되어 있고 (답은 학생들 개별로 고민해와서 피드백 받는 방식) 해당 내용에 맞는 실습(구현) 과제가 포함되어 있습니다.
참고로, 서버 아키텍처에 관한 과목은 따로 있어서 본 강의에는 포함되어 있지 않습니다.
빌드? 우선 사용부터 매뉴얼? Getting started 한 번 돌려보기 TV 리모컨 버튼 5개 전문가는 교육받아 만들어진다? 경험=시간+시행착오+성공실패 오픈소스 트러블슈팅 “메시지” 구글링 오픈소스 함부로 수정하지 마라 최신 버전을 대하는 우리의 자세 LTS로 대동단결 팀장 설득하기 오픈소스는 공짜가 아닙니다. 저도 기여하고 싶어요 2,000년 톰캣을 시작으로 Ant, Eclipse, JUnit, JMeter를 거쳐 현재 개발에 잘 사용하고 있는 Yona, Git, VSCode, Jenkins, CentOS, VirtualBox, Nginx, Node.js, Express.js, MariaDB, Uptime, Mocha, SonarQube, ZAP 이야기 등입니다.
https://www.youtube.com/watch?v=5LHOTBxG0hc
어느날 우연히 스위처 소방수로 참여해서 2달 동안 수행한 일들을 공유합니다. 그 첫번재 이야기 ‘기본을 지키자’ 입니다.
전체를 리드하면서 업무를 진행해본 첫 경험이기도 했고, 유저가 증가하며 서비스되고 있는 프로젝트를 A to Z로 혼자 감당해본 첫 경험이기도 했습니다.
새로운 서버를 설계하고 개발하면서, 레거시 안정화 및 이슈 응대를 모두 병행하는게 쉬운 일은 아니었지만, 핑계대지 않고 하나하나 기본을 다져 보았습니다!
아직 갈길이 멀었지만, 성장해가는 아이오(스위처)의 소프트웨어 이야기를 하나씩 하나씩 풀어보려 합니다 ;)
Auto Scalable 한 Deep Learning Production 을 위한 AI Serving Infra 구성 및 AI DevOps...hoondong kim
[Tensorflow-KR Offline 세미나 발표자료]
Auto Scalable 한 Deep Learning Production 을 위한 AI Serving Infra 구성 및 AI DevOps Cycle 구성 방법론. (Azure Docker PaaS 위에서 1만 TPS Tensorflow Inference Serving 방법론 공유)
3. 강사 소개
•현재 : 한국산업기술대학교 게임공학부 부교
수
• 게임서버 프로그래밍 , 멀티코어 프로그래밍
•게임 제작 이력
• NCSOFT
• Lineage Forever(MMO), Alterlife(MMO), Team BL
(Blade & Soul, MMO), 게임서버 & 물리엔진 연동
• 넷마블 ( 공동연구 )
• 글로벌 모바일 서버 연구 , FPS Game 서버 리모델링 ,
리니지 2 레볼루션 (MMO) 서버 안정화
4. 강사 소개
•NDC 발표
• [NDC12] 멀티 쓰레드 프로그래밍이 왜 이리 힘드나요
?
• ( 컴파일러와 하드웨어에서 Lock-free 알고리즘 까지 )
• [NDC14] 시즌 2 : 멀티쓰레드 프로그래밍이 왜 이리
힘드나요 ?
• (Lock-free 에서 Transactional Memory 까지 )
7. 멀티스레드 프로그래밍
•피할 수 없다
• CPU 가 느리기 때문
•어렵다
• 소스코드에서 디버거로 해결이 안되는 문제들이 있다 .
• [NDC12] 발표 참조
• 성능향상이 힘들다
• Lock-free 를 동원해야 한다 . [NDC14] 발표 참조
8. 모던 C++
•실제 게임 구현에 많이 사용되고 있다 .
• 사용하지 않을 이유가 없다 .
•생산성 향상
• auto, lambda, for (a : b) …
•표준
• 멀티스레딩 / 네트워킹 코드의 표준
• Visual Studio 나 g++ 이나 같은 코드
9. SHARED_PTR
•shared_ptr 가 무엇인지 알고 계신 분 ?
• weak_ptr 가 무엇인지 알고 계신 분 ?
•shared_ptr 를 사용하고 계신 분 ?
•shared_ptr 를 멀티스레드에서 사용하고 계신
분 ?
10. SHARED_PTR
•원래 용도
• delete 누락으로 인한 메모리 leak 방지
•멀티쓰레드에서의 재발견
• 메모리 Life Cycle 문제의 나이스한 해결책
• new 로 할당 받은 자료구조를 여러 스레드에서 공유할 때
참조 중인 객체가 불시에 delete 당하는 것을 막아줌
• 다른 쓰레드가 참고하고 있지 않은 것을 확인하면서 delete
하는 골치 아픔을 없앰
13. 문제
•뒤에 있는 주의사항은 왜 다들 무시하는가 ?
If multiple threads of execution access the same
shared_ptr without synchronization and any of those
accesses uses a non-const member function of
shared_ptr then a data race will occur; the
shared_ptr overloads of atomic functions can be used
to prevent the data race.
이것과는 관계 없습니
다 .
14. 문제
•뒤에 있는 주의사항은 왜 다들 무시하는가 ?
•실제로 주의 하지 않고 사용되었던 사례들이
있음 .
•판사님 저는 아무 말도 하지 않았습니다 .
17. 결론
•shared_ptr 의 대상에 접근하는 것은 thread
safe 하다 .
• 접근만 ! 대상 자체는 다른 문제 !!
•하지만 공유 shared_ptr 변수의 접근
(load, store) 은 thread safe 하지 않다 .
• local shared_ptr 변수의 사용은 항상 안전하다 .
• local shared_ptr 가 가리키는 객체가 shared 일 경우에도
28. WEAK_PTR
•shared_ptr 만으로는 모든 경우를 커버할 수 없다 .
•메모리 leak 을 피하기 위해서는 weak_ptr 가 필요
하다 .
• 자식이 부모를 pointing 해야 할 경우 !!!
•weak_ptr 도 shared_ptr 와 같이 atomic_weak_ptr
를 사용해야 한다 .
29. WEAK_PTR
•weak_ptr::lock() 을 어떻게 atomic 하게 하지 ????
• atomic_load() 사용
• 구현된 atomic_weak_ptr 사용
• 내부적으로 mutex 사용
• atomic_weak_ptr 자체 구현
• 내부적으로 mutex 사용
37. 결론
•shared_ptr 는 절대로 멀티쓰레드 safe 가 아니다 .
•atomic_shared_ptr 를 사용하자 .
• 구매 또는 C++20 까지 참기
• mutex 를 통한 자체 구현
• weak_ptr 까지 set 로 구현 필요
• lock-free 자체 구현
• 연구비만 주시면…
•성능에 신경 쓰자
• 가능하면 사용 빈도를 줄이고 , copy 대신 reference 를 사용
38. 참조
•mutex 구현과 벤치마크프로그램
• https://drive.google.com/drive/folders/0B_q-ByE4opaId2dIL
• 완벽한 검증은 사용자의 몫 ( 연구비 필요… )