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?
|
Список | 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 по дате отправления: