psql: FATAL: xin lỗi, đã có quá nhiều khách hàng

15

Tôi đột nhiên gặp lỗi này khi cố gắng truy cập trang web sử dụng cơ sở dữ liệu postgresql hoặc ngay cả khi sử dụng tiện ích psql hoặc pgadmin3.

Cơ sở dữ liệu của tôi được đặt để xử lý 150 kết nối tối đa:

# SHOW max_connections;
 max_connections 
-----------------
 150
(1 row)

Sau khi khởi động lại máy chủ Ubuntu trên trang web của tôi (đây thực sự là thứ duy nhất sử dụng kết nối), tôi thấy số lượng kết nối hiện tại là 140:

# select count(*) from pg_stat_activity;
 count 
-------
   140
(1 row)

Tôi không hiểu làm thế nào đột nhiên rất nhiều kết nối sau khi khởi động lại máy chủ của tôi. Vì vậy, tôi kiểm tra hoạt động postgresql:

# SELECT * FROM pg_stat_activity;

Và tôi thấy hơn 100 cột có cùng truy vấn chính xác giống như thế này:

SELECT  "reports".* FROM "reports"  WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1

Điều quan trọng hơn nữa là tất cả chúng đều có cùng một địa chỉ máy khách (máy chủ web của tôi).

Máy chủ web này đang sử dụng ruby ​​trên đường ray với nhóm kết nối là 50. Mặc dù có một nhóm kết nối là 50, nhưng cấu hình apache process Pasache là một luồng và do đó mỗi tiến trình không thể tạo ra 50 luồng và 50 kết nối cơ sở dữ liệu. Điều gì nữa xảy ra sau khi khởi động lại hệ thống khiến tất cả người dùng rời khỏi máy chủ web của tôi. Khả năng là postgresql trên máy chủ cơ sở dữ liệu không biết về việc khởi động lại máy chủ web và vẫn đang cố gắng thực hiện các truy vấn này.

Để trả lời các bình luận của Craig, dưới cột chờ, nó hiển thị chữ 'f'. Có vẻ như truy vấn vẫn đang thực thi và khóa chưa được phát hành. Như tôi đã nói trước đây, điều kỳ lạ là đột nhiên hơn 100 truy vấn giống hệt nhau trong vòng một phần nghìn giây đột nhiên xuất hiện trong trạng thái thực thi này. Đó là bí ẩn đối với tôi:

mydb=# SELECT * FROM pg_stat_activity;

 datid  | datname  | procpid | usesysid | usename |                                                                           current_query                                                                           | waiting |          xact_start           |          query_start          |         backend_start         |  client_addr   | client_port
--------+----------+---------+----------+---------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------+-------------------------------+-------------------------------+-------------------------------+----------------+-------------
 464875 | mydb     |    4992 |    16387 | myuser | SELECT  "reports".* FROM "reports"  WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f       | 2014-06-28 22:46:48.437081-04 | 2014-06-28 22:46:48.437081-04 | 2014-06-28 22:46:44.089764-04 | 192.111.11.111 |       37166
 464875 | mydb     |    4993 |    16387 | myuser | SELECT  "reports".* FROM "reports"  WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f       | 2014-06-28 22:46:48.497764-04 | 2014-06-28 22:46:48.497764-04 | 2014-06-28 22:46:44.277856-04 | 192.111.11.111 |       37167
 464875 | mydb     |    4994 |    16387 | myuser | SELECT  "reports".* FROM "reports"  WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f       | 2014-06-28 22:46:48.504425-04 | 2014-06-28 22:46:48.504425-04 | 2014-06-28 22:46:44.485269-04 | 192.111.11.111 |       37168
 464875 | mydb     |    4996 |    16387 | myuser | SELECT  "reports".* FROM "reports"  WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f       | 2014-06-28 22:46:48.482695-04 | 2014-06-28 22:46:48.482695-04 | 2014-06-28 22:46:44.688203-04 | 192.111.11.111 |       37169
 464875 | mydb     |    4998 |    16387 | myuser | SELECT  "reports".* FROM "reports"  WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f       | 2014-06-28 22:46:48.432836-04 | 2014-06-28 22:46:48.432836-04 | 2014-06-28 22:46:44.703883-04 | 192.111.11.111 |       37170

-- many more

 464875 | mydb     |    5052 |    16387 | myuser | SELECT  "reports".* FROM "reports"  WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f       | 2014-06-28 22:46:59.584386-04 | 2014-06-28 22:46:59.584386-04 | 2014-06-28 22:46:51.85682-04  | 192.111.11.111 |       37360
 464875 | mydb     |    5053 |    16387 | myuser | SELECT  "reports".* FROM "reports"  WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f       | 2014-06-28 22:46:59.506483-04 | 2014-06-28 22:46:59.506483-04 | 2014-06-28 22:46:52.083316-04 | 192.111.11.111 |       37367
 464875 | mydb     |    8958 |    16387 | myuser | <IDLE>                                                                                                                                                            | f       |                               | 2014-06-29 00:05:06.735249-04 | 2014-06-27 16:34:39.307312-04 | 192.111.11.111 |       52759
 464875 | mydb     |    5054 |    16387 | myuser | SELECT  "reports".* FROM "reports"  WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f       | 2014-06-28 22:46:59.52573-04  | 2014-06-28 22:46:59.52573-04  | 2014-06-28 22:46:52.285867-04 | 192.111.11.111 |       37371
 464875 | mydb     |    5055 |    16387 | myuser | SELECT  "reports".* FROM "reports"  WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f       | 2014-06-28 22:46:59.530804-04 | 2014-06-28 22:46:59.530804-04 | 2014-06-28 22:46:52.303562-04 | 192.111.11.111 |       37372
 464875 | mydb     |    5056 |    16387 | myuser | SELECT  "reports".* FROM "reports"  WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f       | 2014-06-28 22:46:59.572198-04 | 2014-06-28 22:46:59.572198-04 | 2014-06-28 22:46:52.31447-04  | 192.111.11.111 |       37373
 464875 | mydb     |    5057 |    16387 | myuser | SELECT  "reports".* FROM "reports"  WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f       | 2014-06-28 22:46:59.872037-04 | 2014-06-28 22:46:59.872037-04 | 2014-06-28 22:46:52.323721-04 | 192.111.11.111 |       37374
 464875 | mydb     |    5058 |    16387 | myuser | SELECT  "reports".* FROM "reports"  WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f       | 2014-06-28 22:46:59.961803-04 | 2014-06-28 22:46:59.961803-04 | 2014-06-28 22:46:52.334238-04 | 192.111.11.111 |       37375
 464875 | mydb     |    5059 |    16387 | myuser | SELECT  "reports".* FROM "reports"  WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f       | 2014-06-28 22:46:59.53713-04  | 2014-06-28 22:46:59.53713-04  | 2014-06-28 22:46:52.347227-04 | 192.111.11.111 |       37376
 464875 | mydb     |    5060 |    16387 | myuser | SELECT  "reports".* FROM "reports"  WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f       | 2014-06-28 22:47:00.208948-04 | 2014-06-28 22:47:00.208948-04 | 2014-06-28 22:46:52.360008-04 | 192.111.11.111 |       37377
 464875 | mydb     |    5061 |    16387 | myuser | SELECT  "reports".* FROM "reports"  WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f       | 2014-06-28 22:46:59.938983-04 | 2014-06-28 22:46:59.938983-04 | 2014-06-28 22:46:52.369496-04 | 192.111.11.111 |       37378
postgresql  max-connections 
— JohnMerlino
nguồn
Hãy nhìn vào pg_stat_activity.backend_start. Những kết nối này được tạo trước hay sau khi máy chủ web khởi động lại? Nếu tất cả chúng đều là kết nối mới, tôi sẽ tưởng tượng điều đó có nghĩa là sự cố nằm ở cuối máy chủ web.
— Nick Barnes
@NickBarnes tất cả các kết nối này đều có cùng một truy vấn trong cột "current_query" và thời gian backend_start thực tế giống nhau cho tất cả các kết nối đó (cách nhau một phần nghìn giây). Đó là điều kỳ lạ và tôi tin rằng nếu bộ nhớ phục vụ cho tôi chính xác thì tất cả đều là trước khi khởi động lại. Nhưng tôi cho rằng khởi động lại sẽ phá vỡ kết nối.
— JohnMerlino
1
Ok ... Bạn có thể cần kiểm tra toptrên máy chủ để xem các quy trình này có bận không. Nếu có, thì tôi nghĩ các kết nối sẽ biến mất sau khi các truy vấn kết thúc (hoặc cách khác, bạn có thể giết chúng ngay bây giờ). Nếu chúng không hoạt động và các kết nối chắc chắn đã chết, thì tôi không chắc chuyện gì đang xảy ra hoặc làm thế nào để ngăn chặn lần sau ...
— Nick Barnes
1
Kiểm tra waitingcờ pg_stat_activity, xem họ có bị kẹt trên khóa không.
— Craig Ringer
1
Đầu ra bạn dán từ SELECT * FROM pg_stat_activity;không thể tin được - không có đủ cột. Cột nhà nước nói gì? Đó là lĩnh vực quan trọng nhất cho câu hỏi này.
— eradman

Câu trả lời:

5

Đây có vẻ là vấn đề cụ thể lập trình khách hàng. Bạn sẽ không thể khắc phục điều này bằng cách tăng tham số "max_connections".

Tôi đã tìm thấy một vấn đề có thể liên quan: nhóm kết nối cơ sở dữ liệu Ruby

Dù sao bạn cũng có thể thực hiện thêm một số gỡ lỗi phía máy chủ:

Bật "log_connections" và "log_disconnections". Đồng thời sử dụng "log_line_prefix" với "% m% a% p".

Các ứng dụng rất hữu ích để gỡ lỗi các máy chủ PostgreSQL là powa hoặc nhiều hơn nữa như: pg_activity

Đối với gỡ lỗi máy chủ thời gian thực, tôi thích pg_activity - đặc biệt là với tính năng của nó để hiển thị các trình chặn và để giết phiên.

— Josef Hopfgartner
nguồn
-4

Đây là cách tốt nhất để giải quyết vấn đề ... nó hoạt động

Đăng nhập vào máy chủ bằng SSH putty,

sudo /etc/init.d/postgresql dừng

điều này sẽ giết chết các quá trình nhật ký chết trong cơ sở dữ liệu sau đó,

sudo /etc/init.d/postgresql bắt đầu

— Maduka
nguồn
5
Và lần sau bạn dừng lại một máy chủ sản xuất? Giải pháp của bạn loại bỏ rõ ràng các quy trình bị mắc kẹt, nhưng không giải thích lý do tại sao chúng ở đó, cũng không phải là một quy trình bền vững.
— dezso
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.