Re: High CPU Utilization

Here is vmstat 1 30.  We are under peak load right now so I can gather
information from the real deal :)

Had an almost complete lockup a moment ago, number of non-idle
postgres connections was 637.  Going to drop our JDBC pool sizes a bit
and bounce everything.

procs -----------memory---------- ---swap-- -----io---- -system-- ----
cpu----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy
id wa
12 35  95056 11102380  56856 14954948    3    4   669   541    1    2
23  3 54 19
12 39  95056 11092484  56876 14963204    0    0  6740  1204 10066
13277 91  5  0  4
8 42  95056 11081712  56888 14972244    0    0  8620  1168 10659 17020
78  6  0 15
10 30  95052 11069768  56904 14982628    0    0  8944   976 9809 15109
81  6  1 12
4 27  95048 11059576  56916 14991296    0    0  8852   440 7652 13294
63  4  2 32
5 42  95048 11052524  56932 14996496    0    0  4700   384 6383 11249
64  4  4 28
5 33  95048 11047492  56956 15001428    0    0  3852   572 6029 14010
36  4  5 56
7 35  95048 11041184  56960 15005480    0    0  3964   136 5042 10802
40  3  1 56
1 33  95048 11037988  56968 15009240    0    0  3892   168 3384 6479
26  1  3 69
3 28  95048 11029332  56980 15015744    0    0  6724   152 4964 12844
11  2  8 79
0 34  95048 11025880  56988 15020168    0    0  3852   160 3616 8614
11  1  6 82
3 25  95048 10996356  57044 15044796    0    0  7892   456 3126 7115
4  3  8 85
1 26  95048 10991692  57052 15050100    0    0  5188   176 2566 5976
3  2 12 83
0 29  95048 10985408  57060 15054968    0    0  4200    80 2586 6582
4  1 12 83
1 29  95048 10980828  57064 15058992    0    0  4560    64 2966 7557
7  2  6 85
2 28  95048 10977192  57072 15063176    0    0  3860    72 2695 6742
11  1  7 81
2 29  95048 10969120  57088 15067808    0    0  5084    84 3296 8067
14  1  0 84
0 25  95048 10962096  57104 15072984    0    0  4440   500 2721 6263
12  1  6 80
0 23  95044 10955320  57108 15079260    0    0  5712   232 2678 5990
6  1  6 87
2 25  95044 10948644  57120 15084524    0    0  5120   184 3499 8143
20  3  9 69
3 21  95044 10939744  57128 15090644    0    0  5756   264 4724 10272
32  3  5 60
1 19  95040 10933196  57144 15095024   12    0  4440   180 2585 5244
13  2 15 70
0 21  95040 10927596  57148 15098684    0    0  3248   136 2973 7292
8  1  9 81
1 20  95040 10920708  57164 15104244    0    0  5192   360 1865 4547
3  1  9 87
1 24  95040 10914552  57172 15105856    0    0  2308    16 1948 4450
6  1  1 93
0 24  95036 10909148  57176 15110240    0    0  3824   152 1330 2632
3  1  6 90
1 21  95036 10900628  57192 15116332    0    0  5680   180 1898 3986
4  1 11 84
0 19  95036 10888356  57200 15121736    0    0  5952   120 2252 3991
12  1  8 79
2 22  95036 10874336  57204 15128252    0    0  6320   112 2831 6755
5  2  8 85
3 26  95036 10857592  57220 15134020    0    0  5124   216 3067 5296
32  6  3 59

Alan, my apologies if you get this twice.  Didn't reply back to the
list on first try.

On Mar 16, 2009, at 3:52 PM, Alan Hodgson wrote:

> On Monday 16 March 2009, Joe Uhl <joeuhl@gmail.com> wrote:
>> Right now (not under peak load) this server is running at 68% CPU
>> utilization and its SATA raid 10 is doing about 2MB/s writes and
>> 11MB/
>> s reads.  When I run dd I can hit 200+MB/s writes and 230+ MB/s
>> reads,
>> so we are barely using the available IO.  Further when I run dd the
>> CPU utilization of that process only approaches 20%-30% of one core.
>
> What does vmstat say when it's slow? The output of "vmstat 1 30"
> would be
> informative.
>
> note: dd is sequential I/O. Normal database usage is random I/O.
>
> --
> Even a sixth-grader can figure out that you can’t borrow money to
> pay off
> your debt
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org
> )
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance