Những điều quan trọng cần theo dõi trong PostgreSQL - Phân tích khối lượng công việc của bạn

Trong hệ thống máy tính, giám sát là quá trình thu thập các chỉ số, phân tích, tính toán thống kê và tạo ra các tóm tắt và đồ thị liên quan đến hiệu suất hoặc năng lực của hệ thống, cũng như tạo ra các cảnh báo trong trường hợp có sự cố hoặc hỏng hóc bất ngờ cần sự chú ý hoặc hành động ngay lập tức. Do đó, việc giám sát có hai cách sử dụng:một để phân tích và trình bày dữ liệu lịch sử, giúp chúng tôi xác định các xu hướng trung và dài hạn trong hệ thống của mình và do đó giúp chúng tôi lập kế hoạch nâng cấp và cách thứ hai để hành động ngay lập tức trong trường hợp có sự cố.

Giám sát giúp chúng tôi xác định các vấn đề và phản ứng với những vấn đề đó liên quan đến nhiều lĩnh vực như:

Cơ sở hạ tầng / Phần cứng (vật lý hoặc ảo)
Mạng
Bộ nhớ
Phần mềm Hệ thống
Phần mềm Ứng dụng
Bảo mật

Giám sát là một phần chính trong công việc của DBA. PostgreSQL, theo truyền thống, được biết đến là "bảo trì thấp" nhờ thiết kế phức tạp của nó và điều này có nghĩa là hệ thống có thể tồn tại với tỷ lệ tham gia thấp khi so sánh với các lựa chọn thay thế khác. Tuy nhiên, đối với những cài đặt nghiêm túc, nơi tính khả dụng và hiệu suất cao là điều quan trọng hàng đầu, hệ thống cơ sở dữ liệu phải được theo dõi thường xuyên.

Vai trò của PostgreSQL DBA có thể nâng lên các cấp cao hơn trong hệ thống phân cấp của công ty bên cạnh tính kỹ thuật nghiêm ngặt:ngoài việc giám sát cơ bản và phân tích hiệu suất, phải có khả năng phát hiện những thay đổi trong cách sử dụng, xác định nguyên nhân có thể, xác minh các giả định và cuối cùng là dịch phát hiện trong điều khoản kinh doanh. Ví dụ, DBA phải có khả năng xác định một số thay đổi đột ngột trong một hoạt động nhất định có thể liên quan đến một mối đe dọa bảo mật có thể xảy ra. Vì vậy vai trò của PostgreSQL DBA là một vai trò quan trọng trong công ty, và phải phối hợp chặt chẽ với các trưởng bộ phận khác để xác định và giải quyết các vấn đề phát sinh. Giám sát là một phần quan trọng của trách nhiệm này.

PostgreSQL cung cấp nhiều công cụ sẵn có để giúp chúng tôi thu thập và phân tích dữ liệu. Ngoài ra, do khả năng mở rộng, nó cung cấp phương tiện để phát triển các mô-đun mới thành hệ thống lõi.

PostgreSQL phụ thuộc nhiều vào hệ thống (phần cứng và phần mềm) mà nó chạy. Chúng tôi không thể mong đợi một máy chủ PostgreSQL hoạt động tốt nếu có vấn đề ở bất kỳ thành phần quan trọng nào trong phần còn lại của hệ thống. Vì vậy, vai trò của DBA PostgreSQL chồng chéo với vai trò của sysadmin. Dưới đây, khi chúng tôi kiểm tra những gì cần xem trong quá trình giám sát PostgreSQL, chúng tôi sẽ gặp cả các biến và chỉ số phụ thuộc vào hệ thống cũng như các số liệu cụ thể của PostgreSQL.

Giám sát không đến miễn phí. Một khoản đầu tư tốt phải được đặt vào đó bởi công ty / tổ chức với cam kết quản lý và duy trì toàn bộ quá trình giám sát. Nó cũng thêm một tải nhẹ trên máy chủ PostgreSQL. Điều này có thể khiến bạn ít lo lắng nếu mọi thứ được định cấu hình chính xác, nhưng chúng ta phải lưu ý rằng đây có thể là một cách khác để sử dụng sai hệ thống.

Khái niệm cơ bản về giám sát hệ thống

Các biến quan trọng trong giám sát hệ thống là:

Sử dụng CPU
Sử dụng mạng
Dung lượng đĩa / Sử dụng đĩa
Mức sử dụng RAM
IOPS trên đĩa
Hoán đổi việc sử dụng dung lượng
Lỗi mạng

Đây là một ví dụ về ClusterControl hiển thị đồ thị cho một số biến PostgreSQL quan trọng đến từ pg_stat_database và pg_stat_bgwriter (mà chúng tôi sẽ đề cập trong các đoạn sau) trong khi chạy pgbench -c 64 -t 1000 pgbench hai lần:

Chúng tôi nhận thấy rằng chúng tôi đạt đỉnh về khối được đọc trong lần chạy đầu tiên, nhưng chúng tôi gần bằng 0 trong lần chạy thứ hai vì tất cả các khối đều được tìm thấy trong shared_buffers.

Các biến khác được quan tâm là hoạt động phân trang, ngắt, chuyển mạch ngữ cảnh, trong số những biến khác. Có rất nhiều công cụ để sử dụng trong Linux / BSD và các hệ thống giống unix hoặc unix. Một số trong số đó là:

ps:để biết danh sách các quy trình đang chạy
top / htop / systat:để giám sát việc sử dụng hệ thống (CPU / bộ nhớ)
vmstat:để giám sát hoạt động chung của hệ thống (bao gồm cả bộ nhớ ảo)
iostat / iotop / top -mio:để giám sát IO
ntop:để giám sát mạng

Đây là một ví dụ về vmstat trên hộp FreeBSD trong một truy vấn yêu cầu một số lần đọc đĩa và một số tính toán:

procs  memory      page                         disks      faults          cpu
r b w  avm   fre   flt   re  pi  po   fr    sr  ad0 ad1  in     sy    cs us sy id
0 0 0  98G  666M   421   0   0   0   170  2281    5  0  538   6361  2593  1  1 97
0 0 0  98G  665M   141   0   0   0     0  2288   13  0  622  11055  3748  3  2 94
--- query starts here ---
0 0 0  98G  608M   622   0   0   0   166  2287 1072  0 1883  16496 12202  3  2 94
0 0 0  98G  394M   101   0   0   0     2  2284 4578  0 5815  24236 39205  3  5 92
2 0 0  98G  224M  4861   0   0   0  1711  2287 3588  0 4806  24370 31504  4  6 91
0 0 0  98G  546M    84 188   0   0 39052 41183 2832  0 4017  26007 27131  5  7 88
2 0 0  98G  469M   418   0   0   1   397  2289 1590  0 2356  11789 15030  2  2 96
0 0 0  98G  339M   112   0   0   0   348  2300 2852  0 3858  17250 25249  3  4 93
--- query ends here ---
1 0 0  98G  332M  1622   0   0   0   213  2289    4  0  531   6929  2502  3  2 95

Lặp lại truy vấn, chúng tôi sẽ không nhận thấy bất kỳ đợt bùng nổ mới nào trong hoạt động đĩa vì các khối đĩa đó đã nằm trong bộ nhớ cache của Hệ điều hành. Mặc dù, PostgreSQL DBA phải có khả năng hiểu đầy đủ những gì đang xảy ra trong cơ sở hạ tầng bên dưới nơi cơ sở dữ liệu chạy, việc giám sát hệ thống phức tạp hơn thường là công việc đối với sysadmin, vì bản thân đây là một chủ đề lớn.

Trong linux, một phím tắt rất tiện dụng cho trên cùng tiện ích đang nhấn “C”, nút này sẽ chuyển đổi hiển thị dòng lệnh của các quy trình. Theo mặc định, PostgreSQL viết lại dòng lệnh của các chương trình phụ trợ với hoạt động SQL thực tế mà chúng đang chạy vào lúc này và cả người dùng.

Kiến thức cơ bản về giám sát PostgreSQL

Các biến quan trọng trong giám sát PostgreSQL là:

Hiệu suất bộ nhớ đệm của bộ đệm (số lần truy cập bộ nhớ đệm so với số lần đọc đĩa)
Số lần cam kết
Số lượng kết nối
Số lượng phiên
Các điểm kiểm tra và thống kê của người viết quảng cáo
Máy hút
Khóa
Nhân rộng
Và cuối cùng nhưng chắc chắn không kém phần quan trọng, các truy vấn

Nói chung, có hai cách trong thiết lập giám sát để thực hiện thu thập dữ liệu:

Để lấy dữ liệu qua Nhật ký
Để lấy dữ liệu bằng cách truy vấn hệ thống PostgreSQL

Việc thu thập dữ liệu dựa trên tệp nhật ký phụ thuộc vào nhật ký PostgreSQL (được định cấu hình đúng cách). Chúng ta có thể sử dụng kiểu ghi nhật ký này để xử lý dữ liệu "ngoại tuyến". Giám sát dựa trên tệp nhật ký là phù hợp nhất khi yêu cầu chi phí tối thiểu cho máy chủ PostgreSQL và khi chúng tôi không quan tâm đến dữ liệu trực tiếp hoặc về việc nhận cảnh báo trực tiếp (mặc dù có thể giám sát trực tiếp bằng dữ liệu tệp nhật ký bằng cách chuyển trực tiếp nhật ký postgresql tới nhật ký hệ thống và sau đó truyền nhật ký hệ thống đến một máy chủ khác dành riêng để xử lý nhật ký).

Tải xuống Báo cáo chính thức hôm nay Quản lý &Tự động hóa PostgreSQL với ClusterControlTìm hiểu về những điều bạn cần biết để triển khai, giám sát, quản lý và mở rộng PostgreSQLTải xuống Báo cáo chính thức

Trình thu thập thống kê PostgreSQL

PostgreSQL cung cấp một tập hợp các chế độ xem và chức năng phong phú có sẵn thông qua hệ thống con Bộ thu thập thống kê. Một lần nữa, những dữ liệu đó được chia thành hai loại:

Thông tin động về những gì hệ thống đang thực hiện tại thời điểm này.
Số liệu thống kê được tích lũy kể từ khi hệ thống con của bộ thu thập số liệu thống kê được đặt lại lần cuối.

Chế độ xem thống kê động cung cấp thông tin về hoạt động hiện tại trên mỗi quá trình (pg_stat_activity), trạng thái sao chép vật lý (pg_stat_replication), trạng thái chờ vật lý (pg_stat_wal_receiver) hoặc logic (pg_stat_subscription), ssl (pg_stat_ssl) và chân không (pg_stat_progress_vacuum).

Chế độ xem thống kê đã thu thập cung cấp thông tin về các quy trình nền quan trọng như trình lưu trữ wal, bgwriter và các đối tượng cơ sở dữ liệu:bảng người dùng hoặc hệ thống, chỉ mục, trình tự và chức năng cũng như chính cơ sở dữ liệu.

Rõ ràng là bây giờ có nhiều cách để phân loại dữ liệu liên quan đến giám sát:

Theo nguồn:
- Công cụ hệ thống (ps, top, iotop, v.v.)
- Tệp nhật ký PgSQL
- Cơ sở dữ liệu
  - Động
  - Đã thu thập
Bằng hoạt động cơ sở dữ liệu cụ thể:
- Bộ đệm đệm
- Cam kết
- Truy vấn
- Phiên
- Điểm kiểm tra
- Vv

Sau khi đọc bài viết này và thử nghiệm với các khái niệm, khái niệm và thuật ngữ được trình bày, bạn sẽ có thể tạo ma trận 2D với tất cả các kết hợp có thể. Ví dụ:hoạt động PostgreSQL cụ thể (lệnh SQL) có thể được tìm thấy bằng cách sử dụng:ps hoặc top (tiện ích hệ thống), tệp nhật ký PostgreSQL, pg_stat_activity (chế độ xem động), nhưng cũng sử dụng pg_stat_statements, một tiện ích mở rộng được tìm thấy trong Contrib (chế độ xem thống kê được thu thập) . Tương tự như vậy, thông tin về khóa có thể được tìm thấy trong tệp nhật ký PostgreSQL, pg_locks và pg_stat_activity (được trình bày ngay bên dưới) bằng cách sử dụng wait_event và wait_event_type . Do đó, rất khó để bao quát khu vực giám sát rộng lớn theo kiểu tuyến tính đơn chiều, và tác giả có nguy cơ tạo ra sự nhầm lẫn cho người đọc vì điều này. Để tránh điều này, chúng tôi sẽ đề cập đến việc giám sát đại khái bằng cách tuân theo quy trình của tài liệu chính thức và bổ sung thông tin liên quan nếu cần.

Chế độ xem thống kê động

Sử dụng pg_stat_activity chúng tôi có thể xem hoạt động hiện tại là gì bằng các quy trình phụ trợ khác nhau. Ví dụ:nếu chúng ta chạy truy vấn sau trên các phần của bảng có khoảng 3M hàng:

testdb=# \d parts
                         Table "public.parts"
   Column   |          Type          | Collation | Nullable | Default
------------+------------------------+-----------+----------+---------
 id         | integer                |           |          |
 partno     | character varying(20)  |           |          |
 partname   | character varying(80)  |           |          |
 partdescr  | text                   |           |          |
 machine_id | integer                |           |          |
 parttype   | character varying(100) |           |          |
 date_added | date                   |           |          |

Và hãy chạy truy vấn sau, cần vài giây để hoàn thành:

testdb=# select avg(age(date_added)) FROM parts;

Bằng cách mở một thiết bị đầu cuối mới và chạy truy vấn sau, trong khi truy vấn trước đó vẫn đang chạy, chúng tôi nhận được:

testdb=# select pid,usename,application_name,client_addr,backend_start,xact_start,query_start,state,backend_xid,backend_xmin,query,backend_type from pg_stat_activity where datid=411547739 and usename ='achix' and state='active';
-[ RECORD 1 ]----+----------------------------------------
pid              | 21305
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:04:35.833677+02
xact_start       | 2018-03-02 18:04:35.832564+02
query_start      | 2018-03-02 18:04:35.832564+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | background worker
-[ RECORD 2 ]----+----------------------------------------
pid              | 21187
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:02:06.834787+02
xact_start       | 2018-03-02 18:04:35.826065+02
query_start      | 2018-03-02 18:04:35.826065+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | client backend
-[ RECORD 3 ]----+----------------------------------------
pid              | 21306
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:04:35.837829+02
xact_start       | 2018-03-02 18:04:35.836707+02
query_start      | 2018-03-02 18:04:35.836707+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | background worker

Chế độ xem pg_stat_activity cung cấp cho chúng tôi thông tin về quy trình phụ trợ, người dùng, khách hàng, giao dịch, truy vấn, trạng thái cũng như thông tin toàn diện về trạng thái chờ của truy vấn.

Nhưng tại sao lại là 3 hàng? Trong các phiên bản> =9.6, nếu một truy vấn có thể được chạy song song hoặc các phần của nó có thể được chạy song song và trình tối ưu hóa cho rằng thực thi song song là chiến lược nhanh nhất, thì nó sẽ tạo ra một Tập hợp hoặc Gom Merge và sau đó yêu cầu tối đa max_parallel_workers_per_gather các quy trình của background worker, theo mặc định là 2, do đó có 3 hàng mà chúng ta thấy trong đầu ra ở trên. Chúng tôi có thể phân biệt quy trình phụ trợ ứng dụng khách với trình xử lý nền bằng cách sử dụng backend_type cột. Để bật chế độ xem pg_stat_activity, bạn sẽ phải đảm bảo rằng thông số cấu hình hệ thống track_actiilities đang bật. Pg_stat_activity cung cấp nhiều thông tin để xác định các truy vấn bị chặn bằng cách sử dụng các cột wait_event_type và wait_event.

Một cách tinh tế hơn để theo dõi các báo cáo là thông qua pg_stat_statements phần mở rộng đóng góp, đã đề cập trước đó. Trên hệ thống Linux gần đây (Ubuntu 17.10, PostgreSQL 9.6), điều này có thể được cài đặt khá dễ dàng:

testdb=# create extension pg_stat_statements ;
CREATE EXTENSION
testdb=# alter system set shared_preload_libraries TO 'pg_stat_statements';
ALTER SYSTEM
testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.

testdb=# \d pg_stat_statements

Hãy tạo một bảng với 100000 hàng, sau đó đặt lại pg_stat_statements, khởi động lại máy chủ PostgreSQL, thực hiện chọn trên bảng này trên hệ thống (vẫn còn lạnh), sau đó xem nội dung của pg_stat_statements cho lựa chọn:

testdb=# select 'descr '||gs as descr,gs as id into medtable from  generate_series(1,100000) as gs;
SELECT 100000
testdb=# select pg_stat_statements_reset();
 pg_stat_statements_reset
--------------------------
 
(1 row)

testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
 shared_blks_hit | shared_blks_read
-----------------+------------------
               0 |              541
(1 row)

testdb=#

Bây giờ chúng ta hãy thực hiện select * một lần nữa và sau đó xem lại nội dung của pg_stat_statements cho truy vấn này:

[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.

testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
 shared_blks_hit | shared_blks_read
-----------------+------------------
             541 |              541
(1 row)

Vì vậy, lần thứ hai câu lệnh select tìm thấy tất cả các khối bắt buộc trong bộ đệm được chia sẻ PostgreSQL và pg_stat_statements báo cáo điều này qua shared_blks_hit . pg_stat_statements cung cấp thông tin về tổng số lệnh gọi của một câu lệnh, total_time, min_time, max_time và mean_time, có thể cực kỳ hữu ích khi cố gắng phân tích khối lượng công việc của hệ thống của bạn. Một truy vấn chậm được chạy rất thường xuyên cần được chú ý ngay lập tức. Tương tự, tỷ lệ truy cập thấp nhất quán có thể cho thấy sự cần thiết phải xem xét shared_buffers cài đặt.

pg_stat_replication cung cấp thông tin về trạng thái tái tạo hiện tại cho mỗi wal_sender. Giả sử chúng ta đã thiết lập cấu trúc liên kết sao chép đơn giản với chế độ chờ chính và một chế độ chờ nóng, sau đó chúng ta có thể truy vấn pg_stat_replication trên chế độ chờ chính (thực hiện tương tự ở chế độ chờ sẽ không mang lại kết quả trừ khi chúng ta đã thiết lập sao chép xếp tầng và chế độ chờ cụ thể này đóng vai trò như một hướng ngược dòng sang các dự phòng hạ lưu khác) để xem trạng thái hiện tại của quá trình sao chép:

testdb=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 1317
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 10.0.2.2
client_hostname  |
client_port      | 48192
backend_start    | 2018-03-03 11:59:21.315524+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/3029DB8
write_lsn        | 0/3029DB8
flush_lsn        | 0/3029DB8
replay_lsn       | 0/3029DB8
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async

4 cột sent_lsn , write_lsn , flush_lsn , replay_lsn cho chúng tôi biết vị trí WAL chính xác ở mỗi giai đoạn của quá trình sao chép ở chế độ chờ từ xa. Sau đó, chúng tôi tạo một số lưu lượng truy cập lớn trên trang chính bằng lệnh như:

testdb=# insert into foo(descr) select 'descr ' || gs from generate_series(1,10000000) gs;

Và nhìn lại pg_stat_replication:

postgres=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 1317
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 10.0.2.2
client_hostname  |
client_port      | 48192
backend_start    | 2018-03-03 11:59:21.315524+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/D5E0000
write_lsn        | 0/D560000
flush_lsn        | 0/D4E0000
replay_lsn       | 0/C5FF0A0
write_lag        | 00:00:04.166639
flush_lag        | 00:00:04.180333
replay_lag       | 00:00:04.614416
sync_priority    | 0
sync_state       | async

Bây giờ, chúng tôi thấy rằng chúng tôi có độ trễ giữa chế độ chính và chế độ chờ được mô tả trong sent_lsn , write_lsn , flush_lsn , replay_lsn các giá trị. Kể từ PgSQL 10.0, pg_stat_replication cũng cho thấy độ trễ giữa WAL được xóa cục bộ gần đây và thời gian nó được ghi từ xa, xóa và phát lại tương ứng. Nhìn thấy giá trị rỗng trong 3 cột đó có nghĩa là cột chính và cột chờ đang đồng bộ hóa.

Tương đương với pg_stat_replication ở chế độ chờ được gọi là: pg_stat_wal_receiver:

testdb=# select * from pg_stat_wal_receiver ;
-[ RECORD 1 ]---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
pid                   | 17867
status                | streaming
receive_start_lsn     | 0/F000000
receive_start_tli     | 1
received_lsn          | 0/3163F210
received_tli          | 1
last_msg_send_time    | 2018-03-03 13:32:42.516551+00
last_msg_receipt_time | 2018-03-03 13:33:28.644394+00
latest_end_lsn        | 0/3163F210
latest_end_time       | 2018-03-03 13:32:42.516551+00
slot_name             | fbsdclone
conninfo              | user=postgres passfile=/usr/local/var/lib/pgsql/.pgpass dbname=replication host=10.0.2.2 port=20432 fallback_application_name=walreceiver sslmode=disable sslcompression=1 target_session_attrs=any

testdb=#

Khi không có hoạt động nào và chế độ chờ đã phát lại mọi thứ thì last_end_lsn phải bằng sent_lsn trên số chính (và tất cả các số thứ tự nhật ký trung gian).

Tương tự như sao chép vật lý, trong trường hợp sao chép lôgic, trong đó nhà xuất bản thực hiện vai trò của bản chính và vai trò của chế độ chờ do người đăng ký đảm nhận, đương nhiên vai trò của pg_stat_wal_receiver được thực hiện bởi pg_stat_subscription . Chúng tôi có thể truy vấn pg_stat_subscription như sau:

testdb=# select * from pg_stat_subscription ;
-[ RECORD 1 ]---------+------------------------------
subid                 | 24615
subname               | alltables_sub
pid                   | 1132
relid                 |
received_lsn          | 0/33005498
last_msg_send_time    | 2018-03-03 17:05:36.004545+00
last_msg_receipt_time | 2018-03-03 17:05:35.990659+00
latest_end_lsn        | 0/33005498
latest_end_time       | 2018-03-03 17:05:36.004545+00

Lưu ý rằng về phía nhà xuất bản, chế độ xem tương ứng giống như trong trường hợp sao chép vật lý: pg_stat_replication .

Lượt xem thống kê được thu thập

pg_stat_archiver chế độ xem có một hàng cung cấp thông tin về trình lưu trữ wal. Giữ ảnh chụp nhanh của hàng này đều đặn cho phép bạn tính toán kích thước của lưu lượng truy cập WAL giữa các khoảng thời gian đó. Ngoài ra, nó cung cấp thông tin về các lỗi khi lưu trữ tệp WAL.

pg_stat_bgwriter chế độ xem cung cấp thông tin rất quan trọng về hành vi của:

Người kiểm tra
Người viết nền
Phần phụ trợ (phục vụ khách hàng)

Vì chế độ xem này cung cấp dữ liệu tích lũy kể từ lần đặt lại cuối cùng. Sẽ rất hữu ích khi tạo một bảng có dấu thời gian khác với ảnh chụp nhanh định kỳ của pg_stat_bgwriter , do đó sẽ dễ dàng có được góc nhìn gia tăng giữa hai ảnh chụp nhanh. Điều chỉnh là một khoa học (hoặc ma thuật), và nó đòi hỏi phải ghi nhật ký và giám sát sâu rộng cũng như hiểu rõ về các khái niệm cơ bản và nội bộ của PostgreSQL để có kết quả tốt và chế độ xem này là nơi bắt đầu, tìm kiếm những thứ như:

Có phải là checkpoints_timed phần lớn tổng số các trạm kiểm soát? Nếu không, thì phải thực hiện các hành động, đo lường kết quả và lặp lại toàn bộ quy trình cho đến khi không tìm thấy cải tiến nào.
Là buffers_checkpoint đa số tốt so với hai loại còn lại ( buffers_clean nhưng quan trọng nhất là buffers_backend )? Nếu buffers_backend cao, thì một lần nữa, một số thông số cấu hình nhất định phải được thay đổi, thực hiện các phép đo mới và đánh giá lại.

Pg_stat_ [user | sys | all] _tables

Cách sử dụng cơ bản nhất của các chế độ xem đó là để xác minh rằng chiến lược chân không của chúng tôi hoạt động như mong đợi. Giá trị lớn của các bộ giá trị chết so với các bộ nguyên liệu còn sống cho thấy khả năng hút bụi không hiệu quả. Các chế độ xem đó cũng cung cấp thông tin về các lần quét và tìm nạp seq so với chỉ mục, thông tin về số lượng hàng được chèn, cập nhật, xóa cũng như các bản cập nhật HOT. Bạn nên cố gắng duy trì số lượng bản cập nhật HOT nhất có thể để cải thiện hiệu suất.

Pg_stat_ [user | sys | all] _indexes

Tại đây hệ thống lưu trữ và hiển thị thông tin về việc sử dụng chỉ mục cá nhân. Một điều cần lưu ý là idx_tup_read chính xác hơn idx_tup_fetch. Chỉ mục không PK / không duy nhất với idx_scan thấp nên được xem xét để loại bỏ, vì chúng chỉ cản trở các bản cập nhật HOT. Như đã đề cập trong blog trước, nên tránh lập chỉ mục quá mức, lập chỉ mục sẽ phải trả giá.

Pg_statio_ [user | sys | all] _tables

Trong các chế độ xem đó, chúng ta có thể tìm thấy thông tin về hiệu suất của bộ nhớ cache liên quan đến việc đọc đống bảng, đọc chỉ mục và đọc TOAST. Một truy vấn đơn giản để đếm phần trăm lần truy cập và phân phối số lần truy cập trên các bảng sẽ là:

with statioqry as (select relid,heap_blks_hit,heap_blks_read,row_number() OVER (ORDER BY 100.0*heap_blks_hit::numeric/(heap_blks_hit+heap_blks_read) DESC),COUNT(*) OVER () from pg_statio_user_tables where heap_blks_hit+heap_blks_read >0)
select relid,row_number,100.0*heap_blks_hit::float8/(heap_blks_hit+heap_blks_read) as "heap block hits %", 100.0 * row_number::real/count as "In top %" from statioqry order by row_number;
   relid   | row_number | heap block hits % |     In top %      
-----------+------------+-------------------+-------------------
     16599 |          1 |  99.9993058404502 | 0.373134328358209
     18353 |          2 |  99.9992251425738 | 0.746268656716418
     18338 |          3 |    99.99917566565 |  1.11940298507463
     17269 |          4 |  99.9990617323798 |  1.49253731343284
     18062 |          5 |  99.9988021889522 |  1.86567164179104
     18075 |          6 |  99.9985334109273 |  2.23880597014925
     18365 |          7 |  99.9968070500335 |  2.61194029850746
………..
     18904 |        127 |  97.2972972972973 |  47.3880597014925
     18801 |        128 |  97.1631205673759 |  47.7611940298507
     16851 |        129 |  97.1428571428571 |   48.134328358209
     17321 |        130 |  97.0043198249512 |  48.5074626865672
     17136 |        131 |                97 |  48.8805970149254
     17719 |        132 |  96.9791612263018 |  49.2537313432836
     17688 |        133 |   96.969696969697 |  49.6268656716418
     18872 |        134 |  96.9333333333333 |                50
     17312 |        135 |  96.8181818181818 |  50.3731343283582
……………..
     17829 |        220 |  60.2721026527734 |   82.089552238806
     17332 |        221 |  60.0276625172891 |  82.4626865671642
     18493 |        222 |                60 |  82.8358208955224
     17757 |        223 |  59.7222222222222 |  83.2089552238806
     17586 |        224 |  59.4827586206897 |  83.5820895522388

Điều này cho chúng ta biết rằng ít nhất 50% các bảng có tỷ lệ truy cập lớn hơn 96,93% và 83,5% các bảng có tỷ lệ truy cập tốt hơn 59,4%

Pg_statio_ [user | sys | all] _indexes

Chế độ xem này chứa thông tin về lượt đọc / lượt truy cập của khối cho các chỉ mục.

Pg_stat_database

Dạng xem này chứa một hàng cho mỗi cơ sở dữ liệu. Nó hiển thị một số thông tin của các chế độ xem trước được tổng hợp vào toàn bộ cơ sở dữ liệu (khối đọc, khối lần truy cập, thông tin về bộ nhớ), một số thông tin liên quan đến toàn bộ cơ sở dữ liệu (tổng số lần giao dịch, tệp tạm thời, xung đột, deadclocks, thời gian đọc / ghi) và cuối cùng là số lượng phụ trợ hiện tại.

Những thứ cần tìm ở đây là tỷ lệ blks_hit / (blks_hit + blks_read) :giá trị càng cao càng tốt cho I / O của hệ thống. Tuy nhiên, các lần bỏ sót không nhất thiết phải được tính cho các lần đọc đĩa vì chúng có thể đã được phục vụ rất tốt bởi bộ đệm tệp của hệ điều hành.

Tương tự như các chế độ xem thống kê được thu thập khác được đề cập ở trên, người ta nên tạo phiên bản có dấu thời gian của pg_stat_database xem và có cái nhìn về sự khác biệt giữa hai ảnh chụp nhanh liên tiếp:

Số lần quay lại có tăng không?
Hay số lượng giao dịch đã cam kết?
Có phải chúng ta đang gặp nhiều xung đột hơn ngày hôm qua không (điều này áp dụng cho các trường hợp chờ)?
Chúng ta có số lần bế tắc cao bất thường không?

Tất cả đó là những dữ liệu rất quan trọng. Hai điều đầu tiên có thể có nghĩa là một số thay đổi trong một số kiểu sử dụng, điều đó phải được giải thích. Số lượng xung đột cao có thể có nghĩa là bản sao cần một số điều chỉnh. Số lượng deadlock cao là không tốt vì nhiều lý do. Không chỉ hiệu suất thấp do các giao dịch được khôi phục lại, mà còn nếu một ứng dụng gặp phải sự cố trong một cấu trúc liên kết chính duy nhất, thì các vấn đề sẽ chỉ được khuếch đại nếu chúng ta chuyển sang đa chủ. Trong trường hợp này, bộ phận kỹ thuật phần mềm phải viết lại các đoạn mã gây ra sự cố.

Khóa

Tài nguyên liên quan ClusterControl cho PostgreSQL Cách quản lý và giám sát máy chủ Postgres hiện có của bạn Cách đánh giá hiệu suất PostgreSQL

Khóa là một chủ đề rất quan trọng trong PostgreSQL và xứng đáng với (các) blog của riêng nó. Tuy nhiên, việc giám sát ổ khóa cơ bản phải được thực hiện giống như các khía cạnh giám sát khác được trình bày ở trên. pg_locks chế độ xem cung cấp thông tin thời gian thực về các ổ khóa hiện tại trong hệ thống. Chúng tôi có thể bắt gặp các ổ khóa chờ đợi lâu bằng cách đặt log_lock_waits , khi đó thông tin về các lần chờ đợi lâu sẽ được ghi vào nhật ký PgSQL. Nếu chúng tôi nhận thấy khóa cao bất thường dẫn đến việc chờ đợi lâu, sau đó một lần nữa, như trong trường hợp với bế tắc được đề cập ở trên, các kỹ sư phần mềm phải xem xét bất kỳ đoạn mã nào có thể gây ra khóa bị giữ lâu, ví dụ:khóa ứng dụng rõ ràng (BẢNG KHÓA hoặc CHỌN… ĐỂ CẬP NHẬT).

Tương tự như trường hợp bị khóa, một hệ thống có khóa ngắn sẽ dễ dàng chuyển sang thiết lập đa tổng thể hơn.