IBAnalyst: Cách lấy số liệu thống kê từ cơ sở dữ liệu InterBase/Firebird một cách đúng đắn

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 cho các mẹo và thủ thuật thu thập và phân tích số liệu thống kê từ cơ sở dữ liệu InterBase/Firebird có hoặc không có IBAnalyst.

Đúng thời điểm, đúng nơi

Nghe có vẻ lạ, nhưng chỉ thu thập số liệu thống kê qua gstat hoặc Services API là chưa đủ. Số liệu thống kê phải được thu thập vào đúng thời điểm để cho thấy các ứng dụng ảnh hưởng đến dữ liệu và giao dịch trong cơ sở dữ liệu như thế nào. Thời điểm tồi tệ nhất để thu thập số liệu thống kê là

Ngay sau khi khôi phục
Sau khi sao lưu (gbak -b db.gdb) mà không có công tắc -g
Sau khi quét thủ công (gfix -sweep)

Cũng đúng rằng trong quá trình làm việc có thể có những thời điểm cơ sở dữ liệu ở trạng thái chính xác, ví dụ, khi các ứng dụng tạo ra tải cơ sở dữ liệu ít hơn bình thường (người dùng khi khởi động, giờ ăn trưa hoặc theo thời gian của quy trình kinh doanh cụ thể).

Làm thế nào để bắt được khi có điều gì đó sai trong cơ sở dữ liệu?

Vâng, các ứng dụng của bạn có thể được thiết kế hoàn hảo đến mức chúng sẽ luôn hoạt động với giao dịch và dữ liệu một cách chính xác, không tạo ra khoảng trống quét, nhiều giao dịch đang hoạt động, snapshot chạy lâu và vân vân. Thông thường điều đó không xảy ra. Ít nhất là vì một số nhà phát triển kiểm tra ứng dụng của họ chạy 2-3 người dùng đồng thời cùng một lúc, không nhiều hơn. Do đó, khi họ cài đặt các ứng dụng đã viết cho 15 người dùng đồng thời trở lên, cơ sở dữ liệu có thể hoạt động không thể đoán trước. Tất nhiên, chế độ đa người dùng có thể hoạt động tốt, vì hầu hết các xung đột đa người dùng có thể được kiểm tra với 2-3 ứng dụng chạy đồng thời. Nhưng, tiếp theo, khi nhiều ứng dụng đồng thời hơn sẽ chạy, các vấn đề thu gom rác có thể xuất hiện (ít nhất). Và điều này có thể bị bắt nếu bạn thu thập số liệu thống kê vào đúng thời điểm.

Nếu bạn không gặp phải các vấn đề hiệu suất định kỳ

Điều này có thể xảy ra khi các ứng dụng của bạn được thiết kế đúng cách, tải cơ sở dữ liệu thấp, hoặc phần cứng của bạn hiện đại và rất mạnh mẽ (đủ để xử lý tốt số lượng người dùng và dữ liệu hiện tại).

Thông tin có giá trị nhất là tải giao dịch và tích lũy phiên bản. Điều này chỉ có thể thấy nếu bạn thiết lập lưu số liệu thống kê thường xuyên.

InterBase không có bộ lập lịch tác vụ nội bộ, vì vậy bạn có thể tự do sử dụng bất kỳ bộ lập lịch bên ngoài nào, như Task Scheduler tiêu chuẩn (Windows) hoặc cron (Unix).

Thiết lập tốt nhất là lấy số liệu thống kê giao dịch hàng giờ. Điều này có thể được thực hiện bằng cách chạy

gstat -h db.gdb >db_stat_.txt

trong đó

db.gdb là tên cơ sở dữ liệu của bạn,

db_stat_.txt là tệp văn bản nơi số liệu thống kê sẽ được lưu,

- ngày và giờ hiện tại khi số liệu thống kê được thu thập.

Nếu bạn gặp phải các vấn đề hiệu suất định kỳ

Những vấn đề này thường do quá trình quét tự động chạy. Đầu tiên bạn cần xác định khoảng thời gian giữa các lần giảm hiệu suất như vậy. Tiếp theo, chia khoảng thời gian này tối thiểu cho 4 (8, 16, v.v.). Hiện nay các hệ thống thông tin có nhiều người dùng đồng thời, và hầu hết các vấn đề hiệu suất với máy chủ và cơ sở dữ liệu chưa được cấu hình xảy ra 2 hoặc 3 lần mỗi ngày. Ví dụ, nếu các lần giảm hiệu suất xảy ra mỗi 3 giờ, bạn cần thu thập

gstat -h db.gdb

số liệu thống kê mỗi 30-45 phút, và

gstat -a -r db.gdb -user SYSDBA -pass masterkey

mỗi 1-1.5 giờ.

