Re: 7.2 is slow?

Поиск
Список
Период
Сортировка
От Jussi Mikkola
Тема Re: 7.2 is slow?
Дата
Msg-id 3C207332.28B28249@bonware.com
обсуждение исходный текст
Ответ на Re: 7.2 is slow?  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
Ответы Re: 7.2 is slow?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
I haven't tested with the new 7.2 betas, but here are some results from <br />7.1. <p>We have a developement computer,
IBMx series 250, with 4 processors <br />(PIII Xeon 750Mhz), 1 Gb memory and  2SCSI disks (u160). <p>The software is
writingnew rows to a table, and after this it reads the <br />id from that row. There are currently about 50
connectionsdoing the <br />same thing. <p>When I run this test with the Redhat 7.1, with SMP kernel, I noticed, that
the<br />processors are more than 90% idle. Disks utilisation is not the <br />bottleneck either, since there is very
lowdisk usage. Some data is <br />written to disks every 4-5 seconds. Fsync is turned of. In transactions, <br />this
meansabout 200 inserted rows per second. The software that is used <br />to give the feed, is capable of several
thousandrows per second. <p>Okey, so I tried this also with the same computer, but using the not SMP <br />supported
kernel.So only with one processor. The result was about 600 <br />rows per second. The configuration file was
unchanged.Now, the <br />processor is about 100% utilized. <p>I didn't find any parameters that should help in this,
butif you have a <br />version of 7.2 that you would like to get information about, let me <br />know, so I'll test.
<p>Jussi<p>Zeugswetter Andreas SB SD wrote: <blockquote type="CITE">> I think you are right that the difference
between7.1 and 7.2 may have <br />> more to do with the change in VACUUM strategy than anything else.  Could <br
/>>you retry the test after changing all the "vacuum" commands in pgbench.c <br />> to "vacuum full"? <p>Might
therealso be a difference in chosen query plans ? <br />Wasn't 7.1 more willing to choose an index over seq scan, <br
/>eventhough the scan would be faster in the single user case ? <br />Or was that change after 7.0 ? <p>The seq scan
wouldbe slower that the index in the case of <br />many concurrent accesses. <p>Andreas
<p>---------------------------(endof broadcast)--------------------------- <br />TIP 4: Don't 'kill -9' the
postmaster</blockquote><pre>-- 
Jussi Mikkola                    Project Manager
Bonware Oy                       gsm +358 40 830 7561
Tekniikantie 12                  tel +358 9 2517 5570
02150 Espoo                      fax +358 9 2517 5571 
Finland                          www.bonware.com</pre>  

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Kalchev
Дата:
Сообщение: Re: Thoughts on the location of configuration files, how
Следующее
От: "Zeugswetter Andreas SB SD"
Дата:
Сообщение: Re: Thoughts on the location of configuration files, how about this: