“Dữ liệu Solana chậm hoặc không đầy đủ?” Cần kiểm tra gì trong hạ tầng tiếp nhận
Bạn đăng ký một luồng Shreds Solana tốc độ cao, nhưng chỉ nhận được lác đác vài gói tin. Các Shreds nhận được vẫn được phân tích cú pháp chính xác, nhưng thiếu quá nhiều mảnh dữ liệu để trích xuất giao dịch. gRPC lại hoạt động trên cùng máy chủ, khiến bạn không biết nên kiểm tra tiếp ở đâu.
Bên cạnh việc kiểm tra bên gửi, hãy xem xét cả máy chủ ứng dụng và trung tâm dữ liệu nơi đặt máy chủ đó. Ngay cả khi ERPC chuyển tiếp Shreds nhanh chóng, các hạn chế đối với UDP trên đường truyền hoặc nút thắt xử lý tại máy chủ nhận vẫn có thể khiến ứng dụng không tận dụng được tốc độ đó.
Khi chọn một luồng Shreds, cần xem xét toàn bộ đường đi: các gói tin đến bằng cách nào, và chúng trở thành dữ liệu sử dụng được ra sao. Chất lượng mạng, khoảng cách và chính sách vận hành của trung tâm dữ liệu cũng là những điều kiện hiệu năng chung cho Geyser Yellowstone gRPC, lưu lượng RPC và API thông thường, cũng như việc gửi giao dịch.
Ghi nhận ở bên gửi và dữ liệu sử dụng được ở bên nhận là hai thực tế khác nhau
Trong một yêu cầu hỗ trợ gần đây của ERPC, các phép đo ngắn ở bên gửi ghi nhận khoảng 3.400–3.900 gói/giây. Bên nhận báo cáo khoảng 13 gói/giây và không hoàn tất tái dựng được slot nào.
Các con số này được đo trong những khoảng thời gian khác nhau, và chưa xác nhận được liệu các phương pháp đo có thể so sánh với nhau hay không. Vì vậy, chúng không đủ để xác định tỷ lệ truyền đến thành công hoặc tỷ lệ mất gói. Chỉ riêng ghi nhận ở bên gửi không chứng minh được dữ liệu đã đến nơi, và nguyên nhân cuối cùng vẫn chưa được xác định tại thời điểm viết bài.
Chỉ riêng mức vài nghìn PPS cũng không đủ để kết luận rằng đó là tải cao bất thường đối với một máy chủ đa dụng. Những câu hỏi cần làm rõ là điều gì xảy ra trên đường truyền thực tế, những giới hạn nào được áp dụng, lưu lượng tập trung ra sao trong các khoảng thời gian ngắn, việc tiếp nhận được xử lý thế nào và mỗi bộ đếm đo điều gì.
Cùng ở Frankfurt, nhưng đường truyền mạng khác nhau
Nguồn luồng dữ liệu và máy chủ ứng dụng của bạn có thể cùng ở Frankfurt nhưng vẫn nằm trong các trung tâm dữ liệu riêng biệt. Với cấu hình như vậy, lưu lượng có thể rời một cơ sở, đi qua mạng bên ngoài rồi vào cơ sở còn lại. Cùng mang một nhãn khu vực không có nghĩa là cùng cơ sở, nhà vận hành mạng hay tập hợp thiết bị trung gian.
Khi các luồng dữ liệu hoặc dịch vụ RPC của ERPC và một máy chủ ERPC VPS hoặc Bare Metal được đặt tại cùng một địa điểm, các máy chủ dịch vụ và máy chủ ứng dụng nằm trong những tủ rack gần nhau, và giao tiếp giữa chúng diễn ra trong mạng nội bộ. Đây là ý tưởng của Giao tiếp không khoảng cách tại ERPC: cùng thiết kế vị trí vật lý và đường truyền đến ứng dụng nhận, vượt ra ngoài việc chỉ chọn cùng một thành phố.
Tránh đi vòng qua mạng bên ngoài giữa các dịch vụ ERPC và máy chủ ứng dụng giúp rút ngắn đường truyền, đồng thời giảm mức độ chịu ảnh hưởng của tắc nghẽn và thay đổi tuyến trên mạng bên ngoài ở đoạn đó. Đường truyền ngắn, kết hợp với các tài nguyên cần thiết cho tiếp nhận và xử lý, tạo nền tảng để tận dụng một luồng tốc độ cao. Hãy kiểm chứng kết quả ở cả khâu gói tin đến và khâu xử lý của ứng dụng.
Điều kiện mạng ảnh hưởng đến mọi loại giao tiếp
Các mảnh dữ liệu bị thiếu khiến vấn đề dễ nhận thấy với Shreds, nhưng chất lượng của cùng hạ tầng đó còn ảnh hưởng rộng hơn đến việc nhận dữ liệu, yêu cầu API và gửi giao dịch. Giao thức khác nhau sẽ làm thay đổi biểu hiện mà ứng dụng quan sát được và những điểm cần đo.
| Loại giao tiếp | Ảnh hưởng của mạng thể hiện ở đâu | Cần kiểm tra gì trong ứng dụng |
|---|---|---|
| Shreds / UDP | Mất gói và độ trễ, cùng việc các mảnh cần cho tái dựng có đến hay không | Shreds hợp lệ và thời gian đến khi có thể tái dựng dữ liệu |
| Geyser Yellowstone gRPC | Thời gian chờ truyền lại TCP, dữ liệu luồng bị tồn đọng và độ trễ | Thời gian đến khi cùng một cập nhật được nhận và xử lý |
| RPC, API và lưu lượng giữa các dịch vụ | Hành trình đi và về của yêu cầu, phản hồi, cùng thời gian chờ khi tắc nghẽn | Thời gian phản hồi và mức biến động của nó |
| Gửi giao dịch | Đường truyền của yêu cầu đến nút nhận | Thời gian từ yêu cầu gửi giao dịch đến phản hồi của nút |
Vị trí gần nhau và chính sách vận hành phù hợp hỗ trợ tất cả các loại lưu lượng này. Hãy đo riêng thời gian phản hồi của nút nhận với thời gian đến khi giao dịch được đưa vào khối và được xác nhận cuối cùng trên chuỗi.
Gbps không cho biết đầy đủ về PPS và lưu lượng đột biến
Băng thông mô tả lượng dữ liệu có thể truyền theo thời gian. PPS mô tả số gói tin được xử lý mỗi giây. Một kết nối có thể vẫn còn dư băng thông nhưng đã chạm giới hạn tốc độ gói tin hoặc một hạn chế áp dụng cho UDP. Tài liệu của chính các nhà cung cấp đám mây cũng xem hạn mức băng thông và PPS là hai ràng buộc riêng biệt.[1]
Shreds không nhất thiết đến với tốc độ đều đặn. Một đợt lưu lượng đột biến có thể tạo áp lực lên hàng đợi mà giá trị trung bình không thể hiện được. Nếu gói tin tích tụ nhanh hơn tốc độ xử lý của thiết bị mạng hoặc bên nhận, những gói vượt quá sức chứa của hàng đợi có thể bị loại bỏ.[2]
Hãy hỏi nhà cung cấp dịch vụ lưu trữ máy chủ về việc nhận UDP liên tục, các đợt lưu lượng đột biến ngắn, giới hạn PPS và những quy tắc được cơ chế bảo vệ DDoS áp dụng. Mục tiêu là thiết lập các điều kiện cho phép lưu lượng cần thiết đi qua một cách an toàn, thay vì tắt cơ chế bảo vệ một cách tùy tiện.
gRPC hoạt động không chứng minh rằng việc nhận UDP cũng hoạt động
gRPC dựa trên TCP và Shreds thô qua UDP sử dụng các cơ chế truyền tải khác nhau. TCP cung cấp khả năng truyền lại và sắp thứ tự, còn gRPC dạng luồng có cơ chế điều khiển luồng tính đến khả năng của bên nhận. Bản thân UDP không truyền lại các gói bị mất hoặc buộc bên gửi chờ ứng dụng nhận xử lý kịp.[3]
Vì vậy, gRPC hoạt động trên một máy chủ không chứng minh rằng đường truyền UDP hoặc bên nhận đang hoạt động chính xác. Cần kiểm tra riêng các bộ lọc, cổng, đường truyền và cách triển khai bên nhận theo từng giao thức. Độ trễ xử lý gRPC cũng có thể biểu hiện thành thời gian chờ hoặc tình trạng ngắt kết nối.
transactions/sec trên gRPC và packets/sec trên UDP đo các đơn vị khác nhau ở những giai đoạn xử lý khác nhau. Không thể so sánh trực tiếp chúng để tính lượng dữ liệu truyền đến hoặc tỷ lệ mất dữ liệu.
Từ gói tin nhận được đến dữ liệu sử dụng được
Với bộ nhận dùng socket UDP tiêu chuẩn, các gói tin đến đi qua NIC, nhân hệ điều hành và bộ đệm nhận của socket trước khi tới ứng dụng. Nếu quá trình xử lý không theo kịp, chúng có thể bị loại bỏ sau khi đã đến máy chủ. Các bộ đếm nhận của giao diện Linux bao gồm cả những gói bị loại bỏ ở các giai đoạn sau, nên chỉ riêng việc số đếm nhận tăng lên không chứng minh được gói tin đã được chuyển đến ứng dụng.[4]
Một hàng đợi nhận hoặc một lõi CPU riêng lẻ có thể chịu tải cao ngay cả khi mức sử dụng CPU tổng thể thấp. Hãy kiểm tra các hàng đợi NIC, cách phân bổ ngắt và hiệu năng đơn lõi. Trong ứng dụng, hãy tách khâu nhận khỏi các công việc xử lý tiếp theo khi phù hợp, tránh đưa các thao tác phân tích cú pháp tốn tài nguyên và việc ghi log quá mức vào vòng lặp nhận. Bộ đệm nhận lớn hơn có thể hấp thụ những đợt lưu lượng đột biến tạm thời; nó không thể khắc phục tình trạng thiếu năng lực xử lý kéo dài.[5]
Shreds là các mảnh dữ liệu khối. Cơ chế sửa lỗi chuyển tiếp (FEC) có thể khôi phục dữ liệu bị thiếu bằng data shreds và coding shreds trong cùng một nhóm, nhưng việc tái dựng vẫn cần đủ số mảnh. Có thêm các gói tin trùng lặp không thể thay thế cho những mảnh còn thiếu.[6]
Tùy theo cách triển khai, bên nhận có thể tái dựng các entry từ những mảnh hiện có trước khi toàn bộ slot hoàn tất.[9] Bên cạnh tổng số gói tin, hãy đo số Shreds hợp lệ không trùng lặp, dữ liệu đã tái dựng và thời gian đến khi ứng dụng nhận biết được sự kiện cần thiết.
Đo từng giai đoạn trong cùng một khoảng thời gian
Hãy thống nhất đích đến, cổng và khoảng thời gian đo ở cả hai bên. Ghi nhận riêng các giai đoạn sau giúp thu hẹp phạm vi điều tra tiếp theo.
| Điểm đo | Nội dung cần ghi nhận | Điều có thể xác định |
|---|---|---|
| Bên gửi | Ghi nhận cho đích đến mục tiêu và định nghĩa của bộ đếm | Giai đoạn gửi nào đã được quan sát |
| Điểm vào của máy chủ nhận | Bản bắt gói của lưu lượng UDP mục tiêu, thống kê NIC và số gói bị mất khi bắt gói | Mức lưu lượng quan sát được tại điểm đó |
| Hệ điều hành và socket | Lỗi UDP, gói bị loại bỏ ở bộ đệm nhận và thay đổi của hàng đợi | Việc tiếp nhận có bị tồn đọng bên trong máy chủ hay không |
| Tái dựng Shreds | Shreds hợp lệ không trùng lặp, tái dựng thành công, dữ liệu còn thiếu và lỗi | Các gói tin có tạo ra dữ liệu cần thiết hay không |
| Ứng dụng | Công việc xử lý tồn đọng và dấu thời gian phát hiện cùng một sự kiện | Tốc độ dữ liệu đến có được phản ánh ở ứng dụng hay không |
Nếu bản bắt gói cho thấy có ít gói tin, trước tiên hãy kiểm tra bộ lọc, giao diện được quan sát, số gói bị mất khi bắt gói và gói bị loại bỏ tại NIC. Một số bộ đếm của hệ điều hành bao quát toàn bộ máy chủ hoặc không gian tên mạng; hãy kiểm tra phạm vi của chúng và đối chiếu với số liệu đo từ ứng dụng mục tiêu.[4][5]
Hãy thay đổi thiết lập sau khi xác định được giai đoạn bị giới hạn. Chỉ tăng kích thước bộ đệm hoặc hàng đợi vòng có thể chuyển nút thắt sang nơi khác hoặc làm tăng thời gian chờ. Cấu hình và các bước kiểm tra bên nhận hiện tại của ERPC được ghi lại tại đây:
Chọn cả chính sách vận hành lẫn máy chủ
Solana Foundation giải thích tầm quan trọng của việc kiểm soát NIC, lõi vật lý, trình điều khiển và mạng đối với các validator hiệu năng cao. Không nên áp dụng nguyên xi các yêu cầu của một validator hoàn chỉnh cho mọi bộ nhận Shreds. Một ứng dụng nhận cần cấu hình phù hợp với luồng dữ liệu và khối lượng công việc xử lý của chính nó.[7]
Giảm chi phí hoặc mức tiêu thụ điện là một mục tiêu vận hành hợp lý. Các ứng dụng HFT và thời gian thực đồng thời cũng cần CPU phản hồi nhanh, năng lực xử lý duy trì liên tục và thời gian chờ mạng ngắn. Việc đánh thức CPU từ trạng thái tiết kiệm điện có thể đi kèm sự đánh đổi về độ trễ.[8]
Bên cạnh mẫu CPU và số lõi, hãy kiểm tra cách chia sẻ tài nguyên, cách xử lý tải kéo dài, các điều kiện dành cho lưu lượng UDP và đường truyền mạng thực tế.
ERPC xem xét đồng thời luồng dữ liệu và môi trường nhận
ERPC chú trọng lựa chọn trung tâm dữ liệu gần hạ tầng Solana, đường truyền mạng, phần cứng và thiết lập vận hành, đồng thời cung cấp VPS và Bare Metal cùng với Shreds và gRPC. Bạn có thể chọn VPS phù hợp với khối lượng công việc xử lý và so sánh với Bare Metal khi muốn sử dụng riêng tài nguyên vật lý.
Hiểu cấu hình và cách vận hành của các môi trường mà chúng tôi cung cấp cũng hỗ trợ việc khắc phục sự cố kỹ thuật. Chúng tôi có thể đối chiếu ghi nhận ở bên gửi với số liệu đo của bên nhận và xác định những kiểm tra cụ thể cho mạng, hệ điều hành hoặc ứng dụng. Trong yêu cầu hỗ trợ được mô tả ở đây, chúng tôi đã kiểm tra số liệu đo ở bên gửi và đề nghị bên nhận thực hiện thêm phép đo.
Đánh giá đồng thời luồng dữ liệu, vị trí bên nhận và cách triển khai ứng dụng giúp dễ xác định những điều còn thiếu giữa dịch vụ bạn đã chọn và dữ liệu bạn cần.
So sánh với môi trường hiện tại bằng hình thức tính phí theo giờ
Nếu chưa chắc chắn về môi trường nhận của mình, hãy thử một máy chủ ERPC VPS hoặc Bare Metal với hình thức tính phí theo giờ và so sánh bằng cùng luồng dữ liệu và ứng dụng. Kiểm tra bảng điều khiển để biết giá hiện hành, tình trạng sẵn có và điều kiện đặt hàng ở khu vực bạn muốn sử dụng.
Bắt đầu với một cấu hình đang có sẵn và ghi lại số lượng gói tin nhận được, dữ liệu đã tái dựng, công việc xử lý tồn đọng và dấu thời gian phát hiện cùng các sự kiện. Khi so sánh dấu thời gian giữa các máy chủ, hãy kiểm tra cả độ chính xác của việc đồng bộ đồng hồ. Lặp lại thử nghiệm vào những thời điểm khác nhau và so sánh xem kết quả khác biệt ở đâu trên đường truyền. Dùng các số liệu đo đó để chọn máy chủ và trung tâm dữ liệu phù hợp với ứng dụng.
- VPS: https://erpc.global/vi/vps/
- Bare Metal: https://erpc.global/vi/baremetal/
- Bảng điều khiển: https://dashboard.erpc.global/vi/
Bài viết liên quan
- Solana Stream SDK v4.0.0: https://erpc.global/vi/news/2026/11/07/erpc-solana-stream-sdk-v4-20261107/
- [9] Shreds UDP Forwarding Premium: https://erpc.global/vi/news/2026/11/03/erpc-shreds-udp-forwarding-premium-20261103/
- Discord chính thức của Validators DAO: https://discord.gg/C7ZQSrCkYR
Tài liệu tham khảo kỹ thuật
- [1] Hạn mức băng thông và PPS của AWS EC2: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html
- [2] Hướng dẫn sử dụng UDP của IETF, lưu lượng đột biến: https://www.rfc-editor.org/rfc/rfc8085.html#section-3.1.6
- [3] UDP trên Linux: https://man7.org/linux/man-pages/man7/udp.7.html
- [3] TCP trên Linux: https://man7.org/linux/man-pages/man7/tcp.7.html
- [3] Điều khiển luồng gRPC: https://grpc.io/docs/guides/flow-control/
- [4] Thống kê giao diện mạng Linux: https://docs.kernel.org/networking/statistics.html
- [4] Cách bắt gói và các gói bị loại bỏ trong libpcap: https://github.com/the-tcpdump-group/libpcap/blob/master/doc/README.linux
- [5] Mở rộng khả năng xử lý của ngăn xếp mạng Linux: https://docs.kernel.org/networking/scaling.html
- [5] Bộ đệm nhận của socket Linux: https://man7.org/linux/man-pages/man7/socket.7.html
- [5] Điều tra tình trạng loại bỏ gói UDP của Red Hat: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/network_troubleshooting_and_performance_tuning/tuning-udp-connections
- [6] Cơ chế lan truyền khối Turbine của Anza: https://docs.anza.xyz/consensus/turbine-block-propagation/
- [7] Solana Foundation, phần cứng cho validator hiệu năng cao: https://solana.com/news/high-performance-solana-validators-run-on-bare-metal-hardware
- [8] Quản lý thời gian CPU nhàn rỗi trên Linux: https://docs.kernel.org/admin-guide/pm/cpuidle.html
