대량 쓰기 데이터베이스를 위해 Oracle Redo 로그를 DRAM SSD에 넣습니까?


9

쓰기가 많은 데이터베이스를 사용하여 EMC CX4-120 어레이에 Sun M4000을 연결했습니다. 약 1200 IO / s 및 12MB / s에서 피크를 기록합니다.

EMC에 따르면 EMC 스토리지에서 쓰기 캐시를 포화 상태로 만들고 있습니다.

가장 간단한 해결책은 리두 로그를 DRAM 기반 SSD로 옮기는 것입니다. 그러면 EMC 스토리지의 부하가 절반으로 줄어들고 앱은 로그 버퍼 대기를 보지 못합니다. 예, DBWR은 병목 현상이 발생할 수 있지만 앱은 다시 실행 커밋에서와 같이 기다리지 않습니다.

현재 약 4 개의 4GB 리두 로그를 순환하므로 20GB 정도의 SSD조차도 큰 차이를 만듭니다. 이것은 단기 스토리지이며 지속적으로 덮어 쓰기 때문에 플래시 기반 SSD는 좋은 생각이 아닙니다.

M4000에는 추가 드라이브 로트가 없으므로 PCI-E 카드가 완벽합니다. 외부로 이동하거나 부팅 볼륨을 EMC로 이동하여 로컬 드라이브를 비울 수 있습니다.

Sun은 Flash Accelerator F20 PCIe 카드를 판매하지만 이는 DRAM SSD 솔루션이 아닌 일부 SATA 디스크의 캐시 인 것 같습니다. 세부 사항은 개략적이며 M4000을 지원되는 것으로 나열하지 않았으며 Sun의 전화 트리와 인간의 도움을 구하는 데 지쳤습니다. :(

다른 사람들은 DRAM SSD가 나아갈 길에 동의합니까? 하드웨어 권장 사항이 있습니까?

업데이트 아래 주석의 정보 외에도 "commit_write"에 대한 다양한 설정을 시도했지만 차이가 없었습니다.


어딘가에 로그를 보관하고 있습니까? 궁극적으로 SSD에서 디스크로 복사해야하는 경우 병목 현상을 보관으로 옮길 수 있습니다.
Gary

예 ... 리두 로그가 아카이브되고 있으며 리두 로그 복사 중에 IO는 실제로 순차적 쓰기이므로 IO가 약 80MB / s로 증가합니다. 나는 항상 리두 로그가 순차적이라고 생각했지만 그렇지 않습니다.
rmeden

답변:


9

첫째-어레이에 디스크가 거의 없다고 생각합니다. 12 개의 회전 디스크로 1200IOPS를 쉽게 지원할 수 있습니다 (디스크 당 100 IOPS가 매우 합리적 임). 캐시가 캐시를 처리 할 수없는 경우 1200 IOPS의 지속적인 쓰기 속도가 디스크가 지원할 수있는 것보다 더 많은 것을 의미합니다.

어쨌든 리두 로그 용 SSD는 도움이되지 않습니다. 먼저, 세션이 주로 COMMIT 문에서 대기합니까? statspack / AWR에서 최상위 대기 이벤트를 확인하여 확인하십시오. I / O의 ~ 95 %가 리두 로그에 전혀 해당되지 않는 것 같습니다. 예를 들어, 인덱스가 5 개인 테이블에 대한 단일 행 삽입은 1 개의 I / O를 수행하여 테이블 블록 (행에 대한 공간이 있음)을 읽고 5 개의 인덱스 블록을 읽고 (갱신하기 위해) 1 개의 데이터 블록을 쓰고 1 개의 실행 취소를 수행 할 수 있습니다. 블록 및 5 개의 인덱스 블록 (또는 리프가 아닌 블록이 업데이트 된 경우 이상) 및 1 개의 리두 블록. 따라서 statspack을 확인하고 대기 이벤트를 확인하십시오. 데이터 / 인덱스를 위해 READ와 WRITE를 많이 기다리고있을 것입니다. 읽기를 기다리면 INSERT 속도가 느려지고 WRITE 활동으로 인해 읽기 속도가 느려집니다. 동일한 디스크입니다 (BTW-실제로 모든 인덱스가 필요합니까? 필요하지 않은 사용자를 삭제하면 삽입 속도가 빨라집니다).

확인해야 할 또 다른 사항은 RAID 정의입니다. RAID1 (미러링-각 쓰기는 2 개의 쓰기) 또는 RAID 5 (각 쓰기는 2 개의 읽기 및 체크섬 계산을위한 2 개의 쓰기)입니다. RAID 5는 쓰기 집약적 인로드 속도가 훨씬 느립니다.

BTW-디스크가 쓰기로드를 처리 할 수 ​​없으면 DBWR에 병목 현상이 발생합니다. SGA에는 더티 블록이 가득 차므로 DBWR이 더티 블록을 디스크에 쓸 수있을 때까지 새 블록 (예 : 처리 / 업데이트해야하는 인덱스 블록)을 읽을 공간이 없습니다. 다시 statspack / awr report / addm을 확인하여 일반적으로 상위 5 개의 대기 이벤트를 기반으로 병목 현상을 진단하십시오.


1
+1-가능하면 +10으로 줄 것입니다.
Helvick

2
병목 현상이 발생한 위치를 실제로 확인하기위한 +1
DCookie

대기는 "로그 파일 동기화"및 "로그 버퍼 공간"입니다. DD를 사용하여 볼륨에 약 150MB / s를 얻을 수 있습니다. LGWR이 다음을 제출하기 전에 IO가 완료되기를 기다리고있는 것 같습니다. IO 서비스 시간은 약 1ms입니다. EMC는 무려 500MB의 캐시를 보유하고 있으며 EMC에 따르면 전체 상자를 업그레이드하지 않고도 증가시킬 수 없습니다. 우리는 어레이에 22TB가 있는데 왜 캐시가 거의없는 것을 제공 할 수 있을까요? 재실행 로그는 현재 5 와이드 RAID 5에 있지만 RAID 10과는 차이가 없었습니다 (캐시를 의심하는 또 다른 이유)
rmeden

BTW, 캐시가 더 있으면 디스크가 계속 유지되지 않을 수 있습니다. EMC 어레이에서 REDO를 옮기면 데이터 디스크의 용량이 늘어나고 I / O가 절반으로 줄어 듭니다. 작은 DRAM SSD는 작을 수 있기 때문에 가장 저렴한 고성능 디스크 일 수 있습니다.
rmeden

meden-Oracle은 초당 얼마나 많은 리두를 작성합니까? 총 I / O가 12MB / s이고 1200 IOPS라고 말하면 많은 작은 IO (평균 10KB)를 의미합니다. 리두 로그를 SSD로 이동하면 DBWR이 병목 현상이되고 INSERT가 SGA에서 여유 버퍼를 기다릴 때 다른 대기 이벤트가 표시됩니다. 어떤 RAID 유형, 스트라이프 크기 및 Oracle 블록 크기 (데이터 파일이 모든 디스크에 스트라이핑되어 있는지)를 확인하십시오. 또한 statspack에서 대부분의 I / O에 대한 소스를 확인하십시오. 다시 실행하거나 다른 것이
있습니까?

2

dd는 블록 i / o와 비교할 것이 없습니다.

다른 관점에서 anandtech.com은 SAS 회전 대 SSD로 다양한 조합으로 exaustive 테스트 (MS SQL 서버와 함께 부여)를 수행했으며 Solaris 세계에는 다양한 부분 (로그, 캐시 등을 구성하는 SSD가있는 ZFS가 있음) ).

