Subscribe to Primrose
PrimroseUvicorn & Gunicorn
Uvicorn and GunicornUvicorn and Gunicorn are important concepts when developing applications in Python. However, there are many concepts to be aware of in order to fully understand Uvicorn and Gunicorn. The following is a brief summary of the necessary concepts, and the details will be dealt with separately later.Necessary ConceptsStarletteStarlette is a Web application server that can run asynchronously. Starlette runs on top of Uvicorn.FastAPIFastAPI provides many features on top of Starlet...
PrimroseGas optimization in Solidity, Ethereum
I’m sorry but my English is terrible. I hope you understand that generously.Recently, I was developing a toy project named Blind Market. It’s a simple P2P trading application using smart contract. I was making a contract using Solidity, and the trade stage proceeded in the order of pending, shipping, and done. The problem was appeared in done phase. The problem was that when I tried to close the transaction by paying the price raised by the seller in msg.value, the following error occurred.Pe...
PrimroseP2WPKH
P2WPKHP2WPKH란 비트코인 내에서 가장 일반적인 스크립트 형식으로 비트코인 프로토콜에 대한 지불 거래 유형이다. 주소는 1로 시작하는데, 세그윗을 지원하는 새로운 주소 3 또는 bc1로 시작하는 주소보다 훨씬 비싸다. https://mirror.xyz/0xA1d9f681B25C14C1eE7B87f1CF102E73cA3ad4d9/egjhNVklgy_LgZmcTXXAOTBa6ePBqO3Ja9ZSoDIad-8 즉, 비트코인 주소가 1로 시작하면 P2PKH 주소를 사용하고 있는 것이다. 공개키의 간단한 해시이며, 이 해시를 주소로 사용하는 것이다. 이것은 원래 비트코인 주소 형식이었으며 오늘까지도 충실히 작동한다. 레거시 주소는 세그윗과 호환되지 않지만, 여전히 문제없이 P2PKH 주소에서 세그윗 주소로 BTC를 보낼 수 있다. 그러나 레거시 주소 트랜잭션이 더 크기 때문에 P2PKH 주소에서 전송하는 평균 속도는 세그윗 주소에서 전송할 때보다 더 높은 요금이 발생할 수 있다....
<100 subscribers
PrimroseUvicorn & Gunicorn
Uvicorn and GunicornUvicorn and Gunicorn are important concepts when developing applications in Python. However, there are many concepts to be aware of in order to fully understand Uvicorn and Gunicorn. The following is a brief summary of the necessary concepts, and the details will be dealt with separately later.Necessary ConceptsStarletteStarlette is a Web application server that can run asynchronously. Starlette runs on top of Uvicorn.FastAPIFastAPI provides many features on top of Starlet...
PrimroseGas optimization in Solidity, Ethereum
I’m sorry but my English is terrible. I hope you understand that generously.Recently, I was developing a toy project named Blind Market. It’s a simple P2P trading application using smart contract. I was making a contract using Solidity, and the trade stage proceeded in the order of pending, shipping, and done. The problem was appeared in done phase. The problem was that when I tried to close the transaction by paying the price raised by the seller in msg.value, the following error occurred.Pe...
PrimroseP2WPKH
P2WPKHP2WPKH란 비트코인 내에서 가장 일반적인 스크립트 형식으로 비트코인 프로토콜에 대한 지불 거래 유형이다. 주소는 1로 시작하는데, 세그윗을 지원하는 새로운 주소 3 또는 bc1로 시작하는 주소보다 훨씬 비싸다. https://mirror.xyz/0xA1d9f681B25C14C1eE7B87f1CF102E73cA3ad4d9/egjhNVklgy_LgZmcTXXAOTBa6ePBqO3Ja9ZSoDIad-8 즉, 비트코인 주소가 1로 시작하면 P2PKH 주소를 사용하고 있는 것이다. 공개키의 간단한 해시이며, 이 해시를 주소로 사용하는 것이다. 이것은 원래 비트코인 주소 형식이었으며 오늘까지도 충실히 작동한다. 레거시 주소는 세그윗과 호환되지 않지만, 여전히 문제없이 P2PKH 주소에서 세그윗 주소로 BTC를 보낼 수 있다. 그러나 레거시 주소 트랜잭션이 더 크기 때문에 P2PKH 주소에서 전송하는 평균 속도는 세그윗 주소에서 전송할 때보다 더 높은 요금이 발생할 수 있다....
Share Dialog
Share Dialog
이번에 회사에서 이런 저런 엔진 작업을 할 일이 생겼다.
gRPC, Channel, context 등을 다루면서 자연스레 프로세스도 많아지고, 프로세스 내에서 실행되는 고루틴도 많아졌다.
그러다 든 의문은, goroutine이 100만개가 생성되면, 어떤 식으로 실행이 될 것이고, 정말 그게 더 빠를까?
go 코드를 작성 후 컴파일하면 바이너리 파일에 go runtime이 같이 컴파일된다.
바이너리를 실행할 때 해당 runtime이 go의 gc와, goroutine의 스케줄링을 실시한다.
오늘은 goroutine의 스케줄링과 런타임 등에 대해서 알아보고자 한다.
Go 문서를 읽어보면 Goroutine 개수에 대해 걱정하는 것은 섣부른 최적화라고 나와 있을 정도로 Goroutine은 가볍다고 한다.
또한 각 Goroutine간의 스위칭시에 오버헤드도 적고, 병행 실행에 관한 최적화된 처리를 go runtime scheduler가 처리해준다고 한다.
go runtime에서는 세가지 C 구조체를 활용하여 go routine을 관리한다
G(goroutine)구조체: 단일 goroutine을 표현하는 구조체이다. goroutine에 필요한 스택, 상태정보, 담당하고 있는 코드의 레퍼런스를 담고있다.
M(machine)구조체: OS 쓰레드를 표현하는 구조체이다. global queue, local queue에 있는 실행 가능한 goroutine에 대한 포인터, 지금 실행하고 있는 고루틴에 대한 포인터, 스케쥴러의 cache와 reference를 담고 있다.
P(processor)구조체: 논리적인 프로세서를 표현하는 구조체이다.
기본적으로 cpu 코어 갯수로 할당되는데, runtime.GOMAXPROCS로 조절도 가능하다.
할당 수에 제한이 있기 때문에 고루틴이 많아도 그 갯수만큼 많은 쓰레드를 생성하지 않음
go scheduler는 두가지 큐를 활용하여 G를 스케쥴링한다
GRQ(global run queue): P에 할당되지 않은 G들을 저장
LRQ(local run queue): P에서 처리할 G들을 저장
각각의 P 구조체에는 LRQ가 하나씩 할당된다.
결국 G(goroutine)을 실행하기 위해선 G를 M,P에 할당해주어야한다.
하나의 G가 블락되면 P는 LRQ의 다른 G를 M에 할당한다.
만약 시스템 콜 등으로 P에 할당된 M 자체가 OS 기준으로 블락된 경우엔 P의 할당을 해제해버리고 쉬고있는 M을 P에 할당한다.
go의 라이브러리에서 일반적으로 system call로 처리되어 블로킹 당할만한 것들(소켓과 파일의 I/O처리, 타이머)은 OS에서 제공하는 기능들을 이용해 I/O 멀티플렉싱을 수행하기 때문에 사실 go 에서는 블락킹 자체가 많이 일어나지 않음 → 하나의 코어의 효율적인 쓰레딩 지원
P안에서 처리 우선순위는 다음과 같다
LRQ의 G → 다른 P의 LRQ의 G → GRQ의 G → network poll
이번에 회사에서 이런 저런 엔진 작업을 할 일이 생겼다.
gRPC, Channel, context 등을 다루면서 자연스레 프로세스도 많아지고, 프로세스 내에서 실행되는 고루틴도 많아졌다.
그러다 든 의문은, goroutine이 100만개가 생성되면, 어떤 식으로 실행이 될 것이고, 정말 그게 더 빠를까?
go 코드를 작성 후 컴파일하면 바이너리 파일에 go runtime이 같이 컴파일된다.
바이너리를 실행할 때 해당 runtime이 go의 gc와, goroutine의 스케줄링을 실시한다.
오늘은 goroutine의 스케줄링과 런타임 등에 대해서 알아보고자 한다.
Go 문서를 읽어보면 Goroutine 개수에 대해 걱정하는 것은 섣부른 최적화라고 나와 있을 정도로 Goroutine은 가볍다고 한다.
또한 각 Goroutine간의 스위칭시에 오버헤드도 적고, 병행 실행에 관한 최적화된 처리를 go runtime scheduler가 처리해준다고 한다.
go runtime에서는 세가지 C 구조체를 활용하여 go routine을 관리한다
G(goroutine)구조체: 단일 goroutine을 표현하는 구조체이다. goroutine에 필요한 스택, 상태정보, 담당하고 있는 코드의 레퍼런스를 담고있다.
M(machine)구조체: OS 쓰레드를 표현하는 구조체이다. global queue, local queue에 있는 실행 가능한 goroutine에 대한 포인터, 지금 실행하고 있는 고루틴에 대한 포인터, 스케쥴러의 cache와 reference를 담고 있다.
P(processor)구조체: 논리적인 프로세서를 표현하는 구조체이다.
기본적으로 cpu 코어 갯수로 할당되는데, runtime.GOMAXPROCS로 조절도 가능하다.
할당 수에 제한이 있기 때문에 고루틴이 많아도 그 갯수만큼 많은 쓰레드를 생성하지 않음
go scheduler는 두가지 큐를 활용하여 G를 스케쥴링한다
GRQ(global run queue): P에 할당되지 않은 G들을 저장
LRQ(local run queue): P에서 처리할 G들을 저장
각각의 P 구조체에는 LRQ가 하나씩 할당된다.
결국 G(goroutine)을 실행하기 위해선 G를 M,P에 할당해주어야한다.
하나의 G가 블락되면 P는 LRQ의 다른 G를 M에 할당한다.
만약 시스템 콜 등으로 P에 할당된 M 자체가 OS 기준으로 블락된 경우엔 P의 할당을 해제해버리고 쉬고있는 M을 P에 할당한다.
go의 라이브러리에서 일반적으로 system call로 처리되어 블로킹 당할만한 것들(소켓과 파일의 I/O처리, 타이머)은 OS에서 제공하는 기능들을 이용해 I/O 멀티플렉싱을 수행하기 때문에 사실 go 에서는 블락킹 자체가 많이 일어나지 않음 → 하나의 코어의 효율적인 쓰레딩 지원
P안에서 처리 우선순위는 다음과 같다
LRQ의 G → 다른 P의 LRQ의 G → GRQ의 G → network poll
No comments yet