Tom Lane wrote:
> Gregory Stark <stark@enterprisedb.com> writes:
>
>> This is a tangent but are these actual Postgres processes? What's the logic
>> behind trying to run a 1,000 processes on a box with 16 cpus?
>>
>
> We should certainly be careful about trying to eliminate contention in
> this scenario at the cost of making things slower in more normal cases,
> but it seems interesting to stress the system just to see what happens.
>
>
>> Was this with your patch to raise the size of the clog lru?
>>
>
> That's an important question.
>
>
>> What is MaxBackends actually set to for the runs.
>>
>
> That I think is not. I'm fairly sure there are no performance-relevant
> paths in which cost is driven by MaxBackends rather than the actual
> current number of live backends. Certainly nothing in or around the
> ProcArray would act that way.
>
>
> regards, tom lane
>
I guess I was not clear.. It was PostgreSQL 8.3.0 (with no source code
change)
I had compiled it 64-bit with DTRACE enabled.
max-backend was set to 1500 But I dont think that causes any thing to
work slow. But yes the connections are "pre-opened" in the sense when
500 users are actively doing work there are about 1006 postgresql
processes running.
Yes I think I am taking the database to the extreme. But generally there
is some THINK time of 50ms involved so there are time slices available
for other users. Yes Commercial DB can also do pretty well on such
systems so its not unrealistic to expect that PostgreSQL cannot perform
here.
The old idea of stress testing it is to prove that it can go beyond
these 16cores infact our target is about 64-cores soon.
Regards,
Jignesh