IBAnalyst: những gì bạn có thể thấy tại Summary View

Dmitry Kuzmenko, cập nhật lần cuối 31-03-2014

Tóm tắt

Tài liệu này dành để giải thích thông tin trên trang “Summary view” của IBAnalyst và cách diễn giải thông tin này cho thống kê cơ sở dữ liệu của riêng bạn. Chúng tôi cũng đã thêm một số ví dụ về thống kê vào gói cài đặt để giúp bạn dễ dàng nghiên cứu tất cả các chi tiết kỹ thuật của thống kê InterBase. Chúng nằm trong thư mục Examples của bản cài đặt IBAnalyst.

Nếu bạn chưa biết Oldest transaction, Oldest snapshot, active và Next là gì, vui lòng đọc trước bài viết của Craig Stunz “Understanding Transactions Lifetime”:

http://blogs.teamb.com/craigstuntz/articles/UnderstandingTransactionLifetimes.aspx

Số giao dịch

Nếu bạn đã đọc bài viết Understanding Transaction Lifetimes, có thể bạn vẫn còn thắc mắc về các con số OIT/OST/OAT. Dưới đây là mô tả ngắn gọn:


Số	Giữ, …	Di chuyển về phía trước, …
Oldest transaction	khi giao dịch với số này bị rollback và có nhiều thay đổi dữ liệu trong đó, hoặc khi kết nối máy khách bị mất	khi sweep tự động hoặc thủ công thành công.
Oldest Snapshot	khi snapshot (hoặc read committed write trước IB 7.1) hoạt động trong một thời gian dài (nó ghi nhớ snapshot hoạt động lâu nhất như OST cục bộ của nó)	khi giao dịch mới bắt đầu, nếu giao dịch giữ OST kết thúc
Oldest Active	khi giao dịch với số này hoạt động trong một thời gian dài	khi giao dịch mới bắt đầu, nếu giao dịch giữ OAT kết thúc
Next	không bao giờ	khi giao dịch mới bắt đầu

lưu ý: Oldest transaction ở đây giống với Oldest Interesting Transaction (OIT), được nhắc đến trong nhiều bài viết khác.

Thống kê tốt với cài đặt tiêu chuẩn

Hãy khởi động IBAnalyst và mở (bằng menu Statistics/Load statistics from file) tệp !allok.txt.

IBAnalyst không chỉ báo cáo ngày tạo cơ sở dữ liệu mà còn nhận diện ngày giờ hiện tại trên máy chủ nếu thống kê được lấy qua Services API, hoặc ngày giờ của tệp nếu đó là tệp thống kê được tải lên.

Đó là lý do chúng tôi khuyên bạn không nên sửa đổi các tệp thống kê, vì trong trường hợp này IBAnalyst sẽ tính toán số giao dịch trung bình mỗi ngày không chính xác. Hàng Transactions per day ở đây hiển thị khoảng ~12500 giao dịch mỗi ngày và cơ sở dữ liệu đó “sống” từ khi tạo hoặc khôi phục được 8 ngày.

Oldest, Oldest snapshot, Oldest active và Next transactions ở đây ở trạng thái hoàn hảo, chúc bạn luôn có thống kê trông như thế này.

Nhiều giao dịch đang hoạt động

Tiếp theo, mở tệp !lotofactive.txt (bạn có thể nhìn lại hình !allok bất cứ lúc nào để so sánh các ví dụ sau với nó).

Ở đây hàng Active transactions được đánh dấu màu đỏ, vì có sự khác biệt lớn giữa Oldest active và Next transaction. Điều này có nghĩa là một số giao dịch tại thời điểm thống kê được lấy vẫn đang hoạt động và sau khi nó bắt đầu, 55.000 giao dịch đã bắt đầu (chúng có thể ở bất kỳ trạng thái nào - hoạt động, đã commit, đã rollback). Vì số giao dịch trung bình mỗi ngày là ~12500, IBAnalyst hiển thị cho bạn cảnh báo rằng một số giao dịch vẫn tồn tại trong 4,4 ngày. Điều này có thể xảy ra khi:

một số ứng dụng vẫn đang chạy và có ít nhất một giao dịch mở - một số người dùng có thể giữ ứng dụng chạy trong một thời gian dài
ứng dụng chạy trong một thời gian dài và mất các handle giao dịch - tức là mã của bạn (hoặc các thành phần/thư viện bạn sử dụng) khởi động giao dịch một cách động và trong một số trường hợp “quên” kết thúc chúng bằng rollback hoặc commit.
ứng dụng của bạn không sử dụng giao dịch tường minh (BDE), để việc xử lý giao dịch cho các thành phần được sử dụng. Kết quả là vòng đời giao dịch không được kiểm soát bởi ứng dụng và bạn có thể chắc chắn rằng hầu hết các giao dịch Next-OAT thực sự đang hoạt động.
ứng dụng của bạn sử dụng driver hoặc thành phần cho phép “giao dịch mặc định”. Nếu mã của bạn không kiểm soát giao dịch này, nó có thể chạy rất lâu.

Đáng tiếc là thống kê không hiển thị số lượng thực tế của các giao dịch đang hoạt động. Điều này chỉ có thể được xem trong InterBase 7.x bằng IBConsole, IB Performance Monitor hoặc qua truy vấn trực tiếp đến bảng hệ thống tạm thời tmp$transactions. Trong Firebird 1.5, bạn có thể gọi isc_database_info với tham số isc_info_active_transactions.

Sweeping

Bây giờ hãy mở !needsweep.txt.

Sweep là một quy trình bảo trì bên trong InterBase. Sweep duyệt tất cả các bản ghi trong cơ sở dữ liệu và cố gắng dọn dẹp tất cả các phiên bản rác, sau đó cố gắng đẩy số Oldest transaction lên. Trong cơ sở dữ liệu mới tạo, khoảng thời gian sweep mặc định là 20000. Khi sự khác biệt giữa các giao dịch (xem bảng bên dưới) trở nên lớn hơn khoảng thời gian sweep, sweep sẽ chạy tự động. Do đó, bạn có thể thấy sự suy giảm hiệu suất định kỳ trên cơ sở dữ liệu của mình. Ví dụ: ứng dụng của bạn hoạt động tốt trong Thứ Hai và Thứ Ba, nhưng đến Thứ Tư người dùng báo cáo về các vấn đề hiệu suất trong vài giờ, sau đó hiệu suất lại trở lại bình thường.

Nếu bạn thấy hành vi tương tự - đó là sweeping tự động.


Phiên bản máy chủ	Khi sweep chạy
InterBase 7.x	(Oldest Active - Oldest) > Khoảng thời gian sweep
InterBase 4.x, 5.x, 6.x, Firebird trước 1.5.2, Yaffil	(Oldest Snapshot - Oldest) > Khoảng thời gian sweep

Bảng 1. Điều kiện khi sweep tự động chạy

lưu ý: IBAnalyst tự động hiển thị thông tin Sweep gap chính xác cho tất cả các phiên bản. IBAnalyst chỉ có thể phát hiện sự khác biệt giữa các triển khai máy chủ bằng id ODS, ví dụ: InterBase 7.x có ODS 11.x, các máy chủ hiện đại khác có ODS 10.x. Nếu bạn chỉ làm việc với cơ sở dữ liệu Interbase 7.x (ODS 11), bạn có thể chuyển tùy chọn thích hợp trong hộp thoại Options.

Khi cơ sở dữ liệu của bạn có khoảng thời gian sweep <> 0, IBAnalyst về cơ bản đánh dấu hàng này màu vàng (cảnh báo bạn rằng sweep tự động có thể bắt đầu bất cứ lúc nào không thể đoán trước). Nói chung, 60% tất cả các ứng dụng gặp vấn đề với sweeping tự động. Cách dễ nhất để tránh vấn đề này là đặt khoảng thời gian sweep thành 0, dẫn đến việc tắt sweeping tự động. Tuy nhiên, nếu một số ứng dụng thực hiện nhiều thay đổi rồi rollback, Oldest transaction sẽ bị đóng băng và không di chuyển lên cho đến khi sweep được chạy. Vì trạng thái giao dịch hiệu quả được tính từ Oldest đến Next transaction, khoảng cách này sẽ tăng lên và hiệu suất sẽ giảm. Để ngăn điều này, bạn phải chạy sweep thủ công (gfix -sweep). Trong hình này, bạn có thể thấy hành vi khi khoảng thời gian sweep là 0 và có một giao dịch lớn bị rollback:

Ở đây giá trị sweep gap cho thấy một số giao dịch lớn (đã thực hiện nhiều thay đổi) đã bị rollback khoảng 4,5 ngày trước. Chúng tôi khuyên bạn nên chạy sweep thủ công mỗi ngày.

Tất nhiên, đối với 60% ứng dụng được đề cập, có lẽ tốt hơn là đặt khoảng thời gian sweep lớn hơn hoặc nhỏ hơn 20000, nhưng điều đó phụ thuộc vào nhiều yếu tố (số giao dịch hàng ngày là một trong những yếu tố đó, ví dụ) và chỉ có thể hiểu được bằng cách thử nghiệm. Vì vậy, nếu bạn đặt khoảng thời gian sweep thành 0, bạn có thể chắc chắn rằng sweep sẽ không chạy tự động vào thời điểm không thể đoán trước.

Bạn có thể thấy hình ảnh tương tự cho tệp !rollback.txt.

lưu ý: Nếu sweep đang chạy tự động, đối với cơ sở dữ liệu lớn hoặc cơ sở dữ liệu có nhiều phiên bản bản ghi rác, Snapshot, Active và Next transactions có thể di chuyển về phía trước trong khi sweep hoạt động và sweep có thể bắt đầu lại tại lần bắt đầu giao dịch gần nhất.

Khi sweep không thể thực hiện công việc của nó

Có nhiều trường hợp sweep không thể đẩy Oldest transaction lên cao hơn. Tất nhiên, sweep trước tiên cố gắng thực hiện công việc của nó, tức là kiểm tra tất cả các bản ghi trong cơ sở dữ liệu và thu thập các phiên bản bản ghi không cần thiết. Nhưng nó sẽ chạy lại và chạy lại mà không thành công nếu

có một số vấn đề khi sweep chạy: máy chủ bị dừng trong quá trình sweep hoặc có lỗi trong quá trình dọn dẹp phiên bản bản ghi rác. Ngoài ra, bạn có thể thấy hình ảnh này khi:

thống kê được lấy khi sweep đang hoạt động
sweep đang chạy và cố gắng thu thập rác cho bảng đang được cập nhật liên tục. Điều này có thể kéo dài cho đến khi các bản cập nhật kết thúc.
sweep bị kẹt trên các khóa trang, vì có nhiều người dùng đang làm việc với dữ liệu.

Nói chung, sweep không có cơ hội hoàn thành trong thời gian tải cơ sở dữ liệu cao. Thông thường khi hiệu suất suy giảm đến mức không thể tiếp tục công việc bình thường, DBA khởi động lại máy chủ và sweep chạy tại lần kết nối người dùng đầu tiên. Vì sẽ có một khoảng thời gian trong khi những người dùng khác kết nối, sweep sẽ có thời gian để hoàn thành công việc của nó.

Vì InterBase 7.1/7.5 tính toán Sweep gap khác với các phiên bản trước, tình huống khác khi sweep không thể thực hiện công việc của nó là khi một số ứng dụng có giao dịch snapshot chạy lâu:

Ở đây có hai cảnh báo - một (màu vàng) về snapshot chạy lâu và một (màu đỏ) về khoảng thời gian sweep và sweep gap.

Snapshot chạy lâu

Hình trước chỉ ra snapshot chạy lâu trong InterBase 7.1/7.5. Nếu khoảng thời gian sweep được đặt thành 0, sẽ không có cảnh báo màu đỏ, chỉ có màu vàng. Hình ảnh tương tự sẽ chỉ ra giao dịch snapshot chạy lâu trong các phiên bản Interbase, Firebird và Yaffil khác:

Như bạn thấy ở đây, Sweep gap được tính bằng sự khác biệt giữa Oldest Snapshot và Oldest transaction (cho ODS 10, các phiên bản trước IB7.x). Vì vậy, không có cảnh báo sweep (ngoại trừ khoảng thời gian sweep mặc định).

