Re: Performance problems with a higher number of clients

Thanks for the advices,
The performance is a bit better now. Unfortunately, the machine does not
allow
to put more than 200 - ~250 users without noticing swap hell.
I have to face the fact that I don't have enough memory....

I used the following configuration:

effective_cache_size = 65000
shared_buffers = 10000
random_page_cost = 2
cpu_index_tuple_cost = 0.0005
sort_mem = 512 - I tested each query to see the amount of space
required to sort as Jeff suggested --> nothing above this value

I tested the system with 100, 200, 300, 400, 500 and finally 250 users.
Until ~250 users the system presents good response time and the swap
almost does not exist.
During these expirements, I also started psql and tried to run some
queries.
Unfortunately, even with ~250 users there is one query that takes too
long to finish...
In fact, I canceled its execution after 5 minutes waiting to see anything.

This is the query:

select count(distinct(s_i_id))
from stock, order_line
where ol_w_id = _xx_ and
ol_d_id = _xx_ and
ol_o_id between _xx_ and
_xx_ and
s_w_id = ol_w_id and
s_i_id = ol_i_id and
s_quantity < _xx_;

When the system has no load, after a vacuum -f, I can execute the query
and the plan produced is presented as follows:
Aggregate (cost=49782.16..49782.16 rows=1 width=4) (actual
time=52361.573..52361.574 rows=1 loops=1)
-> Nested Loop (cost=0.00..49780.24 rows=768 width=4) (actual
time=101.554..52328.913 rows=952 loops=1)
-> Index Scan using pk_order_line on order_line o
(cost=0.00..15779.32 rows=8432 width=4) (actual time=84.352..151.345
rows=8964 loops=1)
Index Cond: ((ol_w_id = 4) AND (ol_d_id = 4) AND (ol_o_id
>= 100) AND (ol_o_id <= 1000))
-> Index Scan using pk_stock on stock (cost=0.00..4.02 rows=1
width=4) (actual time=5.814..5.814 rows=0 loops=8964)
Index Cond: ((stock.s_w_id = 4) AND (stock.s_i_id =
"outer".ol_i_id))
Filter: (s_quantity < 20)
Total runtime: 52403.673 ms
(8 rows)

The talbes are designed as follows:

--ROWS ~5000000
CREATE TABLE stock (
s_i_id int NOT NULL ,
s_w_id int NOT NULL ,
s_quantity int NULL ,
s_dist_01 char (24) NULL ,
s_dist_02 char (24) NULL ,
s_dist_03 char (24) NULL ,
s_dist_04 char (24) NULL ,
s_dist_05 char (24) NULL ,
s_dist_06 char (24) NULL ,
s_dist_07 char (24) NULL ,
s_dist_08 char (24) NULL ,
s_dist_09 char (24) NULL ,
s_dist_10 char (24) NULL ,
s_ytd int NULL ,
s_order_cnt int NULL ,
s_remote_cnt int NULL ,
s_data char (50) NULL
);

--ROWS ~15196318
CREATE TABLE order_line (
ol_o_id int NOT NULL ,
ol_d_id int NOT NULL ,
ol_w_id int NOT NULL ,
ol_number int NOT NULL ,
ol_i_id int NULL ,
ol_supply_w_id int NULL ,
ol_delivery_d timestamp NULL ,
ol_quantity int NULL ,
ol_amount numeric(6, 2) NULL ,
ol_dist_info char (24) NULL
);

ALTER TABLE stock ADD
CONSTRAINT PK_stock PRIMARY KEY
(
s_w_id,
s_i_id
);
ALTER TABLE order_line ADD
CONSTRAINT PK_order_line PRIMARY KEY
(
ol_w_id,
ol_d_id,
ol_o_id,
ol_number
);
CREATE INDEX IX_order_line ON order_line(ol_i_id);

Any suggestion ?

Tom Lane wrote:

>Alfranio Correia Junior <alfranio(at)lsd(dot)di(dot)uminho(dot)pt> writes:
>
>
>>I am facing a problem trying to put 500 concurrent users accessing
>>a postgresql instance.
>>
>>
>
>I think you're going to need to buy more RAM. 1Gb of RAM means there
>is a maximum of 2Mb available per Postgres process before you start
>to go into swap hell --- in practice a lot less, since you have to allow
>for other things like the kernel and other applications.
>
>AFAIR TPC-C doesn't involve any complex queries, so it's possible you
>could run it with only 1Mb of workspace per process, but not when
>you've configured
>
>
>
>>sort_mem = 10240
>>
>>
>
>That's ten times more than your configuration can possibly support.
>(I don't recall whether TPC-C uses any queries that would sort, so
>it's possible this setting isn't affecting you; but if you are doing
>any sorts then it's killing you.)
>
>Bottom line is you probably need more RAM.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
>