I'm pretty sure that a postgresql server running with so low memory
27484 pgsql 1 4 0 54668K 37488K sbwait 0 1:20 0.00% postgres
could give a suffisant throughput.
54MB tend to indicate a default deb/rpm installation value which are very low.
During the process you can get the query running, with tools console or pgadmin.
And you can copy and retry it directly against the postgres server, and have
measure of how much time
it would take.
I think you need to tweak a bit the postgresql config.
Infos are present in list-archive & wiki & related postgres websites.
mehma sarja wrote:
>> Did you wait till the cpu went back to low cpu usage?
>
> No, it stays high overnight and my patience runs out before cpu pegging
> does.
>
>
>> Depending on
>> your configuration and optimization of your database this could take
>> anywhere from a few minutes to a few hours to finish.
>>
>> I assume the disk / array is thrashing during this time?
>>
>> John
>>
> There is no disk activity - zip. I do see load averages: 0.99, 0.97, 0.92
> CPU: 24.8% user, 0.0% nice, 0.0% system, 0.1% interrupt, 75.1% idle
> Mem: 1650M Active, 1544M Inact, 832M Wired, 226M Cache, 214M Buf, 3647M Free
> Swap: 4096M Total, 252K Used, 4096M Free
>
> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
> 27410 bacula 4 118 0 1607M 1589M CPU1 1 101:59 100.00%
> bacula-dir
> 27484 pgsql 1 4 0 54668K 37488K sbwait 0 1:20 0.00% postgres
>
>
> Another interesting thing is that it is doing involuntary context switching
> like so:
> PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND
> 27410 bacula 0 32 0 0 0 0 0.00% bacula-dir
> 27484 pgsql 0 0 0 0 0 0 0.00% postgres
>
>
>
> ------------------------------------------------------------------------
>
--
Bruno Friedmann
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
