[pgsql-general: 19] Re: Hỗ trợ bug Npgsql.PostgresException (0x80004005): 53300: sorry, too many clients already

pgvn_support support at postgresql.vn
Sun Jun 10 06:02:01 EDT 2018


Hi,

On 10/06/2018 6:34 CH, Trần Đức Thông wrote:
>
> Cảm ơn các bạn đã trả lời mình.
>
> Việc config lại tham số max_connection thì theo kinh nghiệm của admin 
> thì nên sửa thành bao nhiêu? Và ngoài config max_connection thì còn có 
> tham số nào nữa không. Mình đọc thì thấy cần tham số max_buffersize để 
> tăng dung lượng cache.
>

Bạn nên thao khảo thiết kế hệ thống của bạn để điều chỉnh max_connections.
Số lượng cần chỉnh là số lượng connections thực tế có thể kết nối tới 
PostgreSQL
(bao gồm cả các kết nối liên quan tới quản lý DB từ bạn) + 3 (mặc định 
của superuser_reserved_connections).

Thông thường khi thay đổi tham số max_connections bạn nên để ý tới 
resource hệ thống như bên dưới.

[Memory]
Mỗi một backend process của của PostgreSQL sử dụng khoảng 3MB memory.
Mỗi connection có thể sử dụng = (số lượng sort hay join) * work_mem.
# trường hợp của bạn không thấy có sort hay join.

[CPU]
Mỗi connections là một process nên tăng số lượng connections nhiều quá 
(khoảng 1000?), sẽ dẫn đến CPU neck.

PostgreSQL không có tham số max_buffersize.
Muốn tăng dung lượng buffers bạn có thể thiết lập tham số shared_buffers.
But tham số ngày không trực tiếp liên quan khi điều chỉnh max_connections.
Theo recommend của community thì thiết lập tham số này = 25% memory hệ 
thống.
But nếu thiết lập bạn cũng phải để ý thêm tham số liên quan tới 
checkpoint như max_wal_size,..

# Với các phiên bản gần đây thì không cần để ý tới các thiết lập về OS

