<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Dat Luong blog</title><link>https://datluongductuan.github.io/</link><description>Recent content on Dat Luong blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 04 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://datluongductuan.github.io/index.xml" rel="self" type="application/rss+xml"/><item><title>Tại sao PostgreSQL chọn PANIC khi fsync thất bại? Tìm hiểu về tính bền vững trong database</title><link>https://datluongductuan.github.io/post/tai-sao-postgresql-chon-panic-khi-fsync-that-bai/</link><pubDate>Sat, 04 Apr 2026 00:00:00 +0000</pubDate><guid>https://datluongductuan.github.io/post/tai-sao-postgresql-chon-panic-khi-fsync-that-bai/</guid><description>~17 phút đọc
Vào 1 ngày đóng vai sinh viên hệ &amp;ldquo;online&amp;rdquo; của trường Carnegie Mellon University, nghe thầy Andy Pavlo giảng về database, đọc đến đoạn Postgresql sẽ panic khi gọi system call fsync() bị lỗi. Tôi thực sự bất ngờ, lý do đơn giản thôi, một tượng đài database như vậy phải xử lý mượt mà không vết xước chứ nhỉ, vậy tính Durable trong 4 nguyên tắc ACID của hệ quản trị cơ sở dữ liệu như nào?</description></item><item><title>Quản lý bộ nhớ trong ngôn ngữ lập trình</title><link>https://datluongductuan.github.io/post/memory-management/</link><pubDate>Mon, 16 Mar 2026 00:00:00 +0000</pubDate><guid>https://datluongductuan.github.io/post/memory-management/</guid><description>Trong suốt nhiều thập kỷ, lịch sử khoa học máy tính đã chứng kiến một sự dịch chuyển mang tính triết lý: chuyển giao trách nhiệm quản lý vùng nhớ từ Lập trình viên sang Trình biên dịch (Compiler) và Môi trường thực thi (Runtime).
Việc đẩy phần quản lý bộ nhớ cho lập trình viên hay bộ dọn rác (GC) xử lý sẽ tuỳ vào mục đích của người tạo ngôn ngữ lập trình.</description></item><item><title>Tìm hiểu về độ trễ trong bộ xử lý trung tâm và ổ cứng: Tối ưu hóa hiệu suất hệ thống</title><link>https://datluongductuan.github.io/post/do-tre-trong-cpu-va-o-cung/</link><pubDate>Sun, 23 Mar 2025 00:00:00 +0000</pubDate><guid>https://datluongductuan.github.io/post/do-tre-trong-cpu-va-o-cung/</guid><description>Truy cập qua ổ đĩa thì bao giờ cũng chậm hơn là xử lý trên RAM rồi, qua CPU Cache còn nhanh hơn nữa, vậy tận dụng và ứng dụng vào thực tế như nào? Mời anh em tham khảo bài này.
Độ trễ (Latency) Đầu tiên, nói về độ trễ, chúng ta có một số ý chính như sau:
Truy xuất từ ổ đĩa sẽ chậm hơn 80 lần so với RAM, dù thay thế bằng ổ SSD thì vẫn chậm hơn 4 lần so với RAM Sắp xếp theo thứ tự nhanh nhất trước, chúng ta có:</description></item><item><title>[Case study] Tôi đã tối ưu 1 query PostgreSQL từ ~60s xuống còn ~2s như thế nào</title><link>https://datluongductuan.github.io/post/toi-uu-query-postgresql-60s-xuong-2s/</link><pubDate>Sat, 11 Jan 2025 00:00:00 +0000</pubDate><guid>https://datluongductuan.github.io/post/toi-uu-query-postgresql-60s-xuong-2s/</guid><description>TLDR;
Đánh index với WHERE mà WHERE chỉ filter được 50% rows thì planner PostgreSQL chọn seq scan (full table scan) vì hiệu quả hơn. PostgreSQL để cấu hình mặc định shared_buffer 128MB, mà tài nguyên RAM máy chủ đang có nhiều hơn → cần tăng lên để tận dụng hết tài nguyên. Dữ liệu query theo nghiệp vụ quá nhiều, từ 500MB đến 1GB cho 1 bảng xong câu lệnh SQL lại UNION ALL ghép lại → cần áp dụng một số cơ chế sử dụng bộ nhớ đệm như mview, cache superset hoặc thêm filter timestamp.</description></item></channel></rss>