AIX Concurrent I/O for RDBMS - 2

출처  :  http://lazyboy.tistory.com/entry/AIX-Concurrent-IO-for-RDBMS-2


얼마전에 이 블로그에 AIX Concurrent I/O 에 대하여 글을 올렸던 적이 있다.

AIX Concurrent I/O for RDBMS


해당 Article 에 링크된 문서에서  Concurrent I/O 에 대해서 좋은 점만 설명하고 주의점이나
나쁜것에 대해서 전혀 설명이 없길래 간단한 웹서핑을 통해 찾아봤는데 ...
역시 write 할때 inode 에 대하여 lock 을 안잡는 건 큰 문제가 있다.

예를 들어  Thread A 가 "1111111" 을 write 하고, Thread B 가 "222222" 를 write 한다고 생각해보자.
일반적인 상황에서 Thread A 가 write 를 수행하는 즉시 inode lock 에 대해서 X lock 을 잡아버리기
때문에 Thread B는 대기한다. 그래서 어떤 경우라도 실제 file 에 write 되는 내용은 "111111222222 " 이거나
"222222111111" 이런 경우밖에 발생하지 않는다.  이 경우 write() 하는 단위의 atomicity 는 완벽하게 보장된다.

그러나 Concurrent I/O 의 상황은 좀 다르다. 위와 같은 상황에서 Thread A 와 Thread B 가 서로
중복되어 write 를 수행할 수 있다. 즉 이런 경우 "12121212"와 같은 형태로 write 될수 있다는 거다.
즉 write system call 에 대한 atomicity 를 보장할 수 없다. (이게 얼마나 심각한 문제인지 ...
느낌이 팍 올꺼로 보기에 부가적인 설명은 안하겠다. )

그래서 별도의 buffer 단위로 write를 할때 해당 write 의 atomicity를 보장하기 위해 Mutex 라던지
Semaphore 등을 잡아줘야할꺼라는 거다. 즉 별도의 동기화 메커니즘이 추가로 필요하기 때문에
현재 사용하는 Application 이 사용하는 partition option 을 바꾼다고 할때 꼭 확인해야 할 부분이다.

아마도 그래서 제목에 for RDBMS 라는 부분을 넣은 것 같은데,  RDBMS 는 이러한 동기화메커니즘이
치밀하게 짜여져있는 Software 이다. 그러니 RBMS 에서 사용하는 파일 시스템에 대해 Concurrent I/O 를
반영하는 것은 그리 문제 되지 않는다. 그런데 여러분의 Application 에서 Concurrent I/O 를  사용한다면
꼭 고려해야 할 부분중에 하나다.

그럼 어차피 Mutex 에서 기다리나, inode에서 기다리나 똑같이 기다리는데 왜 Concurrent I/O 라는
기술이 나왔을까. 아마도 inode에서 기다리는 비용이 Mutex 잡는 것보다 비용이 더 커서 그렇게 한것
같은데, 여기에 대한 실제 테스트 비교는 찾을 수가 없었다. 간단하게 테스트해볼 수 있을 것 같은데
확인이 필요한 부분중에 하나이다.