전체 글
-
쓰루풋 (MB/s)이 높으면 성능이 좋은 것일까?성능, 오해와 진실 2021. 1. 6. 23:07
스토리지 성능 경쟁 시 네트워크 쓰루풋 (MB/s)의 결과로만 우열을 가리는 경우가 있는데, 이것은 완전히 옳다고 보긴 어렵다. 왜냐하면, 동일 MBPS (Megabytes per Second)에서도 응답 시간이 낮은 시스템이 더 빨리 작업을 완료할 수 있기 때문이다. 즉, MB/s가 높다고 반드시 성능이 더 좋다고 말할 수 없으며, 성능은 단위 시간당 처리량 (IOPS)이 높아야 하는 것이다. 예를 들면, 백엔드 대역폭이 클 경우 (6Gb/s vs. 12Gb/s), 큰 블록 사이즈로 Sequential I/O 부하를 주면 쓰루풋 (MB/s)은 얼마든지 크게 뽑아낼 수 있다. 그렇다고 IOPS가 2배 차이 나는 것은 아니다. 또한 12Gb/s 제품의 성능이 더 높다는 보장이 없다. 오히려, 6Gb/s의 ..
-
스토리지 포트 수와 성능의 관계스토리지 지식 2021. 1. 5. 23:19
스토리지 포트 (Port) 수가 많으면 성능이 좋다고 생각하는 경우가 있다. 사실, 이런 이야기를 처음 접했을 때 어이없긴 했으나, 많은 엔지니어들이 포트 수량이 많으면 좋은 것으로 당연시하기도 하고, 또 고객의 요구가 심심치 않게 있다 보니 거부감 없이 받아들이는 것을 알게 되었다. (그 외, 특별한 이유는 찾아볼 수 없었다.) 결론부터 말하자면, 포트 수량이 많다고 성능이 좋아지는 것은 아니다. 포트별 성능은 전체 성능에서 나눠 쓸 뿐이다. 바꿔 말해, 포트 수량의 증가가 전체 대역폭 이상의 성능을 발휘할 수 없다. Front-end Port 수량보다는 전체 Port의 대역폭이 관건이다. 차선 (변기)이 많다고 해도 분기점에 이르러 좁아지면 최종 성능은 분기점 기준으로 귀결되기 때문이다. 세상은 이미..
-
Throughput (쓰루풋) 오해와 진실성능, 오해와 진실 2021. 1. 4. 22:02
"Throughput = MB/s" 로만 알고 있는 사람들이 많다. 또한, 성능 비교 시 MB/s만 보며, 이 수치로 성능의 우위를 판단하는 이들도 많다. 심지어, IOPS는 Throughput이 아닌 것으로 생각하는 경우도 흔하다. 아마도 MB/s가 가장 이해하기 쉽고 익숙하기 때문이리라. 엄밀히 말하면, 해당 제품이 제공하는 대역폭을 충분히 확인했다면 MB/s는 크게 신경 쓰지 않아도 되는 지표이다. 물론, Throughput이 MB/s이라는 사실이 틀린 것은 아니다. 쓰루풋은 우리말로 처리량이고, BPS (Bytes per Second)는 데이터 전송률을 나타내는 단위이므로, 초당 처리한 바이트의 양인 B/s, KB/s, MB/s는 쓰루풋이 맞다. 그런데, 이 쓰루풋을 MBPS (MB/sec)의 개..
-
System Hang과 Panic의 차이성능, 오해와 진실 2021. 1. 3. 18:25
System Hang이라는 용어가 무분별하게 사용되는 경우가 많아 정리해본다. Hang 커널 스스로 문제를 인식하지 못하여 시스템이 정지된 상태 원인 분석이 어려움 강제 Panic 가능 Panic 커널 프로그램 중 하나, panic() 중대 결함 발생 시 시스템 자동 Reset (Dump 수행) 문제 발생 시 Panic이 일어나지 않는 경우 대부분 Hang이 됨 다음 사이트의 내용을 인용, 정리함 (cafe.naver.com/osschool/16) 컴퓨터에 문제가 생겼을 때, 스스로 복구할 수 있는 방법이 있다면 얼마나 좋을까? 마치, 사람 몸에 상처가 생겼을 때, 자연스레 아무는 것처럼.. 스스로 복구하는 이 기능은 이미 예전부터 사용하고 있던 것인데, 바로 패닉 (Panic)이다. 1. panic 패..
-
프로세스와 데몬의 차이성능, 오해와 진실 2021. 1. 2. 22:15
프로세스 (Process)와 데몬 (Daemon)을 구분 없이 사용하는 사례가 많기에 정확한 이해를 돕고자 정리해본다. Process 프로그램의 실행 상태 실행 및 종료를 자유롭게 수행 Daemon 항상 수행되고 있는 프로세스 사용자가 직접 제어하지 않고 백그라운드에서 수행 주로, 시스템 스타트업 시 자동으로 기동되는 프로세스를 지칭 inetd, syslogd, crond, httpd ... 프로세스와 데몬, 둘 다 프로세스이나, 데몬은 특별히 다르게 불린다. 먼저, 프로세스를 살펴보면, 디스크에 저장되어 있는 notepad.exe는 프로그램이다. 이것을 실행시키면 notepad.exe는 메모리로 올라간다. 주거지 이동이 일어난다. 이렇게 CPU가 프로그램에 생명을 불어넣어 메모리로 이동시켜 별도의 실행..
-
응답속도와 응답시간성능, 오해와 진실 2021. 1. 1. 21:33
많은 사람들이 성능에 대해, "응답속도가 빠르다" 또는 "응답속도가 느리다"로 말한다. 그러면서, 단위는 ms (밀리 세컨드), us (마이크로 세컨드)로 표현한다. 즉, '초'로 쓰고 '속도'라 읽는다. 흔히 범하는 오용 사례는 다음과 같다. 응답속도가 커져서 성능이 저하됨 응답시간 저하, 사용자 불만 증가 < 1ms 응답속도 속도는 크면 빠른 것이므로 성능도 높아져야 맞고, 응답시간은 작으면 성능이 좋은 것이므로 사용자 불만은 줄어들게 된다. 또, 시간의 단위를 사용하면서 속도라고 하면 서로 배치된다. 수많은 산출물과 글에서 응답시간 대신 응답속도란 용어가 너무나도 흔하게 사용되고, 심지어 전문가라고 하는 사람들도 (성능 전문업체의 매뉴얼에도), 하나의 글에서 (문서에서), 응답속도와 응답시간을 섞어..
-
하드웨어 (CPU) 증설 후 스토리지 성능 저하성능 이슈 2020. 12. 31. 23:51
이번 사례는 DB서버 CPU 증설 및 볼륨 작업 후 스토리지가 느려졌다는 고객 불만에 대해 원인 분석 및 진단한 결과를 공유한다. 사전 작업 AP 및 DB 서버 CPU 및 Memory 증설 AP : 28 → 32 core DB : 48 → 64 core Oracle용 Volume resize 현상 (고객 의견) 스토리지 볼륨 사이즈 증가 후 write latency 약 2배 증가 (5 → 9.5ms) 피크 타임 시, DB의 log file sync 평균 대기시간 약 30% 증가 (2.97 → 3.92ms) 원인 분석 서버/볼륨 작업 전후의 AWR을 제공받아 분석함 9/15 : CPU, Mem 증설 전 9/23 : CPU, Mem 증설 후 9/24 : 볼륨 사이즈 증가 후 일일 평균 및 일 피크 타임 시 ..
-
가용성 다운타임 계산법 (e.g. 6x9s)스토리지 지식 2020. 12. 30. 23:46
시스템의 Availability는 연간 Down time이 0인 100%를 기준으로, 이에 근접하는 수치를 9의 갯수로 표시함으로써 해당 시스템의 안정성을 나타낸다. 6x9s 다운타임 계산법 365 * (100% - 99.9999%) = 0.000365 days 0.000365 * 24 = 0.00876 hours 0.000365 * 24 * 60 = 0.5256 minutes 0.000365 * 24 * 60 * 60 = 31.536 seconds 가용성 수치별 연간 다운타임을 정리한 표를 참조한다.