Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

FreeBSD a wydajność Postgresa

1 view
Skip to first unread message

Asthma

unread,
Feb 19, 2007, 6:15:44 AM2/19/07
to
Witam i prosze o porade dotyczaca nastepujacej
sytuacji:

Posiadam dwie identyczne maszynki (serwerki HP,
p3 1ghz, 768ram, gdd 18gb scsi3). Na pierwszej maszynce
zainstalowalem Debiana 4.0, na drugiej FreeBSD 6.3.
Na obu maszynkach ma docelowo chodzic serwer Postgresa,
dlatego wrzucilem zrodla postgresa 8.2.3, skompilowalem
i odpalilem. Dla testu wrzucilem dane oraz skrypty
z testu benchw. Okazuje sie iz Linux jest dosc wyraznie
szybszy od FreeBSD np:

zapytanie:

benchw=# EXPLAIN ANALYZE
benchw-# SELECT
benchw-# d0.dyr,
benchw-# count(f.fval )
benchw-# FROM
benchw-# dim0 AS d0,
benchw-# fact0 AS f
benchw-# WHERE d0.d0key = f.d0key
benchw-# AND d0.dyr < 2010
benchw-# GROUP BY
benchw-# d0.dyr
benchw-# ;

na Linuksie daje taki wynik:
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------
HashAggregate (cost=394544.66..394545.50 rows=67 width=8) (actual
time=77465.099..77465.129 rows=10 loops=1)
-> Hash Join (cost=230.66..377879.66 rows=3333000 width=8) (actual
time=40.735..66947.972 rows=3360000 loops=1)
Hash Cond: (f.d0key = d0.d0key)
-> Seq Scan on fact0 f (cost=0.00..281819.00 rows=10000000
width=8) (actual time=7.400..29973.223 rows=10000000 loops=1)
-> Hash (cost=189.00..189.00 rows=3333 width=8) (actual
time=33.256..33.256 rows=3360 loops=1)
-> Seq Scan on dim0 d0 (cost=0.00..189.00 rows=3333
width=8) (actual time=3.727..24.133 rows=3360 loops=1)
Filter: (dyr < 2010)
Total runtime: 77490.936 ms

na BSD taki:

QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------
HashAggregate (cost=394544.66..394545.50 rows=67 width=8) (actual
time=93112.526..93112.559 rows=10 loops=1)
-> Hash Join (cost=230.66..377879.66 rows=3333000 width=8) (actual
time=46.765..81693.588 rows=3360000 loops=1)
Hash Cond: (f.d0key = d0.d0key)
-> Seq Scan on fact0 f (cost=0.00..281819.00 rows=10000000
width=8) (actual time=6.382..39697.129 rows=10000000 loops=1)
-> Hash (cost=189.00..189.00 rows=3333 width=8) (actual
time=40.209..40.209 rows=3360 loops=1)
-> Seq Scan on dim0 d0 (cost=0.00..189.00 rows=3333
width=8) (actual time=4.478..28.912 rows=3360 loops=1)
Filter: (dyr < 2010)
Total runtime: 93114.111 ms

Przekompilowywalem jadro bazujac na roznych tipsach na sieci, niestety
efektu wiekszego to nie odioslo. Podobnie zabawa z parametrami postgresa
:(

Pytanie zatem nasuwa sie samo, czy jest to naturalna rzecza?? Dziwi mnie
troche az taka roznica, czy da sie to jakos zminimalizowac?? Moze
problem jest z obsluga kontrolera scsi?? Prosty test przy pomocy dd
pokazuje przewage Linuxa.

dd if=/dev/zero of=plik_tm bs=1000 count=1000000

1000000000 bytes transferred in 26.218595 secs (38140869 bytes/sec) BSD
skopiowane 1000000000 bajtów (1,0 GB), 23,1753 sekund, 43,1 MB/s Linux

Jest jakies narzedzie do zmian parametrow pracy kontrolera ?

Troche mi rece opadaja, chcialem przejsc na BSD a tu walek ;//

Dzieki za wszelkie porady.
Pozdrawiam
J.

Asthma

unread,
Feb 19, 2007, 6:19:27 AM2/19/07
to
> dd if=/dev/zero of=plik_tm bs=1000 count=1000000
>
> 1000000000 bytes transferred in 26.218595 secs (38140869 bytes/sec) BSD
> skopiowane 1000000000 bajtów (1,0 GB), 23,1753 sekund, 43,1 MB/s Linux

No nawet lepiej mi sie udalo jeszcze:
skopiowane 1000000000 bajtów (1,0 GB), 21,0273 sekund, 47,6 MB/s

Jakub Wartak

unread,
Feb 20, 2007, 3:25:44 AM2/20/07
to
Asthma wrote:

> Troche mi rece opadaja, chcialem przejsc na BSD a tu walek ;//

A na jakich systemach plikow testowales ? Pamietaj ze standardowo np ext3
dziala jako async a UFS2 w FreeBSD jako noasync. Miales softupdates na
UFS2 ? Potestuj moze jeszcze z noatime ?

W ostatecznosci jesli bedziesz bardzo zdesperowany ( nie polecam ) zobacz
fsync=off w konfigu pgsqla.

dd nie nadaje sie do benchmarkowania, poszukaj bonie++

--
Jakub Wartak
http://vnull.pcnet.com.pl/
Ssij niecny niechciany listonoszu!: je...@pcnet.com.pl

asthma

unread,
Feb 20, 2007, 1:06:13 PM2/20/07
to
> Asthma wrote:
>
> > Troche mi rece opadaja, chcialem przejsc na BSD a tu walek ;//
>
> A na jakich systemach plikow testowales ? Pamietaj ze standardowo np ext3
> dziala jako async a UFS2 w FreeBSD jako noasync. Miales softupdates na
> UFS2 ? Potestuj moze jeszcze z noatime ?

Ok na Linuksie partycja postgresowa wisi na XFS dokladnie:
/dev/sda7 on /usr/local/pgsql type xfs (rw,noatime)

Na FreeBSD na UFS, dokladnie tak:
/dev/da0s1g on /usr/local/pgsql (ufs, local, noatime, soft-updates)



> W ostatecznosci jesli bedziesz bardzo zdesperowany ( nie polecam ) zobacz
> fsync=off w konfigu pgsqla.
>
> dd nie nadaje sie do benchmarkowania, poszukaj bonie++

Ok oto wyniki z bonnie, prosze mi je skomentowac ;))

Linux
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
jemina 1512M 16834 98 39846 28 21851 14 17606 91 44999 11 301.4 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 2135 35 +++++ +++ 3184 40 2201 38 +++++ +++ 851 14
jemina,1512M,16834,98,39846,28,21851,14,17606,91,44999,11,301.4,1,16,2135,35,+++++,+++,3184,40,2201,38,+++++,+++,851,14


FreeBSD
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
karenhappuch 1512M 35833 87 35289 23 13850 11 27784 80 36345 14 306.8 2
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 4187 21 29572 65 +++++ +++ 5256 24 +++++ +++ +++++ +++
karenhappuch,1512M,35833,87,35289,23,13850,11,27784,80,36345,14,306.8,2,16,4187,21,29572,65,+++++,+++,5256,24,+++++,+++,+++++,+++

A co jeszcze ciekawsze, stworzylem sobie w kazdej z baz jedna tabelke,
wypelnilem danymi, dokladnie 489868 wierszy. I teraz badam sobie i na
Linuksie:

select * from k_pracy;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------
Seq Scan on k_pracy (cost=0.00..7240.78 rows=489868 width=271) (actual
time=0.051..781.421 rows=489868 loops=1)
Total runtime: 1163.002 ms
(2 rows)

