Bạn có chia sẻ rằng ASan có thể bị 'im lặng' (bỏ sót lỗi) do trình biên dịch tối ưu hóa (Optimization) mất đoạn code lỗi trước khi kịp kiểm tra. Mình đang thắc mắc trong thực tế, khi fuzzing hoặc tìm 0-day cho các dự án lớn, làm thế nào để chúng ta cân bằng giữa việc bật flag tối ưu hóa (như -O2, -O3) để mô phỏng chính xác hành vi của bản release, với việc giữ lại độ chính xác cao nhất cho ASan (thường khuyến nghị -O1 hoặc -O0)?
Câu hỏi cực kỳ thực tế luôn bạn owii. Trong case cháy nhà mà kẹt số lượng partition, trick cứu cánh xịn nhất ở tầng app là áp dụng Multi-threading ngay bên trong Consumer. Bạn có thể tuning tăng tham số max.poll.records và fetch.max.bytes lên để kéo một batch thật to, sau đó ném cục data này vào một Thread Pool (như ExecutorService của Java) để xử lý song song thay vì làm tuần tự, xử lý xong hết batch thì mới commit offset bằng tay. Trong trường hợp luồng log yêu cầu khắt khe về thứ tự (ordering) khiến chạy multi-thread dễ bị sai logic, thì cách chữa cháy nhanh nhất là thiết kế một "Overflow Topic" (với số lượng partition lớn hơn hẳn), cho consumer hiện tại làm nhiệm vụ duy nhất là dump/forward thẳng data sang đó để dọn sạch lag ngay lập tức, rồi mới cho một nhóm consumer mới nhẩn nha xử lý ở phía sau
Case này đúng nỗi đau chung khi phải gánh mấy bảng vài trăm triệu record. Nếu business vẫn ép giữ UX nhảy cóc sang trang N, cách "cứu cánh" ngon nhất là dùng trick Deferred Join: bạn chỉ SELECT id ... LIMIT OFFSET (có đánh index chuẩn thì nó chạy rất mượt), xong lấy tập ID đó JOIN ngược lại bảng chính để lấy full data, còn quả COUNT(*) thì vứt luôn vào Redis cache chứ tuyệt đối không đếm realtime. Tất nhiên, tối ưu nhất vẫn là deal lại với Business để giới hạn chỉ cho hiển thị tối đa khoảng 100 trang đầu (bắt user thêm filter nếu muốn tìm sâu hơn giống Google) hoặc chuyển hẳn sang Cursor-based nếu UI là dạng lướt vuốt. Không biết bảng dữ liệu bạn đang tối ưu có hay bị dính nhiều điều kiện filter động đan chéo nhau không nhỉ?
DISCUSSIONS
Rất dễ hiểu, cảm ơn tác giả
Atomic nữa đi tác giả ơiii
Đọc nó sướng gì đâu lun á, rất dễ hiểu
NGUYỄN HUY HOÀNG Software Engineer
📞 Phone: 0941 280 073
📧 Email: hhoang02052004@gmail.com
NGUYỄN HUY HOÀNG Software Engineer
📞 Phone: 0941 280 073
📧 Email: hhoang02052004@gmail.com
Bạn có chia sẻ rằng ASan có thể bị 'im lặng' (bỏ sót lỗi) do trình biên dịch tối ưu hóa (Optimization) mất đoạn code lỗi trước khi kịp kiểm tra. Mình đang thắc mắc trong thực tế, khi fuzzing hoặc tìm 0-day cho các dự án lớn, làm thế nào để chúng ta cân bằng giữa việc bật flag tối ưu hóa (như -O2, -O3) để mô phỏng chính xác hành vi của bản release, với việc giữ lại độ chính xác cao nhất cho ASan (thường khuyến nghị -O1 hoặc -O0)?
NGUYỄN HUY HOÀNG Software Engineer
📞 Phone: 0941 280 073
📧 Email: hhoang02052004@gmail.com
Câu hỏi cực kỳ thực tế luôn bạn owii. Trong case cháy nhà mà kẹt số lượng partition, trick cứu cánh xịn nhất ở tầng app là áp dụng Multi-threading ngay bên trong Consumer. Bạn có thể tuning tăng tham số max.poll.records và fetch.max.bytes lên để kéo một batch thật to, sau đó ném cục data này vào một Thread Pool (như ExecutorService của Java) để xử lý song song thay vì làm tuần tự, xử lý xong hết batch thì mới commit offset bằng tay. Trong trường hợp luồng log yêu cầu khắt khe về thứ tự (ordering) khiến chạy multi-thread dễ bị sai logic, thì cách chữa cháy nhanh nhất là thiết kế một "Overflow Topic" (với số lượng partition lớn hơn hẳn), cho consumer hiện tại làm nhiệm vụ duy nhất là dump/forward thẳng data sang đó để dọn sạch lag ngay lập tức, rồi mới cho một nhóm consumer mới nhẩn nha xử lý ở phía sau
Cảm ơn bạn đã ủng hộ, hay thì share cho mn cùng đọc nhé
Case này đúng nỗi đau chung khi phải gánh mấy bảng vài trăm triệu record. Nếu business vẫn ép giữ UX nhảy cóc sang trang N, cách "cứu cánh" ngon nhất là dùng trick Deferred Join: bạn chỉ SELECT id ... LIMIT OFFSET (có đánh index chuẩn thì nó chạy rất mượt), xong lấy tập ID đó JOIN ngược lại bảng chính để lấy full data, còn quả COUNT(*) thì vứt luôn vào Redis cache chứ tuyệt đối không đếm realtime. Tất nhiên, tối ưu nhất vẫn là deal lại với Business để giới hạn chỉ cho hiển thị tối đa khoảng 100 trang đầu (bắt user thêm filter nếu muốn tìm sâu hơn giống Google) hoặc chuyển hẳn sang Cursor-based nếu UI là dạng lướt vuốt. Không biết bảng dữ liệu bạn đang tối ưu có hay bị dính nhiều điều kiện filter động đan chéo nhau không nhỉ?
Cảm ơn b. Follow để nhận thông báo khi mình ra bài mới nhé
Cảm ơn b. Follow để nhận thông báo khi mình ra bài mới nhé
Sớm thôi nè, chờ tin mình
Buồn ngủ gặp chiếu manh à kkk
Cảm ơn bạn đã ủng hộ nhé, thấy hay thì chia sẻ mọi người cùng đọc nhé
Xin xò thật khum 😘
Một khi đã nắm được bản chất thì mọi thứ nó đơn giản hơn nhiều =)))
Chắc chắn rồi, cảm ơn b đã ủng hộ nhé
Mình còn muốn nó phải chi tiết hơn nữa cơ kkk
ngấm rồi thì hãy áp dụng luôn và ngay nhé