Giới hạn bộ nhớ của trình duyệt khi xử lý tệp
File của tôi chỉ có 15 MB. Sao tab trình duyệt lại hết bộ nhớ?
Tệp trên ổ đĩa là bản đã nén
Toàn bộ hiểu lầm gói gọn trong một câu: con số bạn thấy trong trình quản lý tệp là dung lượng của dữ liệu đã nén, mà không gì xử lý được khi nó còn đang ở dạng nén. Để thay đổi kích thước, nén lại, chuyển đổi hay phân tích một tấm ảnh, trước hết nó phải được giải mã thành pixel thô, và pixel thô thì khổng lồ.
Phép tính rất đơn giản. Một pixel trong bộ nhớ thường chiếm bốn byte — đỏ, lục, lam và alpha. Một tấm ảnh 4000 × 3000 có mười hai triệu pixel, nên bitmap sau giải mã vào khoảng 48 MB. Tệp JPEG mà nó bung ra từ đó có thể chỉ nặng 4 MB. Tệp đã phình lên gấp mười hai lần trước khi bất kỳ công việc nào bắt đầu.
| Kích thước | Số pixel | Bitmap sau giải mã |
|---|---|---|
| 1920 × 1080 | 2.1 triệu | khoảng 8 MB |
| 4000 × 3000 | 12 triệu | khoảng 48 MB |
| 6000 × 4000 | 24 triệu | khoảng 96 MB |
| 10000 × 10000 | 100 triệu | khoảng 400 MB |
Và một bản sao thì không bao giờ đủ
Một dây chuyền xử lý thực tế giữ nhiều bản sao cùng lúc: các byte đầu vào đã nén, bitmap nguồn sau giải mã, một bitmap đầu ra ở kích thước mới, các vùng đệm nội bộ của bộ mã hoá, và kết quả đã nén. Một công cụ có hiển thị bản xem trước cho bạn thì giữ thêm một bản nữa. Với tấm ảnh 4000 × 3000 ở trên, một đỉnh chiếm dụng hai đến ba trăm megabyte là hoàn toàn bình thường, cho một tệp trông có vẻ chỉ 4 MB.
Việc raster hoá PDF hành xử y hệt, theo từng trang: một trang A4 kết xuất ở 300 DPI vào khoảng 2480 × 3508 pixel, tức chừng 35 MB sau giải mã, và một công cụ kết xuất nhiều trang cùng lúc thì nhân con số đó lên. Video còn tệ hơn nữa, vì một bộ giải mã cần giữ đồng thời vài khung hình tham chiếu trong bộ nhớ.
Trần thật sự nằm ở đâu
- Hạn mức bộ nhớ của một tab do trình duyệt đặt ra chứ không phải trang web, và nó nhỏ hơn dung lượng bộ nhớ lắp trên máy. Nó còn co lại khi các tab khác đang bận.
- Các mô-đun WebAssembly dựng theo mô hình bộ nhớ 32-bit phổ biến chỉ định địa chỉ được tối đa bốn gibibyte, mà trình duyệt thường cho phép ít hơn hẳn con số đó cho mỗi thực thể.
- Từng vùng đệm riêng lẻ lại có độ dài tối đa của riêng nó, thấp hơn nhiều so với tổng bộ nhớ mà một trang được phép dùng.
- Hệ điều hành di động sẽ giết một tab phình to quá mức, không báo trước và không sinh ra lỗi nào để trang bắt được.
- Bộ nhớ đồ hoạ là một nguồn riêng và nhỏ hơn. Một canvas lớn hơn kích thước tối đa của nền tảng sẽ đơn giản là thất bại, dù bộ nhớ hệ thống còn trống bao nhiêu đi nữa.
Không con số nào trong đây được công bố thành một mốc duy nhất để tra cứu, vì chúng phụ thuộc vào trình duyệt, vào phiên bản, vào thiết bị và vào những gì đang chạy song song. Đó mới là cái khó thật sự: một công cụ không thể hỏi xem nó được dùng bao nhiêu bộ nhớ.
Vì sao điện thoại là trường hợp ngặt nghèo
Điện thoại có ít bộ nhớ vật lý hơn, không có swap theo nghĩa như trên máy tính để bàn, và một hệ điều hành rất mạnh tay thu hồi bộ nhớ từ các tiến trình chạy nền. Một tab trình duyệt trở thành tiến trình nền ngay khoảnh khắc bạn trả lời một tin nhắn. Vì vậy trình duyệt di động giữ hạn mức chặt hơn và nhanh tay huỷ một tab hơn, mà cú huỷ ấy với bạn thường trông như trang tự tải lại và làm mất công việc dang dở, chứ không giống một thông báo lỗi.
Hệ quả thực tế là một tác vụ chạy xong trên laptop có thể là bất khả thi trên điện thoại với cùng tệp đó. Đó không phải khiếm khuyết của công cụ. Đó là ranh giới phần cứng, và phản hồi trung thực là nói ra điều đó trước khi bắt đầu chứ không phải sập giữa chừng.
Một công cụ cẩn thận hành xử ra sao
- Nó ước lượng lượng bộ nhớ cần dùng từ kích thước sau giải mã trước khi cấp phát bất cứ thứ gì, và từ chối một tác vụ rõ ràng là không vừa.
- Trên một thiết bị eo hẹp, nó xử lý từng tệp một thay vì chạy song song cả lô.
- Nó chuyển các vùng đệm giữa trang và các worker thay vì sao chép chúng, nên một tệp lớn không tồn tại hai lần.
- Nó giải phóng từng kết quả ngay khi kết quả đó được ghi ra, và thu hồi những URL tạm thời vốn sẽ giữ dữ liệu sống dai.
- Nó xử lý theo luồng từng trang hoặc từng khung hình ở những định dạng cho phép, thay vì nạp cả tài liệu vào bộ nhớ.
- Nó đặt trần cho số pixel mà nó chấp nhận, và đó cũng là thứ ngăn một tệp nhỏ nhưng bung ra thành một canvas khổng lồ đánh sập cả tab.
Bạn làm được gì khi một tác vụ thất bại
- Đóng bớt các tab khác. Chúng đang tranh giành cùng một hạn mức, và trình duyệt không chia hạn mức đó một cách công bằng.
- Xử lý ít tệp hơn trong một lần. Một hàng đợi chỉ một tệp thì chậm hơn nhưng khả năng chạy xong cao hơn nhiều.
- Giảm kích thước trước. Giảm nửa cạnh dài nhất thì lượng bộ nhớ cần dùng còn một phần tư, mà đó thường cũng là điều bạn muốn ngay từ đầu.
- Tách một tệp PDF lớn ra rồi xử lý từng phần.
- Chuyển sang máy tính để bàn cho những tác vụ lớn nhất. Đây không phải thất bại của xử lý cục bộ; đây là cách dùng đúng phần cứng bạn đang có.
- Khởi động lại trình duyệt nếu một tab đã mở nhiều ngày. Các tab sống lâu tích tụ bộ nhớ mà một lần tải lại sẽ giải phóng.
Giới hạn của mọi ước lượng
Trình duyệt chỉ phơi ra một gợi ý rất thô về bộ nhớ còn trống, và có trình duyệt chẳng phơi ra gì cả. Vì vậy mọi con số mà một công cụ cục bộ hiển thị cho bạn đều là ước lượng dựng từ chính kích thước của tệp và từ một mô hình dè dặt về dây chuyền xử lý, chứ không phải một số đọc được từ hệ điều hành. Nó hữu ích để quyết định có nên thử một tác vụ hay không. Nó không phải lời hứa rằng tác vụ sẽ chạy xong, vì yếu tố quyết định — phần còn lại của thiết bị sẽ làm gì trong ba mươi giây tới — không phải thứ một trang web nhìn thấy được.
Công cụ cho việc này
Nguồn tham khảo
- W3C — WebAssembly Core Specification, memory model
- W3C — Device Memory API, and why the value is coarse
- WHATWG — HTML Standard, transferable objects