Theo dõi PostgreSQL với hiệu suất

Tiện ích cấu hình perf đi kèm với nhân Linux cực kỳ hữu ích để kiểm tra hành vi trên toàn hệ thống và đa quy trình - nhưng nó còn làm được nhiều điều hơn so với cấu hình CPU mà nó thường được sử dụng. Có thể bạn đã xem perf top -az hoặc perf top -u postgres nhưng đó chỉ là phần nhỏ nhất của những gì nó có thể làm. (Nếu bạn muốn phiên bản TL / DR, hãy chuyển xuống "Đầu dò động không gian người dùng").

Một trong những lợi thế lớn của perf là nó không xâm nhập. Bạn không phải đính kèm trình gỡ lỗi và làm gián đoạn quá trình thực thi. Bạn không cần phải chạy các lệnh trực tiếp bên dưới một hồ sơ trong một môi trường đặc biệt. Không cần khởi động lại máy chủ để gỡ lỗi khối lượng công việc có vấn đề và thường không cần biên dịch lại với các tùy chọn gỡ lỗi. Điều này cực kỳ hữu ích khi bạn đang cố gắng theo dõi các vấn đề về hiệu suất trong một hệ thống trực tiếp, vì nó cho phép bạn kiểm tra các lý thuyết về những gì có thể đang diễn ra một cách nhanh chóng và với tác động tối thiểu.

perf không chỉ là một hồ sơ, nó còn có hỗ trợ theo dõi. Việc lập hồ sơ dựa trên việc lấy mẫu trạng thái của hệ thống khi được kích hoạt bởi bộ đếm hiệu suất phần cứng hoặc phần mềm; nó cung cấp một mẫu thống kê về các điểm mà hệ thống dành nhiều thời gian nhất. Thay vào đó, việc theo dõi sẽ lấy mẫu bất cứ khi nào một sự kiện theo dõi cụ thể xảy ra, vì vậy, nó hữu ích hơn nhiều đối với các sự kiện không thường xuyên nhưng quan trọng.

Khi làm việc với PostgreSQL, một trong những tính năng thú vị nhất của perf là khả năng theo dõi các quy trình không gian người dùng . Bạn muốn biết tần suất PostgreSQL của bạn hoán đổi các phân đoạn WAL, tần suất tra cứu khóa ngoại, v.v.? Đối với một chương trình phụ trợ PostgreSQL hay trên toàn bộ cụm? perf có thể giúp bạn với điều đó.

Các điểm theo dõi không gian người dùng và không gian nhân có thể được trộn lẫn và có thể được sử dụng cùng lúc với việc lập hồ sơ bộ đếm hiệu suất để giúp bạn có được bức tranh tốt về hệ thống. perf có thể ghi lại dấu vết ngăn xếp từ cả nhân và không gian người dùng, và cũng có thể thực hiện trực quan hóa thống kê. Các điểm theo dõi không gian người dùng được tạo bằng các đầu dò động; kernel-space có thể được xác định trước hoặc có thể là các đầu dò động.

Vậy, bạn sử dụng một số tính năng này như thế nào?

Cài đặt công cụ

Trước tiên, hãy đảm bảo rằng bạn đang sử dụng perf hiện tại . Bài báo này được viết trên Fedora 19 với perf 3.11.6 trên x86_64 và một số tính năng tương đối mới.

Nếu bạn muốn có kết quả ngăn xếp không gian người dùng, bạn sẽ muốn mã bạn đang xem được tạo bằng -Og -ggdb -fno-omit-frame-pointer . Nếu bạn đang sử dụng perf được xây dựng bằng libunwind bạn không cần con trỏ khung; xem bài đăng Stack Overflow này và RH Bugzilla # 1025603. Điều này là không cần thiết nếu bạn chỉ quan tâm đến dữ liệu phía hạt nhân. Nếu đang sử dụng các gói phân phối, bạn có thể cần cài đặt -debuginfo cả gói nữa.

Tất cả các bài kiểm tra sau đều được chạy với gói PGDG PostgreSQL 9.2 gốc từ http://yum.postgresql.org/ bằng cách sử dụng perf được xây dựng lại bằng libunwind hỗ trợ theo hướng dẫn trên.

Đầu dò và điểm theo dõi hạt nhân

perf có thể thu thập dữ liệu từ các điểm theo dõi hạt nhân được xác định trước, một số trong số đó có nhiều thông tin khi xem xét các vấn đề về phân mảnh bộ nhớ, I / O đĩa, v.v. Bạn có thể nhận danh sách các điểm theo dõi bằng sudo perf list . Danh sách điểm theo dõi có thể được chỉ định và hỗ trợ các ký tự đại diện. Ví dụ:nếu chúng ta muốn nhận số liệu thống kê ghi và xả đĩa trên phiên bản PostgreSQL đang chạy, chúng ta có thể chạy:

 sudo perf record -g lùn -e block:block_rq_issue, syscalls:sys_enter_fsync -u postgres sleep 10 

để nắm bắt dữ liệu. Thay vì ở chế độ ngủ, bạn có thể không sử dụng lệnh nào và nhấn Control-C khi chụp xong hoặc bạn có thể sử dụng một số lệnh khác như psql -c để kích hoạt khối lượng công việc bạn muốn đo lường.

-u postgres cấu hình tất cả các quy trình đang chạy với tư cách người dùng postgres . Thay vào đó, bạn có thể sử dụng -a để lập hồ sơ toàn hệ thống trên tất cả các CPU. Cũng có thể theo dõi chỉ một chương trình phụ trợ. Bắt đầu psql , chạy select pg_backend_pid () , chạy perf với -p $ the_pid , sau đó bắt đầu khối lượng công việc trong cùng một psql phiên.

Khi bạn đang làm việc với PostgreSQL, quy trình mục tiêu mặc định, là lệnh chạy dưới sự kiểm soát của perf , thường không hữu ích lắm vì phần phụ trợ thực hiện hầu hết công việc, chứ không phải psql . Vẫn hữu ích khi sử dụng lệnh con để kiểm soát khối lượng công việc thử nghiệm và thời gian.

Sau khi đã nắm bắt được dữ liệu, bạn có thể sử dụng báo cáo perf để kiểm tra nó. Có quá nhiều tùy chọn để thảo luận ở đây - để kiểm soát việc tổng hợp và đơn giản hóa kết quả, hiển thị dấu vết ngăn xếp, lời nguyền tương tác so với đầu ra báo cáo văn bản, v.v.

Lấy phiên này làm ví dụ, trong đó có phiên shell (terminal “T2”) và một phiên postgres được kết nối với cơ sở dữ liệu “regress” (terminal “T1”):

 T1 | regression => chọn pg_backend_pid (); T1 | pg_backend_pid T1 | ---------------- T1 | 4495T1 | (1 hàng) 

 T2 | $ sudo perf record -g lùn -e block:block_rq _ *, syscalls:sys_enter_write, syscalls:sys_enter_fsync -p 4495 

 T1 | regress => tạo bảng x khi chọn một FROM create_series (1.1000000) a; T1 | hồi quy => 

 T2 | $ ^ CT2 | [perf record:Thức dậy 332 lần để ghi dữ liệu] T2 | [bản ghi perf:Đã chụp và ghi 86,404 MB perf.data (~ 3775041 mẫu)] T2 | T2 | Báo cáo $ sudo perf -g 

