Ví dụ về phân tích hiệu suất

Để xem video hướng dẫn, hãy mở báo cáo ví dụ tại đây.

Cách diễn giải báo cáo hiệu suất

Sử dụng HQbird, hoặc như một dịch vụ riêng biệt, IBSurgeon Performance Analysis từ cc.ib-aid.com, bạn có thể tạo báo cáo hiệu suất từ nhật ký trace của Firebird.

Báo cáo này là một công cụ chẩn đoán mạnh mẽ cung cấp thông tin chi tiết về việc thực thi truy vấn SQL trong cơ sở dữ liệu Firebird. Hướng dẫn này giải thích cách diễn giải và sử dụng báo cáo trace để xác định và giải quyết các điểm nghẽn hiệu suất một cách có hệ thống.

1. Cấu trúc báo cáo hiệu suất

┌─────────────────────────────────────────┐
│         Báo cáo hiệu suất               │
├─────────────────────────────────────────┤
│ 1. Biểu đồ tóm tắt hiệu suất            │
│    ┌────────────────────────┐           │
│    │  Truy vấn hàng đầu     │           │
│    │     Tóm tắt hàng đầu   │           │
│    │     Tần suất hàng đầu  │           │
│    │     Thời lượng         │           │
│    │     Fetches            │           │
│    │     Reads              │           │
│    │     Writes             │           │
│    │  Biểu đồ chuỗi thời gian│          │
│    │     Thời lượng         │           │
│    │     Số lượng truy vấn  │           │
│    │     Fetches            │           │
│    │     Reads/Writes       │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 2. Phân tích truy vấn hàng đầu          │
│    ┌────────────────────────┐           │
│    │ Xếp hạng truy vấn      │           │
│    │                        │           │
│    │  Theo thời lượng───┐   │           │
│    │                    │   │           │
│    │  Theo thời gian────┤   │           │
│    │  Tóm tắt           │   │           │
│    │                    │   │           │
│    │  Theo kế hoạch─────┤   │           │
│    │  Tóm tắt           │   │           │
│    │                    │   │           │
│    │  Theo tần suất─────┤   │           │
│    │                    │   │           │
│    │  Theo kế hoạch─────┤   │           │
│    │  Tần suất          │   │           │
│    │                    │   │           │
│    │  Theo fetches──────┤   │           │
│    │                    │   │           │
│    │  Theo reads────────┤   │           │
│    │                    │   │           │
│    │  Theo writes───────┘   │           │
│    │                        │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 3. Tóm tắt tiến trình                   │
│    ┌────────────────────────┐           │
│    │ Thống kê mỗi tiến trình│           │
│    │ - Số lần thực thi      │           │
│    │ - Fetches, v.v.        │           │
│    │ - Chỉ số thời lượng    │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 4. Tóm tắt địa chỉ                      │
│    ┌────────────────────────┐           │
│    │Thống kê mỗi địa chỉ    │           │
│    │khách hàng              │           │
│    │ - Số kết nối           │           │
│    │ - Thời lượng           │           │
│    │ - Fetches, v.v.        │           │
│    │ - Tên tiến trình       │           │
│    └────────────────────────┘           │
└─────────────────────────────────────────┘

Cấu trúc chi tiết truy vấn:
┌────────────────────┐
│ Thông tin truy vấn │
├────────────────────┤
│ - Văn bản SQL      │
│ - Thông tin giao dịch│
│ - Kế hoạch thực thi│
│ - Thống kê thời lượng│
│ - Thống kê tài nguyên│
│   * Fetches         │
│   * Reads           │
│   * Writes          │
│   * Marks           │
│ - Thông tin khách   │
│   hàng              │
└────────────────────┘

Báo cáo hiệu suất cung cấp một cái nhìn phân cấp về hoạt động của cơ sở dữ liệu:

1. Biểu đồ tóm tắt hiệu suất

• Biểu diễn trực quan các chỉ số chính theo thời gian - bạn có thể dễ dàng thấy các đỉnh hoạt động/tải. (Cũng có báo cáo phân tích theo phút trong Advanced Performance Monitoring của HQbird, phiên bản rút gọn của nó có sẵn trên công cụ Portal - xem video này để biết chi tiết).

