trao đổi phân vùng vs tập tin cho hiệu suất?


62

Điều gì là tốt hơn cho hiệu suất? Một phân vùng gần bên trong đĩa sẽ có thời gian truy cập chậm hơn và chúng ta phải đợi ổ đĩa chuyển đổi giữa các phân vùng hệ điều hành và trao đổi.

Mặt khác, một phân vùng trao đổi bỏ qua tất cả các hệ thống tệp cho phép ghi trực tiếp vào đĩa, có thể nhanh hơn một tệp.

Hiệu suất đánh đổi là gì?

Làm thế nào nhiều có một hoán đổi kích thước cố định làm cho một sự khác biệt?

Đây có phải là trường hợp thay đổi phân vùng trao đổi lâu hơn không, nhưng hiệu suất sẽ tốt hơn trong khi trên phân vùng trao đổi nếu đó là tệp hoán đổi?


Chỉ tò mò thôi. Bạn có thể cung cấp chi tiết hệ thống như phiên bản kernel, RAM, phân vùng và sơ đồ hệ thống tập tin không?
Viky

Bạn đang tìm kiếm hệ điều hành nào?
Lâu đài Mathieu

4
Để biết thông tin về Linux, xem lkml.org/lkml/2005/7/7/326
Adam Monsen

Bất kỳ cập nhật cho câu trả lời câu hỏi?
kokbira

Câu trả lời:


29
  1. Trên đĩa cứng, thông lượng và tìm kiếm thường nhanh hơn ở đầu đĩa, vì dữ liệu đó được lưu trữ gần khu vực bên ngoài của đĩa hơn, có nhiều cung trên mỗi hình trụ. Do đó, việc tạo trao đổi ở đầu đĩa có thể cải thiện hiệu suất.

  2. Đối với nhân Linux 2.6, không có sự khác biệt về hiệu năng giữa phân vùng trao đổi và tệp hoán đổi không phân mảnh . Khi phân vùng / tệp hoán đổi được kích hoạt bằng hoán đổi, hạt nhân 2.6 sẽ tìm thấy đĩa nào mà tệp hoán đổi được lưu trữ trên đó , để đến lúc trao đổi, nó hoàn toàn không phải xử lý hệ thống tệp.

Do đó, nếu tệp hoán đổi không bị phân mảnh, thì chính xác như thể có một phân vùng trao đổi tại cùng một vị trí. Hoặc đặt một cách khác, bạn sẽ có được hiệu suất giống hệt nhau nếu bạn sử dụng phân vùng trao đổi thô hoặc định dạng nó với một hệ thống tệp và sau đó tạo một tệp hoán đổi lấp đầy tất cả không gian, vì một trong hai cách trên đĩa đó có một vùng liền kề được sử dụng để hoán đổi, mà kernel sử dụng trực tiếp.

Vì vậy, nếu người ta tạo tệp hoán đổi khi hệ thống tệp mới (do đó đảm bảo nó không bị phân mảnh và ở đầu âm lượng), hiệu suất phải giống hệt với phân vùng trao đổi ngay trước âm lượng. Hơn nữa, nếu một người tạo ra tệp hoán đổi ở giữa âm lượng, với các tệp ở hai bên, người ta có thể có hiệu suất tốt hơn, vì ít tìm cách trao đổi hơn.

Trên Linux, nếu tệp hoán đổi được tạo ra không bị phân mảnh và không bao giờ được mở rộng, nó không thể bị phân mảnh, ít nhất là với các hệ thống tệp thông thường như ext3 / 4. Nó sẽ luôn sử dụng các khối đĩa giống nhau, liền kề nhau.

Tôi kết luận rằng về lợi ích duy nhất của phân vùng trao đổi chuyên dụng được đảm bảo không bị phân mảnh khi bạn cần mở rộng nó; nếu trao đổi của bạn sẽ không bao giờ được mở rộng, một tệp được tạo trên hệ thống tệp mới sẽ không yêu cầu phân vùng bổ sung.


5
Điều duy nhất cần thêm ở đây là nếu máy của bạn được cấu hình để "tạm dừng vào đĩa" thì điều thực sự xảy ra là những thứ trong bộ nhớ được ghi để trao đổi. Để làm việc này, trao đổi phải nằm trên phân vùng riêng của nó vì việc hoán đổi không thể nằm trên một hệ thống tập tin hoạt động để điều này xảy ra. Do đó, nếu bạn có máy chủ, có lẽ bạn không sử dụng tính năng này và có thể vui vẻ sử dụng tệp hoán đổi. Nếu bạn có máy tính xách tay, có lẽ bạn muốn có một phân vùng trao đổi để bạn có thể "tạm dừng tập tin" để ngủ đông.
Nathan S. Watson-Haigh

@ NathanS.Watson-Haigh Điều gì xảy ra với dữ liệu đã được trao đổi? Nó không thể bị vứt đi.
XtF