Bạn có thể sử dụng báo cáo perf 'S nguyền rủa gui để tìm ra dấu vết hoặc bạn có thể sử dụng báo cáo perf --stdio tùy chọn để nó truyền dữ liệu sang stdout. Ví dụ:nếu bạn muốn dấu vết ngăn xếp, bạn có thể chạy:

 $ sudo perf report -g --stdio ... blah blah ... # Mẫu:1 trong số các sự kiện 'syscalls:sys_enter_fsync' # Số lượng sự kiện (ước chừng):1 ## Ký hiệu Đối tượng Chia sẻ Lệnh trên không # .. ...... ........ ............. ..................... # 100,00 % postgres libc-2.17.so [.] __GI___libc_fsync | --- __GI___libc_fsync mdimmedsync heap_sync intorel_shutdown standard_ExecutorRun ExecCreateTableAs PortalRunUtility PortalRunMulti PortalRun PostgresMain ServerLoop PostmasterMain main __libc_start_main _prestart (niahl ... 
 hiển thị điều đó cho sự kiện  syscalls:sys_enter_fsync  có một sự kiện với ngăn xếp trên, một fsync được gọi qua  ExecCreateTableAs  . 
 

 (Vì một lý do, tôi chưa thể ghim  fsync ()  cuối cùng có vẻ như không bị  perf  nắm bắt khi  psql  được điều hành trực tiếp dưới sự kiểm soát của  perf  . Đây không phải là vấn đề với  perf stat  , chỉ  bản ghi perf  . Đó là lý do tại sao tôi chuyển qua các vòng để chọn trước phần phụ trợ bằng cách pid ở trên.) 
 
 Đầu dò động không gian người dùng 
 

 Đôi khi bạn quan tâm đến điều gì đó xảy ra bên trong PostgreSQL hơn là các sự kiện bên trong hạt nhân được kích hoạt bởi PostgreSQL. Các phiên bản mới hơn của  perf  có thể trợ giúp việc này bằng cách chèn các điểm theo dõi động kích hoạt các cuộc gọi trong các chương trình không gian người dùng. 
 

 Giả sử bạn quan tâm đến việc xem hoạt động của WAL và muốn xem khi nào  XLogFlush  ,  XLogFileInit  hoặc  XLogFileOpen  được gọi là. Bạn có thể chèn các điểm theo dõi động cho các cuộc gọi này bằng  perf  :
 
 sudo perf thăm dò -x `mà postgres` XLogFileInitsudo perf thăm dò -x` nào postgres` XLogFileOpensudo perf probe -x `mà postgres` XLogFlush 
 

 Bạn chỉ có thể thăm dò các ký hiệu bên ngoài (không tĩnh, không bị ẩn bởi cờ -fvisibility) trừ khi bạn xây dựng bằng  -ggdb  .  perf  sẽ phàn nàn  không tìm thấy ký hiệu nào  nếu bạn cố gắng sử dụng một biểu tượng không tồn tại. Tại thời điểm viết bài  perf  không hỗ trợ sử dụng debuginfo bên ngoài để tra cứu các ký hiệu cho các đầu dò, mặc dù nó có thể sử dụng nó để phân tích ngăn xếp. Nói chung, nếu đó là một bên ngoài trong  src / include  bạn có thể sử dụng nó với  perf  . 
 

 Mỗi điểm theo dõi sẽ in tên của điểm theo dõi đã tạo và bạn có thể sử dụng  perf probe -l  để liệt kê tất cả chúng bằng mọi cách:
 
 $ sudo perf probe -l probe_postgres:XLogFileInit (trên 0x000000000009a360) probe_postgres:XLogFileOpen (trên 0x000000000009a860) probe_postgres:XLogFlush (trên 0x00000000000prea0670) 
 Các đầu dò này hiện có thể được sử dụng như các sự kiện hoàn hảo. Hãy xem hoạt động xlog trong một khối lượng công việc mẫu, theo dõi trên toàn bộ cụm trong khi tôi chạy pgbench:
 
 sudo perf record -g lùn -u postgres -e probe_postgres:XLogFileInit, probe_postgres:XLogFileOpen, probe_postgres:XLogFlush 
 

 Hãy tự mình thử với  perf report -g  . Đây là kết quả trông như thế nào. Bạn có thể sử dụng các tùy chọn như  -g fractal, 0  để kiểm soát chi tiết. Bạn sẽ có thể xem phần trăm số lần truy cập của một bộ đếm nhất định đến từ nhánh ngăn xếp này hay nhánh khác, quy trình và quy trình, v.v.  --sort  các tùy chọn cung cấp cho bạn nhiều quyền kiểm soát hơn đối với việc tổng hợp và nhóm. 
 
 Nhưng chờ đã, còn nhiều thứ nữa 
 

 Bạn cũng nên xem  perf stat  và  perf top  các lệnh. Họ có thể lấy các danh sách sự kiện giống như  bản ghi perf  , mặc dù vì một số lý do kỳ lạ, hỗ trợ bộ lọc quy trình của chúng khác nhau. 
 

 Dưới đây là một ví dụ chạy khối lượng công việc giả và xem xét các điểm theo dõi hạt nhân I / O trong quá trình chạy:
 
 $ sudo perf stat -e block:block_rq _ *, syscalls:sys_enter_write, syscalls:sys_enter_fsync -a -r 5 - psql -q -U postgres craig -c "thả bảng nếu tồn tại x; tạo bảng x khi chọn a FROM create_series (1.1000000) a; "; Thống kê bộ đếm hiệu suất cho bảng thả 'psql -U postgres craig -c nếu tồn tại x; tạo bảng x như chọn một FROM create_series (1.1000000) a; ' (5 lần chạy):0 khối:block_rq_abort [100.00%] 0 block:block_rq_requeue [100.00%] 97 block:block_rq_complete (+ - 14.82%) [100.00%] 96 block:block_rq_insert (+ - 14.97%) [100.00%] 98 block:block_rq_issue (+ - 14.67%) [100.00%] 0 block:block_rq_remap [100.00%] 10.607 syscalls:sys_enter_write (+ - 0.17%) [100.00%] 1 syscalls:sys_enter_fsync 0.908835058 - 18.31% + / pre> 

 Bạn có thể thấy nó đang thực hiện trung bình khoảng 100 yêu cầu I / O lớp khối trên 10k lượt ghi () và thực hiện một fsync (). Một phần trong số đó là tiếng ồn nền của hệ thống vì chúng tôi đang thực hiện tất cả việc lập hồ sơ hệ thống ( -a  ), nhưng vì hệ thống khá nhàn rỗi nên nó không nhiều và nó được tính trung bình trong năm lần chạy. 
 

 Tương tự, bằng cách sử dụng các đầu dò động mà chúng tôi đã thêm trước đó, hãy theo dõi hoạt động xlog trong quá trình chạy pgbench:
 
 $ sudo perf stat -e probe_postgres:XLogFileInit, probe_postgres:XLogFileOpen, probe_postgres:XLogFlush -a - /usr/pgsql-9.2/bin/pgbench -U postgres craig -c 2 -t 10000 sao chân không ... kết thúc. loại giao dịch:TPC-B (loại) hệ số tỷ lệ:Chế độ truy vấn 100:số lượng khách hàng đơn giản:2 số luồng:1 số lượng giao dịch trên mỗi khách hàng:10000 số lượng giao dịch thực sự được xử lý:20000 / 20000tps =715.854663 (bao gồm thiết lập kết nối) tps =716.092133 ( không bao gồm thiết lập kết nối) Thống kê bộ đếm hiệu suất cho '/usr/pgsql-9.2/bin/pgbench -U postgres craig -c 2 -t 10000':64 probe_postgres:XLogFileInit [100,00%] 0 probe_postgres:XLogFileOpen [100,00%] 55,440 probe_postgres:Thời gian XLogFlush 27,987364469 giây đã trôi qua 
 

 Còn nhiều việc bạn có thể làm, bao gồm cả việc nắm bắt trạng thái của các biến cục bộ bằng  perf probe  . Tôi sẽ viết một số ví dụ hữu ích về vấn đề đó sau. Trong thời gian chờ đợi, hãy chơi, khám phá và giải trí với một công cụ chẩn đoán mới. 
 

  Cập nhật: Michael Paquier gần đây đã viết một bài báo liên quan về cách truy tìm PostgreSQL với systemtap có thể được người đọc quan tâm. Bạn phải biên dịch lại Pg để sử dụng cách tiếp cận đó, nhưng cú pháp đẹp hơn và nó mang lại một số lợi thế khác.