Re: Reason for PG being seemingly I/O bound?
От | Harshad RJ |
---|---|
Тема | Re: Reason for PG being seemingly I/O bound? |
Дата | |
Msg-id | 5f2b35a60909132134q2380717dna6043ce6f81d39a2@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Reason for PG being seemingly I/O bound? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-novice |
On Mon, Sep 14, 2009 at 12:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
No, I hadn't confirmed; I was just guessing, because I thought the CPU utilisation was low. It turns out I was wrong in measuring the CPU utilisation (forgot about system utilisation); and vmstat confirms that there isn't any block i/o happening.
(PS. That's an incredibly useful command. Thanks! I was using 'grep' on /proc/vmstat and it was cumbersome)
I hadn't noted down the system utilisation (sorry). My net CPU utilisation (user + system) is about 50%, but it's a dual core system, so it is not all that bad.
The CPU utilisation on my production server is lower, but I will test/research further before asking questions here.
Harshad <harshad.rj@gmail.com> writes:
Did you watch "vmstat 1" or something
similar to confirm that a lot of I/O is really happening?
No, I hadn't confirmed; I was just guessing, because I thought the CPU utilisation was low. It turns out I was wrong in measuring the CPU utilisation (forgot about system utilisation); and vmstat confirms that there isn't any block i/o happening.
(PS. That's an incredibly useful command. Thanks! I was using 'grep' on /proc/vmstat and it was cumbersome)
However I still don't see how it would be I/O bound; the kernel
certainly ought to have everything needed in disk cache after a couple
of cycles. On my machine a similar test immediately pins the CPU
with about half user, half system time.
I hadn't noted down the system utilisation (sorry). My net CPU utilisation (user + system) is about 50%, but it's a dual core system, so it is not all that bad.
The CPU utilisation on my production server is lower, but I will test/research further before asking questions here.
thanks & sorry for the false alarm,
--
Harshad RJ
В списке pgsql-novice по дате отправления: