페이스북 그룹의 최신 기사를 보던 중 IBM Developer works에서 'IBM[모집안내] 클라우드를 공부하고 알릴, IBM C:LOUDERs에 지원하세요!'라는 게시글을 보고 바로 주저없이 지원했습니다. 개인적으로 IBM클라우드에 개인적으로 관심이 많이 있었기 때문입니다. 회사에서 AWS만 하고 있던 터라 다른 클라우드를 배우면 재미있을것 같았고 모집 취지가 너무 마음에 들었기 때문입니다. 공부로 끝내는것이 아니라 그것을 발표를 하고 서로 공유를 하고 함께 성장한다는 그 취지가 너무 좋았습니다. 그러나 지원한다고 하여 아무나 할 수 있었던건 아니었습니다. 먼저 Introduction to Cloud(IBM Cloud Core)를 수강해야 했습니다. 무료강의이지만 클라우드 기초 과정으로서 개인적으로..
■ MySQL 성능 스키마와 InnoDB 통합 MySQL 성능 스키마 기능을 사용하여 특정 내부 InnoDB 작업을 프로파일링 할 수 있습니다. 이 유형의 튜닝은 주로 성능 병목 현상을 극복하기 위해 최적화 전략을 평가하는 전문 사용자를위한 것입니다. 또한 DBA는 용량 계획에 이 기능을 사용하여 일반적인 워크로드에 특정 CPU, RAM 및 디스크 스토리지 조합의 성능 병목 현상이 발생하는지 확인할 수 있습니다. 이 결과로 시스템 일부의 처리량이나 용량을 늘려 성능을 향상시킬 수 있는지 판단할 수 있는 근거가 됩니다. 이 기능을 사용하여 InnoDB 성능을 검사하려면 : + 일반적으로 성능 스키마 기능을 사용하는 방법에 익숙해야 합니다. 예를 들어, 계측기와 소비자를 활성화하는 방법과 performanc..
원글 : https://www.percona.com/blog/2020/03/26/sysbench-and-the-random-distribution-effect/ Sysbench and the Random Distribution Effect - Percona Database Performance Blog How to customize sysbench to extend its use, with one way being the proper tuning of the random IDs generation. www.percona.com Sysbench의 난수 생성에 대해 알아야 할 사항 Sysbench는 벤치마킹을 수행하는 데 잘 알려져 있고 널리 사용되는 도구입니다. Peter Zaitsev가 2000 년 초에..
네트워크 및 트래픽 전송량에 따른 저장단위에 대해 알아보겠습니다. ■ 네트워크 전송량 단위 트래픽 전송량 단위에 대해 알아보겠습니다. 네트워크는 bps란 단위를 쓰며 이 약자는 Bit Per Second입니다. 이것은 초당 얼마를 전송할 수 있는 지 나타내는 단위입니다. Kbps = Kilo bps = 1,000 bps MBPS = Mega bps = 1,000,000 bps GBPS = Giga bps = 1,000,000,000 bps 단위는 1,000단위로 오릅니다. ■ 스토리지 용량 단위 스토리지 용량에 대해 알아보겠습니다. 스토리지 용량은 보통 Byte라는 단위를 씁니다. 1Byte는 8bit로써 8개의 bit묶음입니다. KByte = Kilo Byte = 1,000 Byte MByte = Me..
■ SysBench 히스토리 및 아키텍처 sysbench는 2004 년 Peter Zaitsev에 의해 만들어졌고 곧 Alexey Kopytov가 개발을 인수했습니다. 버전 0.4.12에서 개발이 중단되었습니다. Alexey는 2016년에 다시 작업하기 시작했습니다. 곧 LUA 기반 스크립트를 사용하도록 OLTP 벤치 마크를 다시 작성하여 버전 0.5가 릴리스되었습니다. 그런 다음 2017 년에 SysBench 1.0이 릴리스되었습니다. 이것은 0.4.12 이전 버전과는 비교할 수 없을 정도로 훌륭하게 만들어졌습니다. 하드코딩된 스크립트 대신 LUA를 사용하여 벤치마크를 사용자가 원하는 방법으로 정의하여 테스트할 수 있습니다. 이것은 굉장히 유연하게 테스트 할 수 있는 방법을 제공합니다. SysBench..
■ InnoDB 데드록 교착 상태는 각 트랜잭션마다 다른 잠금이 있기 때문에 다른 트랜잭션을 진행할 수 없는 상황입니다. 두 트랜잭션 모두 자원이 사용 가능할 때까지 대기하므로 보유한 잠금을 서로 해제않아 발생합니다. 트랜잭션이 여러 테이블에서 행을 잠글때(UPDATE 또는 SELECT ... FOR UPDATE와 같은 SQL을 통해) 교착 상태가 발생할 수 있지만 반대 순서로 발생합니다. 교착 상태는 이러한 명령문이 인덱스 레코드 및 간격 범위를 잠그고 각 트랜잭션이 타이밍 문제로 인해 일부 잠금을 획득하지만 다른 잠금은 획득하지 않는 경우에도 발생할 수 있습니다. 교착 상태의 가능성을 줄이려면 LOCK TABLES문 대신 트랜잭션을 사용합니다. 데이터를 삽입하거나 업데이트하는 트랜잭션을 장기간 열어 ..
잠금상태에서 읽기, UPDATE 또는 DELETE는 일반적으로 SQL문 처리시 스캔되는 모든 인덱스 레코드에 대해 레코드 잠금을 설정합니다. 명령문에 행을 제외시킬 WHERE조건이 있는지 여부는 중요하지 않습니다. InnoDB는 정확한 WHERE조건을 기억하지 않지만 스캔된 인덱스 범위만 알고 있습니다. 잠금 장치는 일반적으로 레코드 바로 앞의 "GAP"에 삽입을 차단하는 Next-Key 잠금 장치입니다. 그러나 GAP 잠금을 명시적으로 비활성화하여 Next-Key 잠금을 사용하지 않을 수 있습니다. 트랜잭션 격리 수준은 설정된 잠금에 영향을 줄 수 있습니다. 검색에 보조 인덱스가 사용되고 설정될 인덱스 레코드 잠금이 배타적 일 경우 InnoDB는 해당 클러스터형 인덱스 레코드를 검색하여 잠금을 설정합니..