TPC-B 만 보면 transaction 수가 많아 지면 윈도우가 나아진다는 결론인가요 ^^;

SELECT 를 보면 리눅스가 확실히 나아 보이는데...

그리고 SELECT transaction 100 정도에서 퍼포먼스 떨어지는 건 의의가 있는 건가요. ^^;

솔직히 말하면 이게 정상적인 테스트가 아닙니다 ㅋㅋㅋ

100 트랜젝션에서 처리수가 떨어지는건 아마도 콘넥션이 갑자기 10개로 늘어나면서 그부분에서 오버헤드가 생긴게 아닐까 합니다 -.-;

그리고 리눅스에서 테스트 할때는 쉘스크립으로 쉬지않고 위의 테스트를 한큐에 처리했다는.. -_-;; 귀차니즘 때문에 ㅡㅡㅋ

다음에 기회가 나면 다시 좀 세밀하게 테스트 해보겠습니다 -.-;

그날 기배님이랑 같이 저도 사무실에서 테스트를 해 보았는데, 개인적인 결론이 이것은 OS의 차이로 밖에 볼 수 없다는 생각이 들더군요.

즉, 다시 말해서, PostgreSQL 쪽에서 할 수 있는 것은 다 한 것 같습디다.

커넥션이 느린 것은 커널이 자식 프로세스를 만들어내는 것이 느린 것이고,

인덱스 파일을 검색하는 속도가 느린 것은 그 인덱파을 억세스하는 OS의 파일시스템 자체가 느린 것이고,

tcp 쪽을 통한 패킷 움직이는게 느린것은 os의 tcp/ip쪽이 느린것이고 ....

이런 RDBMS 쪽의 문제가 아닌, OS쪽의 문제로 밖에 볼 수 없을 것 같습디다.

네이티브 윈도우 지원이라고 해서 기대를 하고 설치 실행 해 봤는데

api만 네이티브 api를 사용했을 뿐 네이티브 스레드는 아니더군요.

네이티브란 말에 착각을...--;

윈도우 os의 특성상 fork process는 제대로 된 서비스를 하기 힘듭니다.

향후에 네이티브 스레드 지원 계획이 있는진 모르지만 지금은 이론공부에만 사용하고 윈도에서의 실무 적용은 조금 더 기다려야 할 것 같네요.

원 소스에서 분기한 일본쪽이나 다른 사용은 네이티브 스레드 버전인것 같던데, 언제쯤 코어에서 지원 할려나....

native thread 포팅이 되려면, 먼저 유닉스 쪽에서 그것을 지원해야할 듯싶습니다.

유닉스 쪽에서 fork 방식의 프로세스 만들기가 아닌, 쓰레드 만들기를 지원하면, 여기서 아마 win32 쪽도 native thread 포팅을 시도해 볼 듯 싶네요.

문제는 당분간은 유닉스 쪽에서 그냥 fork 방식의 하위 프로세스를 만들듯 싶네요. 쉽게 바뀌지는 않을 듯 싶습니다.

저야 워낙 초보여서 잘 알지 못합니다만 혹시 ext3의 저널링 때문에 나타난 결과가 아닐까요 ?

FAT는 저널링이란 개념자체가 없으니 뭐 가타부타 얘기꺼리도 없고 ext3는 저널링을 하다보면 아무래도 데이터 억세스 속도가 떨어지지 않을까 싶습니다.

물론 저널링을 Off하면 속도 향상을 기대할 수 있겠지요. 소문에는 ext3 저널링을 Off하면 RaserFS이상의 속도가 나온다고 하던데 사실유무는 확인한 바 없읍니다.

pgsql benchmark 사이트를 하나 만들면 어떨까요?

povray라고 오래된 오픈소스 3D raytrace rendering S/W가 있는데 povray에 번들되어 있는 benmark.pov 파일을 자신의 시스템에서 랜더링한 시간을 이곳에 올리면 순위를 매겨줍니다.

http://www.haveland.com/index.htm?povbench/index.php

pgsql이 어느 정도의 사양에서 어떤 성능이 날지 궁금해 하는 경우가 있는데 각자의 컴퓨터 사양과 postgresql.conf 파일을 pgbench의 실행 결과와 함께 올리면 이에 따른 순위를 보여주는 서비스가 있으면 많은 참고가 될 것 같네요.