그러나 그렇습니다. RAID 5와 RAID 10이 같은 경우 (쓰기) 잘못된 일을하고있는 것입니다. 선형 쓰기를 사용하면 RAID 5가 더 빠를 수 있습니다 (즉, 메모리에서 패리티를 수행 한 다음 스트라이프와 패리티를 한 번에 모두 쓸 수 있음). 작은 작은 블록 (4-8k)을 사용하면 스트라이프를 업데이트하여 죽일 수 있습니다 레이드 10은 그렇지 않은 경우 무언가 잘못되어 2 배 이상 빨라야합니다.

하드웨어에 돈을 쓰려면 먼저 더 깊이 파고 들어야합니다.


2

"forcedirectio"옵션을 사용하고 Oracle 매개 변수 "filesystemio_options"를 "setall"로 설정하여 UFS 파티션을 마운트하는 것에 대한 게시물을 보았습니다.

나는 그것을 시도하고 Oracle 쓰기에서 4-5 배 개선을 보았습니다! 네!

주요 증상은 처리량은 낮지 만 디스크의 응답 시간은 우수했습니다. 이것은 어떤 사람들에게는 도움이되지만 다른 사람들에게는 도움이되지 않는 것 같습니다. 그것은 확실히 나를 위해 일을했다.

새 서버의 SSD를 고려할 수 있지만이 서버는 현재 제대로 실행되고 있습니다.

로버트


직접 I / O를 활성화하는 것이 아니라 비동기 I / O를 활성화하여 발생하는 속도 향상 일 가능성이 큽니다. Oracle에서 setall은 직접 + 비동기를 의미합니다.
kubanczyk

1

이 박스가 리눅스를 실행하는 x86 / 64 박스 였다면 FusionIO PCIe 드라이브 카드 중 하나를 기꺼이 추천했을 것입니다. 놀라 울 정도로 빠르며 SSD처럼 무거운 쓰기로 '죽지'않습니다. 불행히도 그들은 Sparc 또는 Solaris에서 지원되지 않습니다. 이에 대해 논의하기 위해 연락을 원할 수 있습니다.


1

F20e PCIe 카드는 Fusion I / O 기능과 유사합니다. 기본적으로 PCIe 연결 플래시 SSD입니다. 쓰기 작업량이 많으면 드라이브 기반의 가비지 수집을 통해 충분한 여유 블록을 유지하는 데 대해 걱정할 필요가 있으므로 SSD의 지우기 / 프로그램주기가 병목 현상이 될 수 있습니다. 플래시 기반 SSD에서 사용할 수있는 제한된 쓰기주기. 확실히 빠르지만이 직업에 가장 적합한 키트는 아닐 수도 있습니다.


tks 존. 나는 그것이 나를 위해 일할 것이라고 생각하지 않았다. 썬은 어쨌든 M4000에서도 지원하지 않습니다. :(
rmeden
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.