Quản lý cơ sở dữ liệu không phải là một nhiệm vụ nhỏ và có thể dễ dàng khiến bạn bực bội nếu không biết điều gì đang xảy ra. Cho dù cố gắng tìm hiểu xem các chỉ mục mới có hữu ích hay không, số lượng giao dịch trên cơ sở dữ liệu tại một thời điểm nhất định hoặc ai được kết nối với cơ sở dữ liệu tại bất kỳ thời điểm nào, dữ liệu cho phép quản trị viên thực sự biết cơ sở dữ liệu của họ đang hoạt động như thế nào. May mắn thay, với PostgreSQL, dữ liệu cho tất cả những điều này có sẵn trong danh mục hệ thống PostgreSQL.
Danh mục hệ thống PostgreSQL là một lược đồ có các bảng và dạng xem chứa siêu dữ liệu về tất cả các đối tượng khác bên trong cơ sở dữ liệu và hơn thế nữa. Với nó, chúng ta có thể khám phá khi nào các hoạt động khác nhau xảy ra, cách truy cập các bảng hoặc chỉ mục và thậm chí hệ thống cơ sở dữ liệu có đang đọc thông tin từ bộ nhớ hay cần tìm nạp dữ liệu từ đĩa.
Ở đây chúng ta sẽ đi qua một cái nhìn tổng quan về danh mục hệ thống và làm nổi bật cách đọc nó cũng như cách lấy thông tin hữu ích từ nó. Một số siêu dữ liệu rất đơn giản, còn các phần khác thì mất một chút thời gian để tạo ra thông tin hữu ích thực sự. Dù bằng cách nào, PostgreSQL cung cấp cho chúng ta một nền tảng tuyệt vời để xây dựng bất kỳ thông tin nào chúng ta cần về chính cơ sở dữ liệu đó.
Danh mục PostgreSQL
PostgreSQL lưu trữ thông tin siêu dữ liệu về cơ sở dữ liệu và cụm trong lược đồ ‘pg_catalog’. Thông tin này được chính PostgreSQL sử dụng một phần để theo dõi mọi thứ, nhưng nó cũng được trình bày để những người / quy trình bên ngoài cũng có thể hiểu được bên trong cơ sở dữ liệu.
Danh mục PostgreSQL có một quy tắc khá chắc chắn:Nhìn, không chạm vào. Mặc dù PostgreSQL lưu trữ tất cả thông tin này trong các bảng giống như bất kỳ ứng dụng nào khác, nhưng dữ liệu trong các bảng được quản lý hoàn toàn bởi chính PostgreSQL và không được sửa đổi trừ khi trường hợp khẩn cấp tuyệt đối và thậm chí sau đó có khả năng xây dựng lại theo thứ tự.
Chúng ta sẽ xem xét một số bảng danh mục hữu ích, cách đọc dữ liệu và những điều thông minh mà chúng ta có thể làm với chính dữ liệu. Có khá nhiều bảng trong danh mục mà chúng tôi sẽ không xem qua, nhưng bạn có thể tìm thấy tất cả thông tin về các bảng khác nhau này tại tài liệu chính thức của PostgreSQL.
Siêu dữ liệu toàn hệ thống
Một phần tốt của các bảng mà chúng tôi có thể truy vấn trong danh mục là các bảng "trên toàn hệ thống", trong đó không quan trọng chúng tôi được kết nối với cơ sở dữ liệu nào, dữ liệu đại diện cho toàn bộ cụm, không có cơ sở dữ liệu riêng lẻ nào.
Thông tin cơ sở dữ liệu
Thông tin cơ sở dữ liệu chung được lưu trữ trong pg_database và thống kê được lưu trữ trong pg_stat_database.
pg_database:
postgres=# SELECT oid,* FROM pg_database WHERE datname = 'severalnines';
-[ RECORD 1 ]-+-------------
oid | 16396
datname | severalnines
datdba | 10
encoding | 6
datcollate | en_US.UTF-8
datctype | en_US.UTF-8
datistemplate | f
datallowconn | t
datconnlimit | -1
datlastsysoid | 13804
datfrozenxid | 548
datminmxid | 1
dattablespace | 1663
datacl |Bảng pg_database chứa một hàng cho mọi cơ sở dữ liệu trong cụm, bao gồm ba hàng xuất phát từ hộp (postgres, template0 và template1). Hàng này chứa thông tin về mã hóa, giới hạn kết nối và siêu dữ liệu cơ bản khác.
Các cột quan tâm:
oid - Định danh đối tượng, không xuất hiện trong đầu ra truy vấn trừ khi được tham chiếu trực tiếp. Số này sẽ khớp với một thư mục trong thư mục dữ liệu cụm
datname - Tên của cơ sở dữ liệu.
datdba - Chủ sở hữu của cơ sở dữ liệu, oid tham chiếu pg_authid Mã hóa .oid.
- Mã hóa ký tự cho cơ sở dữ liệu này, pg_encoding_to_char () sẽ chuyển đổi thành tên có thể đọc được.
datconnlimit - Số lượng tối đa các kết nối đồng thời được phép trên cơ sở dữ liệu.
dattablespace - The không gian bảng mặc định cho cơ sở dữ liệu này, tham chiếu pg_tablespace.oid.
pg_stat_database:
postgres=# SELECT * FROM pg_stat_database WHERE datname = 'severalnines';
-[ RECORD 1 ]--+------------------------------
datid | 13805
datname | postgres
numbackends | 2
xact_commit | 477460
xact_rollback | 13
blks_read | 417
blks_hit | 16488702
tup_returned | 252376522
tup_fetched | 2637123
tup_inserted | 114
tup_updated | 3
tup_deleted | 1
conflicts | 0
temp_files | 0
temp_bytes | 0
deadlocks | 0
blk_read_time | 0
blk_write_time | 0
stats_reset | 2018-02-04 19:52:39.129052+00Bảng thống kê này là nơi chúng tôi nhận được dữ liệu thú vị và hữu ích. Mỗi hàng trong bảng này chứa dữ liệu trực tiếp cho từng cơ sở dữ liệu và có thể được xuất định kỳ để được theo dõi theo thời gian nếu muốn theo dõi các thay đổi.
Giao dịch
Thông tin giao dịch có thể được tìm thấy trong các cột xact_commit và xact_rollback, chứa số lượng giao dịch mà cơ sở dữ liệu đã cam kết và khôi phục lại tương ứng. Điều này sẽ giúp cho biết cơ sở dữ liệu đang hoạt động như thế nào, cũng như phát hiện các lỗi có thể xảy ra với các chương trình có thể đang lỗi / quay lại ở mức đáng báo động.
Quyền truy cập đĩa và bộ nhớ
Thông tin về việc dữ liệu có được truy xuất từ đĩa hoặc bộ nhớ hay không được lưu trữ trong các cột blks_read và blks_hit. Blks_read hiển thị số khối mà cơ sở dữ liệu này đọc từ đĩa, trong khi blks_hit hiển thị số khối được tìm thấy trong bộ đệm đệm của PostgreSQL (được biểu thị bằng tham số shared_buffers). Vì RAM nhanh hơn nhiều so với đĩa, lý tưởng nhất là chúng ta sẽ thấy blks_hit luôn cao hơn blks_read và nếu không, chúng ta có thể đánh giá lại bộ nhớ khả dụng của mình.
Tuples
Một số cột tiếp theo giải quyết các bộ giá trị. Tup_returned là số hàng được trả về trong cơ sở dữ liệu, là số hàng được đọc bằng cách quét tuần tự nếu từ một bảng hoặc số mục chỉ mục được trả về khi từ một chỉ mục ”. Tup_fetched là số hàng được tìm nạp trong cơ sở dữ liệu, có nghĩa là chúng là kết quả của quá trình quét bitmap, là số hàng trong bảng được tìm nạp bằng cách quét bitmap nếu từ một bảng hoặc các hàng trong bảng được tìm nạp bằng cách quét chỉ mục đơn giản nếu sử dụng một chỉ mục.
Chúng tôi cũng có tup_inserted, tup_updated và tup_deleted, đại diện cho số lượng bộ dữ liệu được chèn, cập nhật và xóa tương ứng trong cơ sở dữ liệu này. Điều này sẽ giúp hiểu cách dữ liệu đi vào, thay đổi và rời khỏi cơ sở dữ liệu. Vì các bộ giá trị được cập nhật và bị xóa dẫn đến các hàng chết, nên các giá trị cao trong các cột này sẽ gợi ý rằng các hoạt động autovacuum được điều chỉnh để đáp ứng nhu cầu của hoạt động cơ sở dữ liệu.
Xung đột
Nếu cơ sở dữ liệu được đề cập là một máy chủ dự phòng, thì xung đột cột sẽ hữu ích như một cách để theo dõi số lượng truy vấn đã bị hủy do xung đột với chế độ chờ ở 'chế độ khôi phục'. Nếu không phải là một cụm dự phòng, cột này có thể được bỏ qua.
Tệp / dữ liệu tạm thời
Đôi khi, các truy vấn sẽ cần phải ghi vào các tệp tạm thời. Điều này có thể xảy ra khi lượng work_mem được phân bổ cho kết nối đã được sử dụng hết và cần tiếp tục thao tác sắp xếp trên đĩa chứ không phải trong bộ nhớ. Cột temp_files theo dõi số lượng các tệp này đã được tạo và temp_byte theo dõi tổng kích thước của tất cả các tệp tạm thời được sử dụng. Dữ liệu này có thể giúp thông báo về việc điều chỉnh work_mem hoặc thậm chí tìm các truy vấn có thể sử dụng tính năng ghi lại nếu kích thước tệp tạm thời quá lớn.
Bế tắc
Cột deadlocks theo dõi số lần deadlock xảy ra. Vì bế tắc có thể gây ra lỗi cho các truy vấn mà nếu không sẽ không xảy ra lỗi, bạn nên theo dõi điều này và đảm bảo các ứng dụng không dẫm chân nhau.
Thời gian đọc và ghi
Các cột blk_read_time và blk_write_time theo dõi tổng số mili giây mà phần phụ trợ trong cơ sở dữ liệu dành để đọc và ghi dữ liệu, điều này có thể hữu ích nếu bạn cố gắng so sánh / cải thiện tốc độ đọc / ghi của đĩa
Đặt lại số liệu thống kê
Cột này, stats_reset, chỉ hiển thị dấu thời gian (với múi giờ) của lần cuối cùng các thống kê được đề cập trong hàng này được đặt lại. Giá trị null có nghĩa là chúng chưa được đặt lại kể từ khi bắt đầu hoặc thậm chí có thể là sự cố cơ sở dữ liệu có thể đã xóa sạch các số liệu thống kê này.
Checkpoints và The Background Writer
pg_stat_bgwriter
postgres=# SELECT * FROM pg_stat_bgwriter;
-[ RECORD 1 ]---------+------------------------------
checkpoints_timed | 47829
checkpoints_req | 2
checkpoint_write_time | 7323
checkpoint_sync_time | 38
buffers_checkpoint | 76
buffers_clean | 0
maxwritten_clean | 0
buffers_backend | 5
buffers_backend_fsync | 0
buffers_alloc | 440
stats_reset | 2018-02-04 19:52:34.712832+00Cụm PostgtreSQL quản lý việc ghi dữ liệu vào đĩa theo một số cách khác nhau. Về ‘bộ đệm bẩn’ (dữ liệu trong bộ nhớ đã được thay đổi kể từ khi đọc từ đĩa, nhưng vẫn chưa ghi thay đổi đó vào đĩa), điều này được thực hiện bởi một trạm kiểm soát hoặc trình ghi nền. Vì bộ đệm bẩn phải được ghi vào đĩa trước khi nó có thể được giải phóng hoặc phân bổ lại, nên việc đảm bảo các quy trình này được tinh chỉnh là rất quan trọng và bảng này giúp làm sáng tỏ cách hoạt động của tất cả.
Trạm kiểm soát
Một điểm kiểm tra xảy ra đúng lịch trình (được biểu thị bằng tham số checkpoint_timeout) hoặc khi lượng tệp WAL tối đa đã được sử dụng kể từ điểm kiểm tra cuối cùng và cần phải thực hiện một điểm kiểm tra. Dù bằng cách nào, một trạm kiểm soát ghi các bộ đệm bẩn vào đĩa và có bốn cột theo dõi nó.
Các cột checkpoints_timed và checkpoints_req hiển thị số lượng các điểm kiểm tra theo lịch trình xảy ra (theo thời gian) và số lượng các điểm kiểm tra được yêu cầu (còn được gọi là bắt buộc). Giá trị leo cao của checkpoint_req có thể gợi ý không đủ giá trị max_wal_size.
Các cột checkpoint_write_time và checkpoint_sync_time ghi lại tổng lượng thời gian (tính bằng mili giây) mà quá trình checkpoint đã dành để ghi và đồng bộ hóa vào đĩa.
Cuối cùng, buffers_checkpoint là tổng số bộ đệm được ghi vào đĩa bởi các điểm kiểm tra.
Trình viết nền
Trình ghi nền là một quy trình riêng biệt ghi các bộ đệm bẩn vào đĩa, lý tưởng là làm giảm số lượng công việc mà người kiểm tra cần thực hiện.
Cột buffers_clean đại diện cho số lượng bộ đệm được ghi vào đĩa bởi tiến trình nền. Khi so sánh với buffers_checkpoint, nó cho biết lượng công việc được xử lý bởi mỗi quy trình (với kiến thức bổ sung rằng người viết nền có khả năng ghi các vùng đệm nhiều lần nếu chúng thay đổi thường xuyên, so với ít thường xuyên hơn với một điểm kiểm tra định thời).
Maxw write_clean đại diện cho số lần trình viết nền đạt đến số trang tối đa để xóa mỗi lần chạy (được kiểm soát bằng tham số bgwriter_lru_maxpages).
Bộ đệm nói chung
Các cột còn lại hiển thị cho chúng ta thông tin bộ đệm chung, với buffers_backend là số bộ đệm mà một chương trình phụ trợ phải tự ghi, thay vì trình ghi nền hoặc điểm kiểm tra, buffers_backend_fsync là số lần một chương trình phụ trợ phải thực hiện lệnh gọi fsync của chính nó và Buffers_alloc hiển thị số lượng bộ đệm đã được cấp phát nói chung.
Hoạt động và khóa cơ sở dữ liệu
Có hai chế độ xem hiển thị hoạt động hiện tại của người dùng, pg_stat_activity và pg_locks. Khi được truy vấn, các kết nối này hiển thị thông tin về các kết nối hiện tại với cơ sở dữ liệu và loại khóa mà chúng có đối với các mối quan hệ nào.
pg_stat_activity
postgres=# SELECT * FROM pg_stat_activity;
-[ RECORD 1 ]----+--------------------------------
datid | 13805
datname | severalnines
pid | 29730
usesysid | 10
usename | postgres
application_name | psql
client_addr |
client_hostname |
client_port | -1
backend_start | 2018-07-21 02:29:48.976588+00
xact_start | 2018-07-21 02:30:03.73683+00
query_start | 2018-07-21 02:30:03.73683+00
state_change | 2018-07-21 02:30:03.736835+00
wait_event_type |
wait_event |
state | active
backend_xid |
backend_xmin | 559
query | SELECT first_name FROM customers WHERE customers_sid = 472;
backend_type | client backendThông tin chung
Dạng xem pg_stat_activity hiển thị một hàng cho mọi kết nối đến cơ sở dữ liệu và một số thông tin cơ bản về nó. Tên dữ liệu cột đại diện cho cơ sở dữ liệu mà kết nối thực sự được kết nối với, pid là ID quy trình của kết nối trên chính máy chủ cơ sở dữ liệu, và useysid và tên sử dụng đại diện cho cơ sở dữ liệu mà người dùng được kết nối.
Đối với nguồn của máy khách, client_addr là địa chỉ IP của máy chủ mà kết nối đến, null có nghĩa là đó là kết nối ổ cắm unix cục bộ.
Dấu thời gian
Có bốn cột dấu thời gian hiển thị khi một số thứ nhất định bắt đầu:backend_start là khi kết nối thực sự được thiết lập, xact_start là khi giao dịch hiện tại bắt đầu (null nếu khách hàng không có giao dịch đang mở), query_start là khi truy vấn hiện tại hoặc gần đây nhất bắt đầu, và state_change là thời điểm trạng thái của kết nối thay đổi lần cuối.
Trạng thái kết nối
Các bit cuối cùng của pg_stat_activity bao gồm trạng thái thực tế của kết nối. Nếu truy vấn đang đợi một truy vấn khác để giải phóng các khóa, thì wait_event_type chứa một số thông tin về loại sự kiện chờ đó là gì và cột wait_event sẽ hiển thị tên sự kiện chờ. Đó là một danh sách dài, nhưng bạn có thể tìm thấy thêm thông tin tại tài liệu PostgreSQL.
Cuối cùng, cột ‘trạng thái’ hiển thị trạng thái kết nối hiện tại, chẳng hạn như hoạt động, không hoạt động, không hoạt động trong giao dịch và cột truy vấn sẽ hiển thị truy vấn thực tế đang được chạy hoặc chạy gần đây nhất.
pg_lock
SELECT * FROM pg_locks;
-[ RECORD 1 ]------+----------------
locktype | virtualxid
database |
relation |
page |
tuple |
virtualxid | 3/475862
transactionid |
classid |
objid |
objsubid |
virtualtransaction | 3/475862
pid | 29730
mode | ExclusiveLock
granted | t
fastpath | tBảng pg_locks hoạt động song song với pg_stat_activity nếu xem xét hoạt động truy vấn. Bất cứ khi nào khóa được thực hiện đối với một quan hệ, thông tin đó sẽ được lưu trữ trong pg_locks. Sử dụng pid từ pg_stat_activity, chúng tôi có thể truy vấn pg_locks để xem mối quan hệ nào mà một kết nối có thể có khóa, loại khóa đó là gì và khóa đã được cấp hay chưa.
Các cột quan trọng nhất là "pid", khớp với pid từ pg_stat_activity, "quan hệ" khớp với OID từ pg_class, "chế độ" hiển thị tên của chế độ khóa được giữ và "được cấp" cho biết có khóa trong hay không câu hỏi đã được cấp.
Thông tin sao chép
Vì PostgreSQL đã tích hợp sẵn các tính năng sao chép, nên có một số quan điểm làm sáng tỏ về hiệu suất và trạng thái của chính quá trình sao chép.
Xem pg_stat_replication: chứa một hàng cho mọi quy trình của người gửi WAL, chứa thông tin về trạng thái của nó, vị trí của các tệp WAL mà nó đang làm việc và thông tin kết nối của máy chủ dự phòng đang nhận dữ liệu WAL để sao chép.
Xem pg_stat_wal_receiver: Nếu cụm ở chế độ chờ, thì cụm này sẽ chứa một hàng hiển thị số liệu thống kê về quá trình máy nhận hình thành máy chủ.
Xem pg_stat_subscription: Nếu gửi dữ liệu WAL đến một nút chờ, mỗi hàng ở đây sẽ đại diện cho đăng ký đó và chứa thông tin về trạng thái của các đăng ký.
Xem pg_replication_slots: Chứa danh sách tất cả các vị trí sao chép tồn tại trên cụm và trạng thái hiện tại của chúng.
Siêu dữ liệu cụ thể cho cơ sở dữ liệu
Bên trong mỗi cơ sở dữ liệu có một bộ sưu tập các bảng danh mục có thông tin cụ thể cho cơ sở dữ liệu đang được truy vấn. Nếu chúng tôi đang tìm kiếm dữ liệu cụ thể từ các bảng này, chúng tôi phải đảm bảo rằng chúng tôi được kết nối với cơ sở dữ liệu phù hợp khi chúng tôi đưa ra các truy vấn.
Đây là nơi trọng tâm của phân tích dữ liệu, nơi chúng ta có thể xem cách dữ liệu người dùng của chúng ta đang được truy cập. Từ bảng, đến chỉ mục, đến chuỗi, các truy vấn đi vào cơ sở dữ liệu và tìm nạp hoặc sửa đổi dữ liệu, các hành động và tác động của chúng sẽ được lưu trữ trong các bảng này và chúng ta có thể xem xét thông tin đó để đưa ra quyết định sáng suốt về việc quản lý cơ sở dữ liệu. đường.
Siêu dữ liệu bảng
Siêu dữ liệu về bảng người dùng của chúng tôi được lưu trữ trong hai bảng sau và chúng có một hàng cho mỗi bảng người dùng được tạo trong hệ thống. Bảng pg_stat_user_tables chứa thống kê về quyền truy cập của người dùng vào bảng, trong khi pg_statio_user_tables chứa thống kê I / O cho mỗi bảng.
LƯU Ý:Dữ liệu trong đây không phải lúc nào cũng hoàn hảo 100% và dựa vào các phân tích thường xuyên về các bảng mới chính xác. Tự động phân tích bao gồm điều này, nhưng hãy điều chỉnh tốt quy trình tự động phân tích để nó có thể giữ số liệu thống kê tốt về mỗi bảng. Nếu thống kê dường như bị tắt, chạy ANALYZE theo cách thủ công trên bảng sẽ làm mới chúng.
Bảng pg_stat_user_tables:
severalnines=> SELECT * FROM pg_stat_user_tables WHERE schemaname = 'public' AND relname = 'history';
-[ RECORD 1 ]-------+---------
relid | 2766788
schemaname | public
relname | history
seq_scan | 13817
seq_tup_read | 466841
idx_scan | 12251
idx_tup_fetch | 127652
n_tup_ins | 11
n_tup_upd | 13
n_tup_del | 3
n_tup_hot_upd | 13
n_live_tup | 3
n_dead_tup | 21
n_mod_since_analyze | 19
last_vacuum |
last_autovacuum |
last_analyze |
last_autoanalyze |
vacuum_count | 0
autovacuum_count | 0
analyze_count | 0
autoanalyze_count | 0Đối với thống kê bảng người dùng của chúng tôi, chúng tôi có khá nhiều dữ liệu.
Phương thức truy cập bảng
Khi khách hàng truy cập dữ liệu từ bảng, nó sẽ làm như vậy trực tiếp hoặc thông qua các chỉ mục. Cột ‘seq_scan’ đếm số lần quét tuần tự mà bảng nhận được và ‘seq_tup_read’ đếm số bộ giá trị được đọc trong quá trình đó. Cột ‘idx_scan’ đếm số lần một chỉ mục trên bảng được sử dụng để tìm nạp dữ liệu.
Hoạt động Tuple Bảng
Giờ đây, chúng tôi có một số cột đếm các hoạt động khác nhau trên bảng.
‘N_tup_ins’ theo dõi số bộ giá trị được chèn vào
‘N_tup_upd’ theo dõi số lượng bộ giá được cập nhật
‘N_tup_del’ theo dõi số bộ giá trị đã bị xóa
Trạng thái bảng Tuple
Do các bản cập nhật và xóa, có thể có các bộ dữ liệu đã chết không còn hoạt động nữa và quá trình chân không cuối cùng sẽ giải phóng chúng. Các cột ‘n_tup_ins’ và ‘n_tup_ins’ lần lượt theo dõi số lượng bộ giá trị còn sống và đã chết. Khi bộ giá trị chết đạt đến một điểm nhất định, autovacuum sẽ được khởi chạy, tùy thuộc vào cài đặt autovacuum.
Hoạt động hút chân không trên bàn
Việc bảo trì bảng được thực hiện thông qua VACUUM hoặc AUTOVACUUM và số liệu thống kê được thu thập thông qua ANALYZE hoặc AUTOANALYZE. Bốn cột tiếp theo chứa ngày khi mỗi hoạt động này được chạy lần cuối:‘last_vacuum’, ‘last_autovacuum’, ‘last_analyze’, ‘last_autoanalyze’.
Chúng tôi cũng có bốn cột thuận tiện hơn chỉ đơn giản là đếm số lần các hành động trước đó xảy ra. Bằng cách sử dụng các bảng này, chúng tôi có thể xem bảng nào nhận được nhiều hoạt động nhất:‘uum_count ’,‘ autovacuum_count ’,‘ analysis_count ’và‘ autoanalyze_count ’.
Bảng pg_statio_user_tables:
severalnines=> SELECT * FROM pg_statio_user_tables WHERE schemaname = 'public' AND relname = history;
-[ RECORD 1 ]---+---------
relid | 2766788
schemaname | public
relname | history
heap_blks_read | 4
heap_blks_hit | 63081
idx_blks_read | 5
idx_blks_hit | 44147
toast_blks_read | 0
toast_blks_hit | 0
tidx_blks_read | 0
tidx_blks_hit | 0Đầu ra I / O hữu ích để giúp hiểu cách dữ liệu đang được truy cập dưới vỏ bọc. Cột ‘heap_blks_read’ đại diện cho số khối đĩa được đọc cho bảng này và ‘heap_blks_hit’ biểu thị các khối đệm được đọc từ bộ nhớ trên bảng này. Điều này rất hữu ích để biết liệu các truy vấn truy cập bảng liên tục phải vào đĩa hay tìm nạp dữ liệu từ bộ nhớ.
Thống kê chỉ mục trên bảng hiển thị cùng một thông tin với các cột ‘idx_blks_read’ và ‘idx_blks_hit’.
Cuối cùng, nếu bảng có bất kỳ bảng TOAST nào, các cột ‘toast_blks_hit’ và ‘toast_blks_read’ sẽ theo dõi các bảng bánh mì nướng, trong khi ‘tdix_blks_read’ và ‘tdix_blks_read’ theo dõi các chỉ mục trên các bảng bánh mì nướng đó.
Siêu dữ liệu chỉ mục
pg_stat_user_indexes
severalnines=> SELECT * FROM pg_stat_user_indexes WHERE indexrelname = 'history_pkey';
-[ RECORD 1 ]-+-------------
relid | 2766797
indexrelid | 2766934
schemaname | public
relname | history
indexrelname | history_pkey
idx_scan | 43910
idx_tup_read | 98147
idx_tup_fetch | 98147Cũng giống như bảng đối chiếu, bảng này chứa thông tin cụ thể về các chỉ mục. Một hàng trên mỗi chỉ mục, bảng này cho biết số lần chỉ mục được quét bằng cột ‘idx_scan’, bao nhiêu bộ giá trị đã được đọc với ‘idx_tup_read’ và bao nhiêu hàng trực tiếp thực sự được tìm nạp bằng ‘idx_tup_fetch’.
pg_statio_user_indexes
severalnines=> SELECT * FROM pg_statio_user_indexes WHERE indexrelname = 'history_pkey';
-[ RECORD 1 ]-+-------------
relid | 2766797
indexrelid | 2766934
schemaname | public
relname | history
indexrelname | history_pkey
idx_blks_read | 2
idx_blks_hit | 49380Đối với pg_statio_user_indexes, hai cột có sẵn cho dữ liệu là ‘idx_blks_read’ và ‘idx_blks_hit’, đại diện cho số khối được đọc từ đĩa và từ bộ nhớ.
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ứcChúng ta có thể làm gì với dữ liệu này?
Sáng tạo! Nếu các truy vấn đến một bảng cụ thể có vẻ cực kỳ chậm, hãy theo dõi hoạt động của bảng đó theo thời gian, xem nó nhận được bao nhiêu lần quét tuần tự so với lần quét chỉ mục, xem liệu bảng đó sẽ vào đĩa hay bộ nhớ để lấy dữ liệu.
Nếu một bảng lớn liên tục bị autovacuum thường xuyên, hãy theo dõi các bộ dữ liệu sống đến chết theo thời gian, có thể nó đặc biệt cần chỉnh autovacuum để có thể hoàn thành nhanh hơn hoặc thậm chí có thể bảng là một ứng cử viên cho việc phân vùng.
Vì chúng tôi có thể biết khi nào dữ liệu đến từ đĩa hoặc bộ nhớ, chúng tôi có thể tạo tỷ lệ bộ nhớ trên đĩa theo thời gian, xác định chính xác nếu bất kỳ lúc nào tỷ lệ này giảm xuống trong ngày.
Số lượng bảng mà chúng tôi đã đề cập đến là những thông tin quan trọng nhất, dữ liệu chính hữu ích để biết về hoạt động bên trong của cơ sở dữ liệu. Tuy nhiên, có nhiều bảng khác trong danh mục hệ thống chứa dữ liệu hữu ích theo tình huống. Việc đọc các bảng khác như trước đây sẽ giúp cung cấp thông tin chi tiết về tình trạng của cơ sở dữ liệu nói chung.
Để biết thêm thông tin về bất kỳ bảng hoặc dạng xem nào trong Danh mục PostgreSQL, hãy truy cập tài liệu chính thức tại đây, cũng như thông tin về bộ thu thập thống kê tại đây.
