Re: Finding bottleneck

Поиск
Список
Период
Сортировка
От Kari Lavikka
Тема Re: Finding bottleneck
Дата
Msg-id Pine.HPX.4.62.0508082020421.3361@purple.bdb.fi
обсуждение исходный текст
Ответ на Re: Finding bottleneck  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Finding bottleneck  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
On Mon, 8 Aug 2005, Tom Lane wrote:
> What that sounds like to me is a machine with inadequate disk I/O bandwidth.
> Your earlier comment that checkpoint drives the machine into the ground
> fits right into that theory, too.  You said there is "almost no IO-wait"
> but are you sure you are measuring that correctly?

Currently there's some iowait caused by "fragmentation" of the comment
table. Periodic clustering helps a lot.

Disk configurations looks something like this:
   sda: data (10 spindles, raid10)
   sdb: xlog & clog (2 spindles, raid1)
   sdc: os and other stuff

Usually iostat (2 second interval) says:
   avg-cpu:  %user   %nice    %sys %iowait   %idle
             32.38    0.00   12.88   11.62   43.12

   Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
   sda             202.00      1720.00         0.00       3440          0
   sdb             152.50         4.00      2724.00          8       5448
   sdc               0.00         0.00         0.00          0          0

And during checkpoint:
   avg-cpu:  %user   %nice    %sys %iowait   %idle
             31.25    0.00   14.75   54.00    0.00

   Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
   sda            3225.50      1562.00     35144.00       3124      70288
   sdb             104.50        10.00      2348.00         20       4696
   sdc               0.00         0.00         0.00          0          0

I think (insufficiency of) disk IO shouldn't cause those lingering queries
because dataset is rather small and it's continuously accessed. It should
fit into cache and stay there(?)

> 400 queries?  Are you launching 400 separate backends to do that?

Well yes. That's the common problem with php and persistent connections.

> Some sort of connection pooling seems like a good idea, if you don't
> have it in place already.

pg_pool for example? I'm planning to give it a try.

>             regards, tom lane


     |\__/|
     ( oo )    Kari Lavikka - tuner@bdb.fi - (050) 380 3808
__ooO(  )Ooo_______ _____ ___ _ _  _   _    _      _                  _
       ""


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

Предыдущее
От: Rhett Garber
Дата:
Сообщение: Re: Why hash join instead of nested loop?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Finding bottleneck