Build project chậm: nâng RAM hay nâng SSD trước mới đúng chỗ?

Bấm build xong rồi đi pha cốc cà phê, quay lại vẫn thấy thanh tiến trình đứng im. Lúc đó câu hỏi quen thuộc lại hiện lên: nên bỏ tiền nâng RAM hay đổi sang SSD nhanh hơn? Câu trả lời đúng không nằm ở linh kiện nào "xịn" hơn, mà ở việc máy bạn đang kẹt ở đâu. Bài này chỉ cách đo trong 5 phút để biết chắc trước khi rút ví.

Build thực chất làm gì với máy của bạn

Một lần build, dù là npm run build, Gradle, Maven, cargo build hay biên dịch C++, đều lặp đi lặp lại ba việc:

1. Đọc hàng nghìn đến hàng chục nghìn file nhỏ từ ổ đĩa: mã nguồn, thư viện trong node_modules, file .jar, header, cache.
2. Giữ dữ liệu trung gian trong bộ nhớ: cây cú pháp (AST), đồ thị phụ thuộc, bộ nhớ heap của JVM hay Node, nhiều tiến trình compiler chạy song song.
3. Ghi kết quả ra đĩa: file object, bundle, cache build, artifact.

CPU là bên làm việc nặng nhất, nhưng nó chỉ chạy hết tốc độ khi dữ liệu được đưa tới kịp. Nếu ổ đĩa đọc file chậm, CPU phải ngồi chờ. Nếu RAM không đủ chỗ, hệ điều hành phải đẩy bớt dữ liệu xuống ổ đĩa (gọi là swap hoặc pagefile), và lúc đó mọi thứ chậm đi gấp nhiều lần.

Vì vậy RAM và SSD không cạnh tranh nhau. Chúng giải quyết hai kiểu nghẽn khác nhau, và nâng nhầm thứ thì gần như không cải thiện gì.

Khi nào RAM là thủ phạm

RAM là bàn làm việc của máy. Bàn càng rộng, càng bày được nhiều thứ cùng lúc mà không phải cất vào tủ rồi lấy ra lại.

Dấu hiệu RAM đang thiếu khi build:

• Bộ nhớ sử dụng chạm 90–100% trong lúc build.
• Ổ đĩa đột nhiên hoạt động liên tục dù bạn không mở file gì, đó là hệ điều hành đang swap.
• Build lần đầu và build lần sau chậm như nhau, vì không còn RAM trống để hệ điều hành giữ file vừa đọc làm cache.
• Mở IDE, trình duyệt, Docker cùng lúc thì máy giật cả chuột.
• Gặp lỗi kiểu JavaScript heap out of memory hoặc OutOfMemoryError: Java heap space.

Môi trường lập trình hiện đại ăn RAM nhiều hơn ta tưởng. Một phiên làm việc điển hình có IDE (VS Code với vài extension, hoặc IntelliJ), trình duyệt với chục tab tài liệu, Docker chạy database, cộng thêm chính tiến trình build. Riêng Docker Desktop trên Windows và macOS chạy trong một máy ảo nên đã giữ sẵn một phần RAM riêng.

Khi nào SSD là thủ phạm

Ổ đĩa là tủ hồ sơ. Build cần lôi ra hàng chục nghìn tờ giấy nhỏ, và tốc độ lôi từng tờ quan trọng hơn tốc độ chuyển một thùng lớn.

Đây là điểm nhiều người hiểu sai: con số "đọc 7.000 MB/s" in trên hộp SSD là tốc độ đọc tuần tự, đo bằng file lớn liền mạch. Build thì đọc rất nhiều file nhỏ rải rác, nên thứ quyết định là tốc độ đọc ngẫu nhiên khối nhỏ (4K random) và độ trễ.

Dấu hiệu ổ đĩa đang là điểm nghẽn:

• Máy vẫn đang dùng HDD cho ổ hệ điều hành hoặc thư mục project. Đây là trường hợp rõ ràng nhất.
• Trong lúc build, cột Disk hoạt động gần 100% trong khi RAM vẫn còn trống nhiều.
• npm install, git checkout sang nhánh khác, giải nén dependency đều chậm.
• Ổ SSD đã gần đầy. SSD đầy quá thường ghi chậm đi đáng kể vì bộ đệm và vùng trống để sắp xếp dữ liệu bị thu hẹp.

Đo trong 5 phút trước khi mua

Cách đơn giản nhất: mở công cụ theo dõi, chạy build, nhìn xem cột nào chạm trần.

Trên Windows

Mở Task Manager (Ctrl + Shift + Esc), sang tab Performance, rồi chạy build. Quan sát ba mục:

• Memory: nếu "In use" sát tổng dung lượng và "Committed" vượt dung lượng RAM thật, máy đang dựa vào pagefile.
• Disk: nếu "Active time" đứng 100% kéo dài, ổ đĩa là điểm nghẽn.
• CPU: nếu tất cả nhân đều gần 100%, chính CPU đang bận, nâng RAM hay SSD đều ít tác dụng.

Muốn chi tiết hơn, mở Resource Monitor (gõ resmon vào ô Run) và xem cột Hard Faults/sec ở tab Memory. Con số này cao liên tục trong lúc build là dấu hiệu rõ của thiếu RAM.

Trên Linux

# Xem RAM và swap đang dùng
free -h

# Theo dõi mỗi giây: cột si/so khác 0 liên tục nghĩa là đang swap
vmstat 1

# Xem mức bận của ổ đĩa (cột %util), cần gói sysstat
iostat -x 1

Trên macOS

Mở Activity Monitor, tab Memory, nhìn biểu đồ Memory Pressure. Màu xanh là ổn, vàng là bắt đầu căng, đỏ là thiếu RAM thật sự. Trên các máy Apple Silicon, RAM hàn chết nên không nâng được, đây là lý do nên cân nhắc kỹ dung lượng ngay lúc mua.

Bảng quyết định nhanh

Với máy làm lập trình hiện nay, một mốc tham khảo phổ biến:

• 8 GB: chỉ đủ cho project nhỏ, sẽ chật khi mở IDE cùng trình duyệt và Docker.
• 16 GB: mức tối thiểu dễ chịu cho web, mobile hoặc backend thông thường.
• 32 GB trở lên: hợp với Android Studio, nhiều container Docker, project C++ hoặc monorepo lớn, máy ảo.

Đây là kinh nghiệm thực tế chứ không phải con số tuyệt đối. Kết quả đo trên chính máy bạn luôn đáng tin hơn.

Nâng cấp sao cho đúng

Nâng RAM

• [ ]Kiểm tra máy còn khe trống hay RAM đã hàn chết trên bo mạch. Nhiều laptop mỏng nhẹ không nâng được.
• [ ]Xác định đúng chuẩn: DDR4 hay DDR5, DIMM (máy bàn) hay SO-DIMM (laptop). Hai chuẩn không cắm lẫn được.
• [ ]Ưu tiên lắp theo cặp để chạy dual channel, băng thông bộ nhớ tăng đáng kể so với một thanh.
• [ ]Xem dung lượng tối đa bo mạch hoặc CPU hỗ trợ trong tài liệu của hãng.
• [ ]Sau khi lắp, kiểm tra trong Task Manager mục "Slots used" và "Speed" để chắc RAM được nhận đủ.

Nâng SSD

• [ ]Kiểm tra máy có khe M.2 không và khe hỗ trợ NVMe hay chỉ SATA. Một số khe M.2 đời cũ chỉ chạy SATA.
• [ ]Máy cũ chỉ có khay 2.5 inch thì SSD SATA vẫn là bước nâng cấp rất đáng tiền so với HDD.
• [ ]Chọn dung lượng dư dả. node_modules, cache Gradle, image Docker và SDK chiếm chỗ rất nhanh.
• [ ]Ưu tiên ổ có DRAM cache hoặc HMB nếu thường xuyên ghi nhiều, giúp tốc độ ổn định hơn khi làm việc nặng.
• [ ]Chuyển cả hệ điều hành và thư mục project sang SSD mới. Để project lại trên HDD thì coi như chưa nâng.

Những cách tăng tốc build gần như miễn phí

Trước khi chi tiền, thử những việc này:

• Loại thư mục project khỏi quét virus thời gian thực. Trên Windows, Microsoft Defender quét từng file được đọc và ghi, làm chậm đáng kể các thao tác với rất nhiều file nhỏ. Windows 11 có tính năng Dev Drive dành riêng cho việc này. Chỉ loại trừ thư mục project bạn tin tưởng.
• Bật cache build của công cụ bạn dùng: build cache và daemon của Gradle, cache của Turborepo hoặc Nx, ccache cho C/C++.
• Đóng bớt ứng dụng ngốn RAM trong lúc build, nhất là trình duyệt nhiều tab và máy ảo không dùng.
• Giới hạn RAM cho Docker hoặc WSL2 vừa đủ, tránh để chúng giữ quá nhiều bộ nhớ của hệ thống.
• Dọn ổ đĩa, giữ SSD còn trống một khoảng hợp lý để tốc độ ghi không bị tụt.
• Trên WSL2, để project trong hệ thống file Linux thay vì /mnt/c, vì truy cập chéo sang ổ Windows chậm hơn nhiều.

Nâng cấp đúng chỗ nghẽn thì vài trăm nghìn cũng thấy khác biệt. Nâng nhầm chỗ thì vài triệu cũng chẳng nhanh thêm giây nào.

Tóm tắt nhanh

• Còn dùng HDD: lên SSD trước, đây là nâng cấp có hiệu quả rõ nhất.
• Đã có SSD mà RAM chạm trần, có swap khi build: nâng RAM, ưu tiên lắp theo cặp.
• Đã có NVMe và đủ RAM: đổi SSD đời mới hơn ít tác dụng, hãy nhìn sang CPU và cấu hình cache build.
• Luôn đo bằng Task Manager, Activity Monitor hoặc vmstat, iostat trong lúc build trước khi mua.
• Thử các cách miễn phí trước: loại trừ antivirus, bật cache build, dọn ổ.

Câu hỏi thường gặp

Laptop 8 GB RAM với HDD thì nâng cái nào trước?

Lên SSD trước. Với HDD, mọi thứ từ khởi động máy, mở IDE đến đọc file khi build đều chậm. Sau đó, nếu đo thấy RAM vẫn chạm trần, nâng tiếp lên 16 GB.

Mua RAM bus cao hơn có giúp build nhanh hơn không?

Có nhưng thường ít. Dung lượng đủ và chạy dual channel quan trọng hơn nhiều so với tăng tốc độ bus. Hãy dùng đúng tốc độ mà bo mạch và CPU hỗ trợ.

Tăng pagefile hoặc swap có thay được việc nâng RAM không?

Không. Tăng swap chỉ giúp máy không bị crash hay báo hết bộ nhớ, nhưng dữ liệu nằm trên ổ đĩa vẫn chậm hơn RAM rất nhiều. Đó là cách chữa cháy, không phải cách tăng tốc.

SSD NVMe Gen 4 có đáng tiền hơn Gen 3 cho lập trình không?

Với build thông thường, chênh lệch thời gian thường nhỏ vì build chủ yếu đọc file nhỏ ngẫu nhiên. Nếu ngân sách có hạn, ổ Gen 3 dung lượng lớn hơn thường là lựa chọn thực tế hơn ổ Gen 4 dung lượng nhỏ.