Xin cảm ơn,
—
Together we work better
Cộng đồng PostgreSQL Việt Nam
>
> Việc custom cấu hình mặc gồm những tham số nào nhờ admin chỉ dõ thêm.
>
> Thank admin.
>
> On Jun 10, 2018 15:53, "pgvn_support" <support at postgresql.vn 
> <mailto:support at postgresql.vn>> wrote:
>
>     Hi,
>
>     On 09/06/2018 9:07 CH, Trần Đức Thông wrote:
>>     Xin bạn,
>>
>>     Mình hiện tại đang sử dụng PostgreSQL vào trong công việc. Tuy
>>     nhiên hiện giờ mình gặp một bug mà chưa giải quyết được. Nhờ các
>>     bạn tư vấn giúp. Chi tiết như sau
>>
>>     Phiên bản PostgreSQL 10
>>
>>     Mình có thực hiện một test như sau.
>>     1. Tạo một Table có 4 cột, và insert vào đó 1120 bản ghi.
>>
>>     2. Viêt một web api sử dụng thư viện#Npgsql
>>     <https://www.facebook.com/hashtag/npgsql?source=feed_text>tạo kết
>>     nối đến db vào execute một function. Function này thực hiện một
>>     nhiệm vụ đơn giản là trả ra hết các bản ghi của table trên.
>>
>>     3. Sử dụng jemeter load test vào function trên. Với tham số
>>     Number Of Theard = 200, Ramp-Up = 0, Loop Count = 5.
>>
>>     4. Kết quả xảy ra lỗi "sorry, too many clients already" -> check
>>     trong db thấy số connection đang mở là 105. Trong khi theo config
>>     của PostgreSql max-connection = 100.
>>
>     Số connections hiện tại trên PostgreSQL có thể xem từ view
>     pg_stat_activity của PostgreSQL.
>
>     max_connections không tính số lượng worker process (như background
>     worker, autovacuum launcher, ...).
>     Nên có trường hợp số lượng rows trong pg_stat_activity trả về giá
>     trị lớn hơn max_connections.
>
>     Ở phiên bản 10, có một số connections không được tính cho
>     max_connections cũng hiện thị trong pg_stat_activity như:
>     background writer, checkpointer, walwriter.
>     Nên giá trị connection đang mở có thể có giá trị 105 như bạn xác nhận.
>
>>     Mình không có nhiều kinh nghiệm với sql nên nhờ mọi người tư vấn
>>     giúp. Với 2 câu hỏi như sau.
>>
>>     1. Tạo sao lại xảy ra hiện tượng mở nhiều connection (sao
>>     connection pool k được dùng đến) trong chuỗi Connection string đã
>>     có tham số Pooling = true
>>
>
>     Chức năng connection pooling bạn nói là ở phía npgsql, không phải
>     bên PostgreSQL.
>     Nên mình chỉ có thể trả lời khái quát như bên dưới.
>     Để tìm hiểu cụ thể bạn tham khảo documents (hoặc source) phía npgsql.
>
>     Thông thường vì PostgreSQL sử dụng mỗi process cho một kết nối,
>     nên ở một số Driver có chức năng pool connection (hoặc tạo kết nối
>     trước (prefork))
>     để giảm overhead khi có kết nối mới.
>
>     Bạn có thể chỉnh số lượng connections pool ở phía driver.
>
>>     Câu 2. Tại sao khi postgresql đã max connection -> các request
>>     sau không được được cho vào queue đợi khi thực khi xong các
>>     request hiện tại mới tiếp tự thưc thi các request mới. Mà theo
>>     hiên tại postgresql vẫn cố mở thêm conneciton mới dẫn đến xảy ra
>>     lỗi trên
>>
>
>     Lỗi "sorry, too many clients already" là phía PostgreSQL trả về,
>     khi số lượng kết nối yêu cầu lớn hơn max_connections.
>     but PostgreSQL không tự mở thêm kết nối. Mở kết nối là do phía npgsql.
>     PostgreSQL cũng không có cơ chế queue để chứa các kết nối.
>
>     Bạn nên xem lại hệ thống bạn có mở kết nối khác ngoài npgsql không
>     (Ví dụ như cho mornitoring?) và
>     điều chỉnh lại max_connections (postgresql.conf) hoặc Max pool
>     size (npgsql) cho đúng.
>
>>
>>
>>
>>
>>
>>>>     Nhờ các bạn tư vấn giúp.
>>
>>     Mình xin cảm ơn.
>>     -------------------------------------------------------------------------------------------------
>>
>>     *Tran Duc Thong*
>>     Software engineering
>>     Mobile: 0989 452 004
>>     Email: humg.thongit at gmail.com <mailto:humg.thongit at gmail.com>
>
>     Xin cảm ơn,
>>     Together we work better
>     Cộng đồng PostgreSQL Việt Nam
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.postgresql.vn/pipermail/pgsql-general/attachments/20180610/119ad75b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 34774679_1820173794713440_1674413414325157888_n.jpg
Type: image/jpeg
Size: 16623 bytes
Desc: not available
URL: <http://www.postgresql.vn/pipermail/pgsql-general/attachments/20180610/119ad75b/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 34776555_1820163938047759_3125179472001630208_n.jpg
Type: image/jpeg
Size: 25358 bytes
Desc: not available
URL: <http://www.postgresql.vn/pipermail/pgsql-general/attachments/20180610/119ad75b/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 34815573_1820167161380770_7656883969492779008_n.jpg
Type: image/jpeg
Size: 37510 bytes
Desc: not available
URL: <http://www.postgresql.vn/pipermail/pgsql-general/attachments/20180610/119ad75b/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 34838297_1820164721381014_2112880329151741952_n.jpg
Type: image/jpeg
Size: 26905 bytes
Desc: not available
URL: <http://www.postgresql.vn/pipermail/pgsql-general/attachments/20180610/119ad75b/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 35049242_1820165204714299_6562859883991924736_n.jpg
Type: image/jpeg
Size: 26642 bytes
Desc: not available
URL: <http://www.postgresql.vn/pipermail/pgsql-general/attachments/20180610/119ad75b/attachment-0009.jpg>


More information about the pgsql-general mailing list