3
@ NathanS.Watson-Haigh Bạn có thể liên kết một nguồn không? Ubuntu 17.04 sử dụng tệp hoán đổi theo mặc định. Sẽ rất ngạc nhiên nếu nó không thể "treo vào đĩa".
Matthias Weiler

22

Trên thực tế, nó không tạo ra nhiều sự khác biệt miễn là bạn không sử dụng các tệp thưa thớt .

Tạo một tệp "bình thường" bằng dd sẽ phân bổ tệp (nếu có thể) trong một lần chạy, trong khi tạo tệp thưa sẽ cho bạn biết rằng bạn có tệp 10 GB nằm xung quanh nhưng không thực sự sử dụng hết dung lượng. Tôi không chắc chắn rằng mkswap sẽ không phân bổ không gian dù sao nhưng thông thường, một tệp hoán đổi sẽ phát triển kịp thời và do đó sẽ không phân bổ một khu vực liên tục (như một phần của đĩa) mà chỉ phân bổ các khối khi cần thiết dẫn đến phân mảnh theo thời gian (tất nhiên tùy thuộc vào cách sử dụng đĩa của bạn)

Bên trong hạt nhân Linux sẽ truy cập trực tiếp vào các khối bên dưới của tệp hoán đổi - Tôi không thể tìm thấy liên kết ngay bây giờ những gì xảy ra dưới mui xe, bạn phải tin tưởng tôi vào điều này trừ khi ai đó sẽ tìm thấy thứ gì đó chính thức hơn. Tất cả những gì tôi có thể nghĩ ra ngay bây giờ là:

tất cả chỉ áp dụng cho dòng 2.6 nhân Linux.

Nếu bạn muốn hiệu suất tối ưu (và đó thực sự là gì? ... hoán đổi là chậm, thời gian. Tăng RAM để bạn không trao đổi để có hiệu suất tốt nhất ), bạn sẽ muốn sử dụng phân vùng.


18
Các phiên bản hiện đại của hoán đổi sẽ hoàn toàn từ chối làm việc với các tệp thưa thớt được định dạng là trao đổi, với lý do tệp có lỗ hổng.
Tim Post

3

Đây là một câu hỏi thú vị và đã được đọc rất nhiều về cùng. Nói chung, một phân vùng trao đổi tốt hơn một tệp do hệ thống tệp cơ bản. Nhưng nếu bạn luôn có nhu cầu tăng kích thước trao đổi thì tập tin là một lựa chọn tốt hơn. Cho đến khi kernel 2.4 được xem là phân vùng trao đổi nhanh hơn tệp, nhưng bây giờ với những cải tiến của kernel 2.6, các hiệu suất gần như giống nhau.

Một cái gì đó tôi tìm thấy trên internet là tốt.

http://www.go2linux.org/swap-file-vs-swap-partition

http://www.sunmanager.org/pipermail/summaries/2005-November/006913.html


Cả hai liên kết đó thực sự giải thích lý do đằng sau quyết định của họ.
Bill Gray

Lý do là tập tin sẽ có quá tải hệ thống tập tin cơ bản. Nếu bạn tạo một tập tin, nó có thể bị mất. và tùy thuộc vào tệp đang được lưu trong bộ đệm khi trao đổi, việc đọc có thể bị chậm so với toàn bộ phân vùng là hệ thống tệp hoán đổi.
Viky

Đã thử đào thêm và tìm thấy bài viết tương đối trên wiki. Chỉ để hỗ trợ bạn, có một vài thông số điều chỉnh trao đổi mà bạn có thể kiểm tra. Ngoài ra kiểm tra giải thích theo thực hiện cho linux. Có thể giúp. vi.wikipedia.org/wiki/Paging
Viky

Theo dõi một trong những trích dẫn trên liên kết wiki đã đề cập ở trên và tìm thấy một chủ đề thú vị về cùng một vấn đề. Có thể muốn kiểm tra xem. lkml.org/lkml/2005/6/28/427
Viky

Tôi đã đề cập đến tình trạng quá tải hệ thống tập tin trong câu hỏi của tôi, nhưng nó không phải là một khối hiệu suất nhiều như có một phân vùng gần đĩa bên trong. Sự chậm trễ đó sẽ lớn hơn hệ thống tập tin.
Bill Gray

2

Tôi nghĩ ở giai đoạn hiện tại, trừ khi bạn đang chạy một máy tính xách tay có cấu hình ghi dữ liệu vào trao đổi khi nó tạm dừng / ngủ, trao đổi nên thực sự được coi là "phương sách cuối cùng". Đặt cược tốt nhất của bạn là đặt đủ RAM vào một hộp để nó không bao giờ có trang vào đĩa.

Điều đó đang được nói, một phân vùng có lẽ là cách tốt hơn, hiệu suất khôn ngoan, mặc dù một tệp linh hoạt hơn. Chỉ cần đảm bảo rằng nó nằm trên trục xoay 7200+ RPM.