..i na FreeBSD
actual-# select * from k_pracy;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------
Seq Scan on k_pracy (cost=0.00..12705.68 rows=489868 width=271) (actual
time=1.016..1527.763 rows=489868 loops=1)
Total runtime: 2612.302 ms
(2 rows)

Noo i kapke na moje oko dziwacznie to wyglada :)) Parametry identyczne cosik
tu naprawde jest skopcone ;//

Pozdrawiam i dzieki za pomoc.
J.

--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

Jakub Wartak

unread,
Feb 21, 2007, 10:53:17 AM2/21/07
to
asthma wrote:

> Ok oto wyniki z bonnie, prosze mi je skomentowac ;))

Wystaw to jako HTML bo u mnie sie calkowicie rozjechalo...

> A co jeszcze ciekawsze, stworzylem sobie w kazdej z baz jedna tabelke,
> wypelnilem danymi, dokladnie 489868 wierszy. I teraz badam sobie i na
> Linuksie:

[..]

> Total runtime: 1163.002 ms
> (2 rows)
>
> ..i na FreeBSD

[..]

> Total runtime: 2612.302 ms
> (2 rows)
>

Mysle ze to kwestia tunningu PostgreSQLa i VM systemu - kompilowales tymi
samymi wersjami gcc?, jakie flagi np CFLAGS ? W linuxie masz jeszcze cos
jak drop_caches w /proc/sys/vm/ do zrobienia przed benchmarkami - bo
*wydaje* mi sie ze PostgreSQL bardzo mocno zalezy do VM OS'a. A calkiem
mozliwe ze faktycznie ten sterownik RAIDA pod Free nie daje rady...

Po tunning PostgreSQLa udaj sie na pl.comp.bazy-danych badz na listy
pgsql ;)

Pawel Jakub Dawidek

unread,
Mar 2, 2007, 6:28:20 PM3/2/07
to
Asthma <ast...@op.pl> wrote:
> Witam i prosze o porade dotyczaca nastepujacej
> sytuacji:
>
> Posiadam dwie identyczne maszynki (serwerki HP,
> p3 1ghz, 768ram, gdd 18gb scsi3). Na pierwszej maszynce
> zainstalowalem Debiana 4.0, na drugiej FreeBSD 6.3.
> Na obu maszynkach ma docelowo chodzic serwer Postgresa,
> dlatego wrzucilem zrodla postgresa 8.2.3, skompilowalem
> i odpalilem. Dla testu wrzucilem dane oraz skrypty
> z testu benchw. Okazuje sie iz Linux jest dosc wyraznie
> szybszy od FreeBSD np:
[...]

Z tego co wiem optymalizacja FreeBSD pod kątem PostgreSQLa trwa. Jedną z
ciekawych rzeczy, które możesz spróbować jest wyłączenie opcji
update_process_titles, która jest domyślnie włączona, pełni jedynie
informacyjną funkcję natomiast zwalnia działanie PostgreSQLa o ponad 30%
z tego co słyszałem. Nie wiem gdzie dokładnie można ją wyłączyć, musisz
poszukać.

Są oprócz tego jeszcze inne optymalizacje już samego FreeBSD, proponuję
byś śledził listy FreeBSD (cur...@FreeBSD.org i perfo...@FreeBSD.org).

--
Pawel Jakub Dawidek http://www.wheel.pl
p...@FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!

Dariusz Sznajder

unread,
Mar 3, 2007, 12:08:54 PM3/3/07
to
Dnia 02.03.2007 Pawel Jakub Dawidek <p...@FreeBSD.org> napisał/a:
> update_process_titles, która jest domyślnie włączona, pełni jedynie
> informacyjną funkcję natomiast zwalnia działanie PostgreSQLa o ponad 30%
> z tego co słyszałem. Nie wiem gdzie dokładnie można ją wyłączyć, musisz
> poszukać.
Ale to raczej nie będzie miało znaczenia dla pojedyńczej instancji i
trwającego minutę zapytania.

--
Dariusz Sznajder
DSZ1-RIPE

0 new messages