>Rahila, if you want to saturate the CPU and don't care about the > particular benchmark, try to use read-only transactions. Either just add > "-S" at the pgbench command line, or write something SELECT-only on your > own. Anyway, use '-j' in such cases. Thanks a lot for your suggestion. Using select only queries helped me lower % CPU time spent on IO. Also , increasing number of threads helped loading CPU around 87 to 90 %. -Rahila On Sat, Oct 26, 2013 at 7:53 PM, Tomas Vondra <tv@xxxxxxxx> wrote: > On 25.10.2013 19:04, Scott Marlowe wrote: >> On Fri, Oct 25, 2013 at 8:29 AM, Rahila Syed <rahilasyed90@xxxxxxxxx> wrote: >>> >>> Configurations of my machine is: >>> >>> Processors: Xeon E5-2650 Processor Kit >>> Intel® Xeon ® Processor E5-2650 (2 GHz, 8C/16T, >>> 20 MB) * 2 nos >>> >>> >>> RAM : 32GB DDR3-1600 REG Memory Kit >>> 8x 4GB Registered ECC DIMM, DDR3L-1600(PC3L-12800) >>> >>> HDD: 450GB 10K Hot Plug 2.5-inch SAS HDD * 8 nos >>> 1 x 450 GB SAS HDD, 2.5-inch, 6Gb/s >>> >>> Disk Speed : 10,000 RPM >>> >>> RAID Controller (512MB, RAID 0/1) >> >> My guess is that you're maxing out your IO subsystem long before >> you're maxing out CPU. What does >> >> iostat -xd 10 >> >> have to say about it? > > Right, that's my guess too. The problem is most likely the "sync" at the > end of the transaction. > > Rahila, if you want to saturate the CPU and don't care about the > particular benchmark, try to use read-only transactions. Either just add > "-S" at the pgbench command line, or write something SELECT-only on your > own. Anyway, use '-j' in such cases. > > Tomas > > > -- > Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