Tuy nhiên, không chỉ các giao dịch snapshot ảnh hưởng đến trạng thái giao dịch theo cách này. Tất cả các phiên bản InterBase, Firebird và Yaffil ngoại trừ InterBase 7.1/7.5 có hành vi sau, mà chúng tôi gọi là “read committed artifact”.

Snapshots một lần nữa và Khi ReadCommitted đóng băng Oldest Snapshot

Mở !snapshot2.txt. :

Lưu ý rằng Oldest transaction lớn hơn Oldest snapshot. Và Sweep gap có giá trị âm. Điều này có thể xảy ra trong hai trường hợp. Trường hợp đầu tiên là khi có một số giao dịch snapshot bắt đầu và commit lần lượt. Tức là hình ảnh này có thể xảy ra với snapshots cũng như hình trước. Trường hợp tiếp theo chỉ xảy ra trên các máy chủ khác ngoài IB 7.1/7.5 với các giao dịch ReadCommitted (hoặc kết hợp các giao dịch ReadCommitted và Snapshot). Chúng có thể khóa số Oldest Snapshot theo cách tương tự như các giao dịch Snapshot. Trạng thái giao dịch hiện tại có thể được mô phỏng bằng chuỗi sau

bắt đầu giao dịch 1, snapshot hoặc read_committed
bắt đầu/commit một số giao dịch read_committed
bắt đầu giao dịch 2, snapshot hoặc read_committed
bắt đầu/commit một số giao dịch read_committed
commit giao dịch 1

(tất nhiên, chúng ta nói ở đây về các giao dịch read_committed write, không phải read-only).

Tại thời điểm này, giao dịch 2 đang hoạt động (snapshot hoặc read committed), bắt đầu sau snapshot 1 (đánh dấu 3), sẽ giữ số snapshots như Oldest Snapshot (nếu bạn làm việc với IB 7.1/7.5, điều này chỉ có thể xảy ra với các giao dịch snapshot đồng thời. read_committed hoặc read_committed+snapshot sẽ không tạo ra hiệu ứng này). Vì không có rollback lớn nào, Oldest transaction di chuyển về phía trước và trở nên lớn hơn Oldest Snapshot.

Bây giờ, nếu bạn có giao dịch read committed chạy lâu, bạn sẽ thấy hình ảnh như thế này. Đáng tiếc là bạn không thể làm gì ở đây với các ứng dụng của mình (ngoại trừ thêm tham số “read” cho các giao dịch read-only). Và tất nhiên, sweep sẽ không chạy tự động (nếu được đặt <> 0) trong trường hợp này.

lưu ý: hành vi này sẽ được sửa trong Firebird 2.0

Chế độ xem tuyệt đối và tương đối

Theo mặc định, IBAnalyst điền các hàng giao dịch theo phần trăm giá trị tuyệt đối của chúng. Tức là 100% là từ 0 đến Next transaction. Đôi khi, khi cơ sở dữ liệu hoạt động trong một thời gian dài, bạn có thể thấy thông tin giao dịch như

Trong khi có nhiều giao dịch, sự khác biệt giữa snapshot, active và oldest trông rất nhỏ (gần 98%). Để làm rõ tình hình hơn, hãy mở hộp thoại Options, tab Transactions và chọn tùy chọn “Relative (from oldest) bars %” (bạn không thể đặt hộp kiểm này nếu bạn sử dụng chế độ xem kiểu cũ, không có thanh đồ thị). Sau khi nhấn nút OK, chế độ xem giao dịch sẽ thay đổi thành

Bây giờ bạn thấy sự khác biệt giữa các giao dịch ở chế độ xem tương đối (100% là từ giao dịch Oldest (hoặc snapshot) đến Next, không phải từ 0). Điều này giúp bạn dễ dàng hiểu tình hình hiện tại và xem các cảnh báo (nếu có).

Chế độ xem này sẽ được giữ nguyên cho đến khi bạn bỏ chọn nó trong hộp thoại Options. Bạn có thể hiểu mình đang xem chế độ nào bằng hàng Oldest Transaction hoặc Oldest snapshot - trong chế độ xem tương đối, một trong các hàng này không bao giờ được tô màu xanh lá cây. Trong chế độ xem tuyệt đối, nó luôn được tô màu (tất nhiên là một phần).

Vẫn còn thắc mắc? Hãy hỏi chúng tôi tại [email protected]