database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
ㆍPostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
PostgreSQL Columns 5472 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 5472
PostgreSQL8.0.0 beta1 리눅스 VS 윈도우
작성자
신기배(nonun)
작성일
2004-08-14 17:54:52
조회수
14,238

간단하게 테스트 했습니다 -.-;

결과가 들쭉날쭉 하네여 ^^;;

 

ps. 윈도우는 fat32 입니다. 리눅스는 ext3 구요~

이 글에 대한 댓글이 총 7건 있습니다.

 

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

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

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

정재익(advance)님이 2004-08-15 00:29:13에 작성한 댓글입니다.

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

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

 

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

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

신기배(nonun)님이 2004-08-15 01:22:48에 작성한 댓글입니다.

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

 

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

 

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

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

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

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

 

김상기(ioseph)님이 2004-08-17 23:11:04에 작성한 댓글입니다.

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

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

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

 

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

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

 

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

최하림(opendraft)님이 2004-08-24 01:40:28에 작성한 댓글입니다.

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

 

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

 

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

 

김상기(ioseph)님이 2004-08-24 13:23:22에 작성한 댓글입니다.

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

 

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

 

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

가짜리눅서님이 2004-10-19 17:39:52에 작성한 댓글입니다.
이 댓글은 2004-10-20 15:21:38에 마지막으로 수정되었습니다. Edit

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

 

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

 

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

 

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

 

박성철(gyumee)님이 2004-12-27 11:51:44에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
8748PostgreSQL 9.0 리플리케이션 기능 사용기
김상기
2010-12-17
9417
7053나름대로 쓰는 PostgreSQL 약사 [1]
김상기
2007-02-21
12231
5953비정상적인 시스템 종료에 따른 postmaster의 반응 (7.1 이상에서)
김상기
2005-03-08
13047
5472PostgreSQL8.0.0 beta1 리눅스 VS 윈도우 [7]
신기배
2004-08-14
14238
5187PostgreSQL vs MySQL [6]
정재익
2004-02-04
48238
5139tsearch2 한국어 파서 사전 개발안 [8]
김상기
2004-01-04
14319
4939DSN 개발 뒷 이야기 [4]
김상기
2003-09-13
10541
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2019 DSN, All rights reserved.
작업시간: 0.094초, 이곳 서비스는
	PostgreSQL v11.5로 자료를 관리합니다