1
Tại sao một phân vùng sẽ có hiệu suất tốt hơn khôn ngoan, khi thời gian truy cập có thể là một yếu tố gây chậm trễ?
Bill Gray

5
Bởi vì sử dụng tệp có thể cần nhiều chuyển động đầu hơn, vì khi tìm trang để đọc / ghi dữ liệu có thể ở bất kỳ đâu trên hệ thống tệp, do đó, cấu trúc fs có thể cần được tìm kiếm trong khi với phân vùng trao đổi, mỗi trang sẽ ở một vị trí đã biết trong vách ngăn. Điều này làm cho thời gian truy cập (như được gắn với thông lượng hàng loạt) là một yếu tố khác biệt.
David Spillett

2
"Không cấu hình trao đổi trừ khi bạn cần ngủ đông" là một quan điểm gây tranh cãi. Đôi khi hệ thống trao đổi bộ nhớ thực thấp có thể cho phép hệ thống phục hồi. Không có trao đổi có thể hạn chế bạn chạy các chương trình phân bổ bộ nhớ lớn nhưng thực tế không chạm vào phần lớn (ví dụ: các công cụ gỡ lỗi nhất định). Đôi khi, một vùng bộ nhớ chiếm dụng nhưng nhàn rỗi được sử dụng tốt hơn làm bộ đệm đĩa và điều đó chỉ có thể được thực hiện nếu có trao đổi. Xem unix.stackexchange.com/questions/2658/ Khăn để thảo luận.
Anon

1
Những gì @Anon nói. Chrome là một con heo bộ nhớ khét tiếng và thậm chí với <100 tab, máy tính xách tay 16 GB của tôi không phản hồi trong vài phút khi mức sử dụng bộ nhớ khoảng 90% và không có tệp trao đổi. Đáng ngạc nhiên, Ubuntu không có cơ chế tích hợp để cảnh báo người dùng rằng HĐH sắp hết bộ nhớ .
Dan Dascalescu

2

Suy nghĩ trong công việc của chúng tôi là vì tệp Swap có thể bị phân mảnh và phân mảnh làm chậm truy cập trao đổi, phân vùng là một cách tiếp cận tốt hơn. Tất nhiên, việc xác định một tệp hoán đổi có kích thước tĩnh thực hiện nhiều điều tương tự nhưng điều này chỉ có vẻ chủ quan hơn.

Đây có phải là cách tiếp cận đúng không? Có lẽ là không, vì thực tế đã được thiết lập gần 10 năm trước. Sự thay đổi lớn duy nhất trong công nghệ ổ đĩa trong những năm qua là sự phức tạp của bộ điều khiển RAID mà chúng tôi sử dụng (chúng tôi chưa đủ giàu cho SSD). Sự gia tăng kích thước ổ đĩa có nghĩa là phân vùng trao đổi mà chúng ta tạo ra gần với khởi động của ổ đĩa hơn so với khi ổ đĩa 18 GB là tiêu chuẩn vận chuyển, do đó tốc độ trao đổi thậm chí còn nhanh hơn so với thời xưa.

Tất nhiên, trên các hệ thống Windows dựa trên ESX của chúng tôi, vị trí của tệp hoán đổi là hoàn toàn, hoàn toàn không cần thiết. Có rất nhiều lớp ảo hóa giữa tệp hoán đổi và đĩa đĩa vật lý mà nó không thành vấn đề. Nhưng chúng tôi giữ nó trên một phân vùng riêng vì đó chỉ là tiêu chuẩn.


4
Một tệp hoán đổi không bị phân mảnh, vì kernel sử dụng phương pháp mmap trực tiếp và sẽ không bao giờ phát triển hoặc thu nhỏ tệp. +1 mặc dù cho nhận xét của bạn về ảo hóa: nó thường không quan trọng.
parasietje

0

Sử dụng tệp hoán đổi có thể sử dụng thêm một chút bộ nhớ cho bản dịch từ tệp sang bộ nhớ. Chúng tôi đang nói về bộ nhớ ít hơn 1 MB cho mỗi 1 GB trao đổi. Bộ đệm hệ thống tệp KHÔNG lưu trữ dữ liệu đã hoán đổi dữ liệu, chỉ có dữ liệu tổ chức, nên là hầu hết các yêu cầu bộ nhớ bổ sung.

Bên cạnh đó tôi nghi ngờ bạn sẽ mất bất kỳ hiệu suất hợp lý nào, ngoại trừ có thể một lần trong 1000 lần tìm kiếm bổ sung duy nhất.

Thật buồn cười, sử dụng zswap cùng với tệp hoán đổi mở rộng linh hoạt dẫn đến tăng tốc ấn tượng cho các hoạt động hoán đổi với rất ít chi phí trong khi không sử dụng.


1
Bạn có thể cung cấp bất kỳ loại biện minh cho khiếu nại của bạn? Điều này có vẻ khá giai thoại.
austinian
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.