그러던중 현대의 컴파일러에선 XOR가 메모리를 사용하지 않지만 병렬처리에서의 문제로 성능이 떨어진다는 이야기를 들었다.
항상 자세한 설명과 함께 도움주시는 pr0gr4m 님.
느려지는게 맞다고 하셔서 궁금해서 돌려봤다.
import timeit
# temp 사용
def swap_temp():
a = 5
b = 10
temp = a
a = b
b = temp
return a, b
# XOR 사용
def swap_xor():
a = 5
b = 10
a ^= b
b ^= a
a ^= b
return a, b
# 성능 테스트
temp_time = timeit.timeit("swap_temp()", setup="from __main__ import swap_temp", number=1000000)
xor_time = timeit.timeit("swap_xor()", setup="from __main__ import swap_xor", number=1000000)
print(f"Using temp: {temp_time} seconds")
print(f"Using XOR: {xor_time} seconds")
코드를 여러번 실행해 봤고 결론을 얻었다.
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.04701741598546505 seconds
Using XOR: 0.06559245800599456 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.04990166565403342 seconds
Using XOR: 0.06569029204547405 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.04502225015312433 seconds
Using XOR: 0.0672295419499278 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.045115040615200996 seconds
Using XOR: 0.06622312497347593 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.044884291011840105 seconds
Using XOR: 0.06595424981787801 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.04486312484368682 seconds
Using XOR: 0.06613395782187581 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.04502458404749632 seconds
Using XOR: 0.06623658305034041 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.044890208169817924 seconds
Using XOR: 0.0665586250834167 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.045562250073999166 seconds
Using XOR: 0.06695195799693465 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.04477795818820596 seconds
Using XOR: 0.06620474997907877 seconds
topologyKey: kubernetes.io/zone maxSkew: 2는 하나의 호스트 즉 노드간 파드의 차이는 maxSkew: 2 를 초과할수 없다. topologyKey: topology.kubernetes.io/zone maxSkew: 5 zone 간 pod의 갯수는 maxSkew: 5 초과 할수 없으므로 하나의 zone에서만 pod가 스케줄링된다면 20개의 replicas 를 요청한다 해도 5개의 pod 만 스케줄링 된다.
AZ별로 제공하는 유형의 인스턴스 페일리가 달라서 특정 유형만 사용하려고 하면 프로비저닝 조건에 걸려서 스케줄링이 쉽지 않다.
karpenter 의 강력함은 테스트중에 확인할수 있는데, 42s 만에 Pod 가 Running 된다. 42초안에 Node도 프로비저닝 된다는 말이다.
2023-05-20T11:03:34.806Z ERROR controller.provisioner Could not schedule pod, incompatible with provisioner "default", no instance type satisfied resources {"cpu":"1","memory":"256M","pods":"1"} and requirements karpenter.k8s.aws/instance-category In [c m t], kubernetes.io/os In [linux], kubernetes.io/arch In [amd64], karpenter.sh/provisioner-name In [default], karpenter.sh/capacity-type In [on-demand], topology.kubernetes.io/zone In [ap-northeast-2a] {"commit": "d7e22b1-dirty", "pod": "default/host-spread-fbbf7c9d9-x4lfd"}
topologySpreadConstraints 옵션을 테스트하면서 느꼈는데, 여러 요인들로 잘 스케줄링하지 못한다.
두가지 조건에 의해서 pod는 모두다 스케줄링 되지 못하는데, 노드를 스케줄링하지 못해서 걸리기도 한다. 조건은 확실히 걸리긴한다.
다음과같이 노드가 a 3대 b 3대 c 1대 스케줄링 되면 모두 14개의 pod가 스케줄링된다. C zone때문에 두번째 조건에 걸리기 때문이다. 다양한 조건을 사용하면 이와 같이 균등하게 zone 에 스케줄링 하긴 어려운점이 있다. 적당히 조건을 걸어주면 잘 작동한다.
k get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
karpenter-5bffc6f5d8-p2pxh 1/1 Running 0 9d 192.168.12.183 fargate-ip-192-168-12-183.ap-northeast-2.compute.internal <none> <none>
karpenter-5bffc6f5d8-qgcwn 1/1 Running 0 9d 192.168.13.157 fargate-ip-192-168-13-157.ap-northeast-2.compute.internal <none> <none>
Karpenter는 버전에 따라 Pod내에 Container 가 2개인 경우가 있다. 이경우엔 컨트롤러와 웹훅용도의 컨테이너가 두개가 동작한다. 일정버전 이상에서만 Fargate에 프로비저닝 된다. 그냥 v0.27.3버전 이상쓰자.