Tốt nhất là khi bạn thu thập số liệu thống kê gstat -a -r ngay trước khi lần giảm hiệu suất sắp xảy ra. Nó sẽ cho thấy rác thực sự ở đâu và có bao nhiêu phiên bản bản ghi lỗi thời đã tích lũy.

Làm gì với số liệu thống kê này

Nếu ứng dụng của bạn sử dụng giao dịch một cách rõ ràng và sử dụng chúng tốt, tức là bạn biết read_committed là gì và khi nào nên sử dụng nó, các giao dịch snapshot của bạn kéo dài không lâu hơn mức cần thiết, và các giao dịch đang hoạt động trong khoảng thời gian tối thiểu, bạn có thể điều chỉnh khoảng thời gian quét hoặc tắt nó đi, và sau đó chỉ quan tâm đến số lượng cập nhật mà (các) ứng dụng thực hiện và những bảng nào cần được cập nhật ít hơn hoặc cần quan tâm đến các cập nhật.

Điều này có nghĩa là gì, bạn có thể hỏi? Chúng tôi sẽ đưa ra ví dụ về một hệ thống nào đó, nơi các vấn đề hiệu suất xảy ra mỗi buổi sáng trong 20-30 phút. Điều đó rất đủ cho các ứng dụng “buổi sáng”, và không thể kéo dài lâu hơn.

Quản trị viên cơ sở dữ liệu đã được hỏi các câu hỏi đúng, và đây là bức tranh:

Công việc hàng ngày được chia thành các phần - nhà phân tích làm việc vào buổi sáng, sau đó dữ liệu được chèn và chỉnh sửa bởi các nhân viên vận hành thông thường, và vào cuối ngày các quy trình đặc biệt bắt đầu thu thập dữ liệu, sẽ được sử dụng cho phân tích vào ngày hôm sau (ít nhất).

Công việc cuối cùng trên cơ sở dữ liệu vào cuối ngày là rất nhiều cập nhật, và cập nhật các bảng mà nhà phân tích sử dụng vào buổi sáng. Vì vậy, có rất nhiều phiên bản rác, bắt đầu được thu gom bởi ứng dụng chạy vào buổi sáng.

Và, câu trả lời cho vấn đề đó được tìm thấy đơn giản - chạy gfix -sweep vào cuối ngày.

Quét đọc tất cả các bảng trong cơ sở dữ liệu và cố gắng thu gom tất cả các phiên bản rác cho các giao dịch đã cam kết và đã rollback. Sau khi quét, cơ sở dữ liệu trở nên sạch gần như sau khi khôi phục.

Và, “vấn đề buổi sáng” đã biến mất.

Vì vậy, bạn cần xem xét số liệu thống kê với nhiều yếu tố khác:

có bao nhiêu người dùng đồng thời (trung bình) làm việc trong ngày
ngày làm việc dài bao lâu (8, 12, 16, 24 giờ)
loại ứng dụng nào chạy vào các thời điểm khác nhau trong ngày, và chúng ảnh hưởng đến dữ liệu được sử dụng bởi các ứng dụng khác, chạy cùng lúc hoặc tiếp theo như thế nào. Tức là bạn phải hiểu các quy trình kinh doanh diễn ra trong cả ngày và cả tuần.

Khi DBA không thể làm gì

Buồn phải nói, những tình huống này xảy ra. Và một lần nữa, ví dụ:

Một hệ thống nào đó được cài đặt cho ~15 người dùng. Định kỳ hiệu suất tệ đến mức DBA cần khởi động lại máy chủ. Sau khi khởi động lại máy chủ, mọi thứ hoạt động tốt trong một thời gian, sau đó hiệu suất lại trở nên tệ. Số liệu thống kê cho thấy trung bình hàng ngày có khoảng 75.000 giao dịch, và có các giao dịch đang hoạt động chạy từ đầu ngày đến thời điểm hiệu suất giảm xuống.

Thật không may, các ứng dụng được viết bằng BDE và không sử dụng giao dịch nào cả; tức là tất cả việc xử lý giao dịch là tự động và được sử dụng bởi chính BDE. Điều này khiến một số giao dịch duy trì hoạt động trong thời gian dài, và rác (phiên bản bản ghi) tích lũy cho đến khi DBA khởi động lại máy chủ. Sau khi khởi động lại, quét tự động chạy, và rác được thu gom (loại bỏ).

Tất cả những điều này do các ứng dụng gây ra, vì chúng chỉ được kiểm tra với 2-3 người dùng đồng thời, và khi chúng trở thành ~15, các ứng dụng bắt đầu tạo ra tải rất cao.

Cần phải nói rằng trong cấu hình đó 70% người dùng chỉ đọc dữ liệu, và 30% còn lại đang chèn và cập nhật một số (!) dữ liệu.

Trong tình huống này, điều duy nhất có thể làm cho hiệu suất tốt hơn là thiết kế lại các ứng dụng hoàn toàn.

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