• Giúp xác định các mẫu và bất thường: so sánh đồ thị từ các giai đoạn có hiệu suất tốt (ví dụ: tuần/tháng trước) với các vấn đề hiệu suất có thể giúp xác định vấn đề.

2. Phân tích truy vấn hàng đầu

• Nhiều góc độ xếp hạng để phân tích toàn diện: các truy vấn dài nhất, các truy vấn thường xuyên nhất, các truy vấn tốn thời gian nhất (được nhóm theo văn bản hoặc kế hoạch), v.v.

• Mỗi chiều tiết lộ các cơ hội tối ưu hóa khác nhau

• Thống kê chi tiết cho mỗi truy vấn bao gồm:

• Chỉ số thời lượng (tối thiểu, tối đa, trung bình, trung vị)

• Tiêu thụ tài nguyên (fetches, reads, writes)

• Mẫu thực thi - số lượng nguồn gốc cho các truy vấn hàng đầu.

3. Tóm tắt tiến trình

• Nhóm thống kê theo tiến trình thực thi

• Giúp xác định các ứng dụng có vấn đề

• Hiển thị tiêu thụ tài nguyên và các hoạt động cơ sở dữ liệu (kết nối, truy vấn, v.v.) và các chỉ số (fetches, reads, v.v.) theo tiến trình

4. Tóm tắt địa chỉ

• Nhóm thống kê theo kết nối khách hàng

• Tiết lộ phân phối tải trên các khách hàng

• Giúp xác định các vấn đề cụ thể theo kết nối

Mỗi phần hỗ trợ phân tích hiệu suất ở các cấp độ khác nhau:

• Các mẫu toàn hệ thống (Biểu đồ) - xem khi nào và ở đâu các vấn đề xảy ra nói chung.

• Tác động đáng chú ý nhất từ các truy vấn (Truy vấn hàng đầu) - xác định các truy vấn nên được tối ưu hóa trước tiên.

• Các vấn đề cấp ứng dụng (Tóm tắt tiến trình) - xác định các ứng dụng gây ra vấn đề hiệu suất.

• Các vấn đề cấp khách hàng (Tóm tắt địa chỉ) - xác định các địa chỉ IP (máy trạm, máy tính khách hàng) có luồng truy vấn lớn nhất.

2. Phân tích Tóm tắt thời gian và Tóm tắt kế hoạch

Nên bắt đầu phân tích tình huống hiệu suất với các phần Tóm tắt. Nhấp vào đây để mở phần Tóm tắt kế hoạch trong báo cáo ví dụ.

Tóm tắt thời gian tổng hợp tổng thời gian thực thi cho mỗi mẫu câu lệnh SQL duy nhất.

Hãy coi nó như một báo cáo “trung tâm chi phí” cho thấy các truy vấn nào đang tiêu thụ nhiều tài nguyên cơ sở dữ liệu nhất theo thời gian.

Nếu các truy vấn không được tham số hóa, tức là chứa rõ ràng các giá trị tham số bên trong văn bản SQL thay vì trình giữ chỗ tham số (:myparam1), cần sử dụng phần "Tóm tắt kế hoạch" để xác định các truy vấn có tần suất cao nhất.
Ví dụ về truy vấn không tham số hóa: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Ví dụ về truy vấn tham số hóa: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

Mỗi truy vấn trong phần Tóm tắt có tiêu đề với các phần chính sau:

• Tóm tắt: Phần trăm tổng thời gian, cho thấy truy vấn tiêu thụ bao nhiêu phần thời gian tổng thể của cơ sở dữ liệu.

• Tần suất: Số lần mẫu truy vấn xuất hiện

• Fetch, Read, Write: các chỉ số tài nguyên

Ví dụ: nếu có

Tóm tắt: 19.08% (3920272 trên 20541791 ms)

Điều này cho chúng ta biết mẫu truy vấn này đang tiêu thụ gần 20% tổng thời gian cơ sở dữ liệu - một phần đáng kể cần được chú ý ngay lập tức.

Bên dưới tiêu đề trong phần Tóm tắt kế hoạch, chúng ta sẽ thấy kế hoạch thực thi SQL được sử dụng để nhóm các truy vấn; trong Tóm tắt thời gian, đó sẽ là văn bản của chính truy vấn.

Vì mẫu truy vấn đại diện cho nhiều hơn một truy vấn cụ thể, thông tin cụ thể về kết nối được lấy từ truy vấn đầu tiên tương ứng với mẫu:

Trong ảnh chụp màn hình ở trên, bạn có thể thấy tiêu đề của câu lệnh ví dụ cho mẫu, bao gồm tên ứng dụng đã khởi động SQL này, ID kết nối và ID giao dịch, cũng như địa chỉ IP và chi tiết giao dịch.

Bên dưới là kế hoạch (đối với Tóm tắt thời gian; đối với Tóm tắt kế hoạch, phần này được bỏ qua vì nó đã được hiển thị ở đầu), các giá trị tham số (theo thứ tự xuất hiện) và thống kê theo bảng:

Xin lưu ý, trong Tóm tắt kế hoạch, chúng tôi nhóm các SQL bằng kế hoạch thực thi, nghĩa là chỉ kế hoạch là cố định cho mẫu; còn trong Tóm tắt thời gian, chúng tôi nhóm bằng văn bản câu lệnh SQL và các thứ khác (giá trị tham số, thời gian thực thi, v.v.) có thể khác nhau. Sử dụng thông tin này như một ví dụ về mẫu thực thi (trong 99% trường hợp, điều này đủ để tái tạo vấn đề).

Bên dưới, chúng ta có biểu đồ riêng về các lần thực thi của truy vấn cụ thể này. Như bạn có thể thấy, truy vấn này được bắt đầu trong giai đoạn tải cao mà chúng ta đã nhận thấy trên biểu đồ tổng quan.

Và cuối cùng, chúng ta có một bộ sưu tập thống kê rất quan trọng cho TẤT CẢ các truy vấn tương ứng với mẫu và danh sách các địa chỉ nguồn gốc:

Trong thống kê này, chúng ta có thể thấy thời gian thực thi tối thiểu, tối đa, trung bình và trung vị, cùng các thống kê tương tự cho fetches, reads, writes và marks (các hoạt động xóa bộ nhớ cache).

2.1. Cách sử dụng Tóm tắt thời gian:

• Đầu tiên xác định các truy vấn tiêu thụ thời gian không cân xứng (chúng nằm trong top 3 của phần này - #1, 2, 3)

• So sánh mức tiêu thụ thời gian với tần suất

• Xem thời gian thực thi trung bình (tổng thời gian / tần suất) ở cuối phần của truy vấn (xem bên dưới)

• Tìm kiếm các mẫu trong đó:

• Thời gian cao + Tần suất thấp = Các truy vấn riêng lẻ không hiệu quả

• Thời gian cao + Tần suất cao = Các truy vấn có khả năng không hiệu quả nhưng được sử dụng nhiều

3. Phân tích tần suất: Tần suất và Tần suất kế hoạch

Sử dụng phân tích tần suất để hiểu các truy vấn chạy thường xuyên như thế nào. Hãy coi nó như việc đếm xem một con đường cụ thể được sử dụng bao nhiêu lần trong giờ cao điểm.

Nếu các truy vấn không được tham số hóa, tức là chứa rõ ràng các giá trị tham số bên trong văn bản SQL thay vì trình giữ chỗ tham số (:myparam1), cần sử dụng phần "Tóm tắt kế hoạch" để xác định các truy vấn có tần suất cao nhất.
Ví dụ về truy vấn không tham số hóa: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Ví dụ về truy vấn tham số hóa: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

3.1. Hiểu tác động của tần suất

Biểu diễn của mẫu truy vấn Tần suất rất giống với Tóm tắt kế hoạch/thời gian:

Các truy vấn tần suất cao giống như các giao lộ đông đúc - ngay cả khi mỗi chiếc xe (truy vấn) di chuyển nhanh, khối lượng lớn có thể gây tắc nghẽn. Điều này ảnh hưởng đến:

• Các kết nối cơ sở dữ liệu (giống như chỗ đỗ xe - giới hạn về số lượng)

• Băng thông mạng (giống như công suất đường)

• Mức sử dụng CPU (giống như bộ điều khiển giao thông bị quá tải)

• Hiệu quả bộ nhớ đệm (giống như phải truy cập lặp đi lặp lại cùng một thông tin)

Để ước tính tác động của các truy vấn tần suất cao, hãy thu thập trace với ngưỡng tham số = 0.

3.2. Các Mức Tác Động Theo Tần Suất

3.3. Ví dụ Phân Tích

Hãy xem xét một trường hợp thực tế từ báo cáo trace của chúng tôi:

Tần suất: 4.428 lần thực thi (24,43% tổng số)
Tác động: Nghiêm trọng - khối lượng lớn truy vấn trên bảng SALES
Nguyên nhân gốc: Kiểm tra số dư khách hàng lặp đi lặp lại
Ưu tiên tối ưu hóa: Cao

Giải thích: Truy vấn này chạy hàng nghìn lần, tương tự như một
ngã tư đông đúc. Mặc dù mỗi lần thực thi có thể nhanh, nhưng
tác động tích lũy là đáng kể. Ứng dụng có thể đang kiểm tra
số dư thường xuyên hơn mức cần thiết.

4. Phân tích thống kê các truy vấn hàng đầu trong các phần xx-Summary và Frequency

Khi phân tích báo cáo trace của Firebird, mỗi nhóm truy vấn chứa số liệu thống kê tổng hợp chi tiết cung cấp những hiểu biết quan trọng về các mẫu hiệu suất. Hãy phân tích từng chỉ số và hiểu ý nghĩa của nó đối với việc tối ưu hóa cơ sở dữ liệu.

4.1. Phân Tích Số Liệu Thống Kê Tổng Hợp

Hãy xem xét tập hợp số liệu thống kê ví dụ này:

Tổng: 4428 mục:
Thời lượng: min: 351; max: 3919; avg: 457,70; median: 455,00; sum: 2026710 (20,29%);
Fetches: min: 7135; max: 7168; avg: 7146,86; median: 7147,00; sum: 31646289 (0,75%);
Ghi: min: 0; max: 0; avg: 0,00; median: 0,00; sum: 0 (0,00%);
Đọc: min: 0; max: 6995; avg: 3,13; median: 0,00; sum: 13856 (8,22%);
Marks: min: 0; max: 0; avg: 0,00; median: 0,00; sum: 0 (0,00%);
Từ 1 địa chỉ duy nhất: TCPv6:::1 (4428)

4.2. Phân Tích Số Lần Thực Thi

4.2.1. Tổng Số Mục

Tổng: 4428 mục

Đây là số lần mẫu truy vấn cụ thể này được thực thi trong khoảng thời gian trace.

Hiểu con số này giúp bạn:

• Tính toán mức sử dụng tài nguyên cho mỗi lần thực thi

• Xác định xem việc lưu trữ truy vấn trong bộ nhớ đệm có mang lại lợi ích hay không (hoặc đơn giản là chạy nó ít thường xuyên hơn)

Số lần thực thi cao có thể chỉ ra cơ hội cho:

• Triển khai câu lệnh chuẩn bị sẵn (và có tham số) - cùng một truy vấn với cùng tần suất, khi được tham số hóa và chuẩn bị cho việc thực thi lặp lại, sẽ yêu cầu ít tài nguyên hơn

• Thêm bộ nhớ đệm kết quả - lưu trữ giá trị kết quả để sử dụng trong suốt thao tác dài hoặc thậm chí lâu hơn, cho phiên của người dùng, có thể giảm nhu cầu thực thi truy vấn thường xuyên

• Gộp các thao tác - cân nhắc thực thi truy vấn để trả về hoặc xử lý nhiều bản ghi cùng một lúc, điều này sẽ loại bỏ chi phí cho việc thực thi truy vấn (chuẩn bị, truyền qua mạng, v.v.).

4.3. Chỉ Số Thời Lượng

4.3.1. Ví Dụ Về Các Thành Phần Thời Lượng

Thời lượng: min: 351; max: 3919; avg: 457,70; median: 455,00; sum: 2026710 (20,29%);

4.3.2. Phân Tích Thời Lượng

• Trung vị và trung bình gần nhau (457,70 so với 455,00 ms) cho thấy hiệu suất ổn định

• Tỷ lệ max/min (~11 lần) chỉ ra một số biến động

• 20,29% tổng thời gian là đáng kể - truy vấn này có nằm trong top 3 ở phần Frequency hoặc Plan-Frequency không? (có, nó nằm trong đó.)

4.4. Chỉ Số Sử Dụng Tài Nguyên

4.4.1. Thao Tác Fetch

Fetches: min: 7135; max: 7168; avg: 7146,86; median: 7147,00; sum: 31646289 (0,75%);

Fetches đại diện cho việc truy xuất hàng:

• Số lượng fetch nhất quán (chênh lệch min/max chỉ 33) cho thấy tập kết quả ổn định

• Số lượng fetch tương đối cao (>7000 mỗi lần thực thi) có thể chỉ ra:

• Cần giới hạn tập kết quả và/hoặc phân trang, nếu có nhiều bản ghi được trả về.

• Tiềm năng tối ưu hóa truy vấn - đặc biệt có ý nghĩa nếu truy vấn nằm trong top 3 của Frequency/Plan-Frequency.

4.5. Thao Tác Đọc

Đọc: min: 0; max: 6995; avg: 3,13; median: 0,00; sum: 13856 (8,22%);

Đọc vật lý cho biết truy cập đĩa:

• Trung vị bằng 0 với tối đa khác 0 cho thấy thỉnh thoảng bỏ lỡ bộ nhớ đệm

• 8,22% tổng số lần đọc cho thấy tác động I/O ở mức trung bình

• Khoảng cách lớn giữa min (0) và max (6995) cho thấy hiệu quả bộ nhớ đệm thay đổi.

4.6. Thao Tác Ghi

Ghi: min: 0; max: 0; avg: 0,00; median: 0,00; sum: 0 (0,00%);

Nếu truy vấn không thực hiện ghi, thông thường đó là thao tác chỉ đọc.

4.7. Thao Tác Mark

Marks: min: 0; max: 0; avg: 0,00; median: 0,00; sum: 0 (0,00%);

Thao tác Mark liên quan đến quản lý bộ nhớ đệm trang dữ liệu:

• Marks bằng 0 cho thấy không có trang dữ liệu nào được đánh dấu để ghi ra, phổ biến cho các truy vấn SELECT đơn giản

• Thao tác marks khác 0 với bộ nhớ đệm

4.8. Phân Tích Kết Nối Máy Khách

Từ 1 địa chỉ duy nhất: TCPv6:::1 (4428)

Điều này cho thấy phân bố nguồn truy vấn:

• Địa chỉ máy khách duy nhất cho thấy truy vấn cụ thể của ứng dụng

• Kết nối cục bộ (::1 là localhost IPv6)

• Tất cả 4428 lần thực thi từ cùng một nguồn

4.9. Sử Dụng Các Chỉ Số Này Để Tối Ưu Hóa

4.9.1. Phân Tích Mẫu Hiệu Suất

Tính nhất quán khi thực thi

• So sánh thời lượng min/max

• Tìm kiếm các giá trị ngoại lệ trong việc sử dụng tài nguyên

• Kiểm tra trung vị so với trung bình để xác định biến động

Mẫu sử dụng tài nguyên

• Fetches cao → Xem xét kích thước tập kết quả

• Đọc cao → Kiểm tra phạm vi phủ của chỉ mục

• Marks cao → Kiểm tra tranh chấp khóa

Phân tích tác động máy khách

• Nhiều máy khách → Điều chỉnh kích thước connection pool

• Một máy khách → Tối ưu hóa ứng dụng

4.9.2. Ưu Tiên Tối Ưu Hóa

Dựa trên các chỉ số này, ưu tiên:

• Kích thước tập kết quả

• 7000 fetches mỗi lần thực thi

• Cân nhắc thêm LIMIT/OFFSET

• Xem xét danh sách cột SELECT

Chiến lược bộ nhớ đệm

• Thực thi thường xuyên (4428 lần)

• Kích thước kết quả nhất quán

• Không liên quan đến ghi

Có lẽ, truy vấn này có thể được thực thi ít thường xuyên hơn.

Sử dụng chỉ mục

• Số lần đọc thay đổi

• Trung vị đọc bằng 0 nhưng tối đa cao

• Xem xét phạm vi phủ của chỉ mục

5. Ứng Dụng Thực Tế

Đối với ví dụ cụ thể này:

Cải thiện ngắn hạn:

• Triển khai bộ nhớ đệm kết quả (số lần thực thi cao, fetches nhất quán)

• Xem xét kích thước tập kết quả (>7000 fetches mỗi lần thực thi)

Tối ưu hóa trung hạn:

• Phân tích các mẫu sử dụng chỉ mục

• Cân nhắc sử dụng câu lệnh chuẩn bị sẵn

• Xem xét logic ứng dụng về tần suất thực thi

Cân nhắc dài hạn:

• Theo dõi các mẫu thực thi theo thời gian

• Lên kế hoạch chiến lược bảo trì chỉ mục

• Cân nhắc các thay đổi về mẫu truy cập dữ liệu

6. Phân Tích Thời Lượng

Phân tích thời lượng xem xét thời gian thực thi của từng truy vấn. Hãy nghĩ về thời lượng như một chiếc đồng hồ bấm giờ cho mỗi truy vấn - truy vấn càng mất nhiều thời gian thì khả năng gây ra vấn đề hiệu suất càng cao.

6.1. Hiểu Về Chỉ Số Thời Lượng

Chỉ số thời lượng rất quan trọng vì chúng ảnh hưởng trực tiếp đến trải nghiệm của người dùng, tức là người dùng phàn nàn “hệ thống chậm”. Giống như khách hàng bực bội khi phải xếp hàng dài, người dùng trở nên bực bội khi truy vấn mất quá nhiều thời gian để hoàn thành. Các truy vấn chạy lâu gây ra:

• Trải nghiệm người dùng kém khi màn hình mất quá nhiều thời gian để tải

• Tài nguyên hệ thống bị chiếm giữ trong thời gian dài

• Các truy vấn khác phải xếp hàng chờ phía sau các truy vấn chậm

• Các vấn đề timeout tiềm ẩn trong ứng dụng

6.2. Các Mức Tác Động

6.3. Ví Dụ Phân Tích

Thời lượng: 77.793ms
Tác động: Nghiêm trọng - một truy vấn tiêu thụ 77,7 giây
Nguyên nhân gốc: Tổng hợp phức tạp trong PRC_COLLECT_RANKCATEGORY
Ưu tiên tối ưu hóa: Ngay lập tức

Giải thích: Truy vấn này mất hơn một phút để thực thi, giống như
một sự ùn tắc giao thông hoàn toàn. Stored procedure có thể đang
xử lý quá nhiều dữ liệu hoặc sử dụng các thuật toán không hiệu quả.

7. Chiến Lược Triển Khai

Hãy nghĩ về việc tối ưu hóa như việc cải thiện hệ thống giao thông - bạn cần xác định vấn đề, lên kế hoạch giải pháp và triển khai các thay đổi một cách cẩn thận.

7.1. Ma Trận Ưu Tiên

Ma trận này giúp bạn quyết định điều gì cần chú ý trước, giống như việc phân loại các vấn đề giao thông trong thành phố:

7.2. Quy Trình Tối Ưu Hóa Từng Bước

1. Xác định các truy vấn quan trọng

• Tìm kiếm các điểm ùn tắc lớn nhất (truy vấn chậm)

• Tìm các giao lộ đông đúc nhất (truy vấn tần suất cao)

• Phát hiện các tuyến đường không hiệu quả (sử dụng tài nguyên cao)

2. Phân tích các kế hoạch thực thi

• Nghiên cứu các tuyến đường hiện tại (sử dụng chỉ mục)

• Kiểm tra các mẫu giao thông (phương pháp join)

• Kiểm tra các điểm nghẽn (thao tác sort)

3. Triển khai tối ưu hóa

• Xây dựng các tuyến đường mới (chỉ mục)

• Thiết kế lại các tuyến đường (cấu trúc lại truy vấn)

• Thêm các lối tắt (bộ nhớ đệm)

4. Xác minh cải tiến

• Đo lường luồng giao thông mới (báo cáo trace mới)

• So sánh các chỉ số trước/sau

• Ghi lại những gì đã hiệu quả

Liên hệ với IBSurgeon nếu có bất kỳ câu hỏi nào

Vui lòng liên hệ với chúng tôi nếu có bất kỳ câu hỏi nào: [email protected].