Vertica의 이 일들 (15) - Vertica 오류 보고TM
java.sql.SQLException: [Vertica][VJDBC](5065) ERROR: Too many ROS containers exist for the following projections:
(limit = 18078, ROS files = 12088, DV files = 5992, new files = 10)
문제가 생기면 Vertica의 저장 메커니즘을 말하지 않을 수 없습니다.Vertica는 기본적으로 새로 쓴 데이터를 WOS(쓰기 최적화)에 쓴 다음에 일정한 조건(예를 들어 일정한 시간 주기)에 따라 WOS의 데이터를 ROS(읽기 최적화)에 쓴다. 이때 ROS는 매우 작은 데이터 블록의 조각이 많을 수 있다. 이것은 Vertica가 일정한 시간 주기 후에 이 ROS 블록을 큰 ROS 파일로 통합하는 것이다.여기서 데이터를 WOS에서 ROS에 쓰는 과정인 Vertica관은 MoveOut 조작이라고 하고, 흩어진 ROS를 큰 ROS로 합치는 과정인 Vertica관은 MergeOut 조작이라고 한다.
자, 이제 우리 문제를 봅시다.오류는 로스가 너무 많다는 것이다. 그럴 수 있는 이유는:
그래, 내 어플 좀 보자.
1 SELECT GET_CONFIG_PARAMETER('MoveOutInterval');
2 SELECT GET_CONFIG_PARAMETER('MergeOutInterval');
우리의 응용 프로그램 자체에 많은 ROS 조각이 생기기 때문에 우리는 MoveOut과 MergeOut의 Interval을 줄여서 Vertica가 가능한 한 빨리 MoveOut과 MergeOut을 할 수 있는지 생각했다.그래서 Vertica 매개변수를 수정했습니다.
1 SELECT SET_CONFIG_PARAMETER('MoveOutInterval', 60);
2 SELECT SET_CONFIG_PARAMETER('MergeOutInterval', 30);
이 두 개의 매개 변수를 수정한 후, 우리의 응용은 확실히 오랫동안 운행한 후에 다시는 위의 문제가 발생하지 않았다.사실 이 문제에 관해서는 조절할 수 있는 몇 가지 파라미터가 있다. 구체적인 자료는 Vertica Tuple Mover Parameters를 참고할 수 있다
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
다양한 언어의 JSONJSON은 Javascript 표기법을 사용하여 데이터 구조를 레이아웃하는 데이터 형식입니다. 그러나 Javascript가 코드에서 이러한 구조를 나타낼 수 있는 유일한 언어는 아닙니다. 저는 일반적으로 '객체'{}...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
