Re: vacuumdb not letting me connect to db

[Peter J. Holzer]

On 2021-02-06 12:54:11 -0600, Ron wrote:
> On 2/6/21 6:06 AM, Atul Kumar wrote:
> 
> Hi Gavan,
> 
> Thanks for providing the details, I need more clarification on this as how
> should I analyze that what should be ideal no. of connections should we 
> set
> to avoid IO overhead based on the available hardware resources.
> How to do this calculation ?
> 
> 
> 
> Run "iotop -o -u postgres", and then compare that with the total bandwidth
> available to the system.  If it's (even almost) saturated, then everything 
> else
> will be starved.
> 
> The "--jobs=" value should AT MOST be some *small* multiple of the number of
> CPUs (like 1x, 1.5x or maybe 2x if the core count is low, and nothing else is
> running on the system.

While this is generally good advice, Atul reported earlier in the thread
that CPU consumption is only 1 to 4 %. So the problem is clearly not
related to CPU usage, but very probably (as some have already noted) on
I/O. You could use a similar rule of thumb for disks ("a small multiple
of the number of disks") but with SSDs this might not be very accurate.

I think the only method to get to the optimal number of vacuums
that can be run in parallel is to determine it experimentally:
300 is clearly too high. So try 150, 75, 37, etc. For each number try to
do some other work - is the performance acceptable? If yes, note the
time until vacuum is finished. FInally among those where the performance
was acceptable choose the value which was fastest.

(Note: If you do this on the same database, subsequent runs will benefit
from work already done, so the take the results with a grain of salt).

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature

Re: Should pgAdmin 3 be saved?

[Gabriel Martin]

Thanks for the answer, Tom. It's nice to get an answer so quickly ;)

Following your advice, I will probably post something about this on
the "pgadmin-hackers" list, a sub-list of the project lists dedicated
to "pgAdmin development and patches." I'm just going to wait a little
bit before, in order to let people react here and to avoid being on
multiple mailing lists at the same time.

I'm crossing my fingers that someone competent perceives the interest
of not letting pgAdmin 3 die completely. It would be great to keep the
good old PgAdmin App Version (aka PgAdmin 3) functional in parallel to
the newer Hosted Web Version of PgAdmin (aka PgAdmin 4).

regards, gm

Le sam. 6 févr. 2021, à 14 h 26, Tom Lane  a écrit :
>
> Gabriel Martin  writes:
> > Do you think there's a possibility that people could fix pgAdmin 3, even if
> > it means making a fork or whatever?
>
> You'd probably be better advised to ask this on the pgadmin project lists.
>
> Certainly, anybody who cares to fork and maintain pgAdmin 3 could do so.
> It's a matter of finding people with the time, interest, and technical
> ability.
>
> regards, tom lane