쓰기가 많은 데이터베이스를 사용하여 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”에 대한 다양한 설정을 시도했지만 차이가 없었습니다.
답변
첫째-어레이에 디스크가 거의 없다고 생각합니다. 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 개의 대기 이벤트를 기반으로 병목 현상을 진단하십시오.
답변
dd는 블록 i / o와 비교할 것이 없습니다.
다른 관점에서 anandtech.com은 SAS 회전 대 SSD로 다양한 조합으로 exaustive 테스트 (MS SQL 서버와 함께 부여)를 수행했으며 Solaris 세계에는 다양한 부분 (로그, 캐시 등을 구성하는 SSD가있는 ZFS가 있음) ).
그러나 그렇습니다. RAID 5와 RAID 10이 같은 경우 (쓰기) 잘못된 일을하고있는 것입니다. 선형 쓰기를 사용하면 RAID 5가 더 빠를 수 있습니다 (즉, 메모리에서 패리티를 수행 한 다음 스트라이프와 패리티를 한 번에 모두 쓸 수 있음). 작은 작은 블록 (4-8k)을 사용하면 스트라이프를 업데이트하여 죽일 수 있습니다 레이드 10은 그렇지 않은 경우 무언가 잘못되어 2 배 이상 빨라야합니다.
하드웨어에 돈을 쓰려면 먼저 더 깊이 파고 들어야합니다.
답변
“forcedirectio”옵션을 사용하고 Oracle 매개 변수 “filesystemio_options”를 “setall”로 설정하여 UFS 파티션을 마운트하는 것에 대한 게시물을 보았습니다.
나는 그것을 시도하고 Oracle 쓰기에서 4-5 배 개선을 보았습니다! 네!
주요 증상은 처리량은 낮지 만 디스크의 응답 시간은 우수했습니다. 이것은 어떤 사람들에게는 도움이되지만 다른 사람들에게는 도움이되지 않는 것 같습니다. 그것은 확실히 나를 위해 일을했다.
새 서버의 SSD를 고려할 수 있지만이 서버는 현재 제대로 실행되고 있습니다.
로버트
답변
이 박스가 리눅스를 실행하는 x86 / 64 박스 였다면 FusionIO PCIe 드라이브 카드 중 하나를 기꺼이 추천했을 것입니다. 놀라 울 정도로 빠르며 SSD처럼 무거운 쓰기로 ‘죽지’않습니다. 불행히도 그들은 Sparc 또는 Solaris에서 지원되지 않습니다. 이에 대해 논의하기 위해 연락을 원할 수 있습니다.
답변
F20e PCIe 카드는 Fusion I / O 기능과 유사합니다. 기본적으로 PCIe 연결 플래시 SSD입니다. 쓰기 작업량이 많으면 드라이브 기반의 가비지 수집을 통해 충분한 여유 블록을 유지하는 데 대해 걱정할 필요가 있으므로 SSD의 지우기 / 프로그램주기가 병목 현상이 될 수 있습니다. 플래시 기반 SSD에서 사용할 수있는 제한된 쓰기주기. 확실히 빠르지만이 직업에 가장 적합한 키트는 아닐 수도 있습니다.