Tại sao I / O đĩa cao làm giảm khả năng phản hồi / hiệu năng của hệ thống?


19

Tôi chưa bao giờ hiểu tại sao I / O đĩa cao làm chậm hệ thống rất nhiều. Nó lạ đối với tôi bởi vì tôi hy vọng việc chậm lại chỉ ảnh hưởng đến các quá trình phụ thuộc vào dữ liệu ổ đĩa cứng / quang, nhưng việc chậm lại ảnh hưởng đến cả những thứ được tải vào RAM. Tôi ở đây đề cập đến iowait .

Tại sao bộ xử lý chờ, thay vì làm công việc khác? Bất cứ ai cũng có thể giải thích giới hạn này và tại sao nó chưa được giải quyết trong nhân Linux? Có một hạt nhân ngoài kia không có vấn đề này?

[ lưu ý ] Đã có một số tiến bộ trong lĩnh vực hiệu suất này. Đối với một, các hạt nhân sau này (2.6.37 trong trường hợp của tôi) phản ứng nhanh hơn nhiều.


Không xeno giải thích chính xác làm thế nào điều này đã được giải quyết trong nhân Linux lần cuối bạn hỏi?
Michael Mrozek

2
Đưa ra các chỉnh sửa, tôi nghĩ rằng mục đích của câu hỏi trước là về tiến trình đang được thực hiện để khắc phục vấn đề trong khi câu hỏi này là về lý do tại sao vấn đề tồn tại.
Steven D

@mic Steven nói đúng. Chúng tôi đã có một cuộc thảo luận dài về ý nghĩa của câu hỏi trước đó. Câu trả lời của xeno tốt đến nỗi tôi đã chỉnh sửa câu hỏi cho phù hợp với nó, và tôi đã hỏi lại câu hỏi ban đầu ở đây.
tshepang

Tôi hiểu, nhưng câu hỏi của bạn dường như mâu thuẫn với người khác; Ở đây bạn nói "Có ai có thể giải thích giới hạn này không và tại sao nó không được giải quyết trong nhân Linux? Có một hạt nhân ngoài kia không có vấn đề này không?", nhưng câu trả lời của xeno bắt đầu bằng "Tôi nghĩ phần lớn nó đã được giải quyết."
Michael Mrozek

@mic Không hẳn. Hạt nhân vẫn làm iowait , có nghĩa là nó vẫn chờ. Tôi xem câu trả lời của xeno vì khả năng đáp ứng của hệ thống đã được cải thiện . Và tôi đồng ý, như tôi đã lưu ý về câu hỏi.
tshepang

Câu trả lời:


9

Các hệ điều hành sử dụng bộ nhớ ảo để có thể sử dụng nhiều bộ nhớ hơn so với RAM vật lý có sẵn. Khi kernel quyết định rằng nó có cách sử dụng tốt hơn cho trang bộ nhớ vật lý, nội dung của nó có thể được "phân trang" để lưu trữ trên đĩa. Khi một trang bộ nhớ ảo như vậy được truy cập trong khi phân trang, nó sẽ tạo ra lỗi trang và được chuyển trở lại từ đĩa vào RAM.

Lỗi trang là một thảm họa cho hiệu suất vì độ trễ của đĩa được đo bằng mili giây, trong khi độ trễ RAM được đo bằng nano giây. (1 mili giây = một triệu nano giây!)

Bộ nhớ không chỉ được sử dụng bởi các tiến trình của người dùng, mà còn bởi kernel cho những thứ như bộ nhớ đệm hệ thống tập tin. Trong quá trình hoạt động của hệ thống tệp, kernel sẽ lưu trữ dữ liệu được sử dụng gần đây. Giả định là có khả năng cùng một dữ liệu sẽ được sử dụng lại trong thời gian ngắn, do đó, bộ nhớ đệm sẽ cải thiện hiệu năng I / O.

Bộ nhớ vật lý đang được sử dụng cho bộ đệm hệ thống tệp không thể được sử dụng cho các quy trình, do đó, trong quá trình hoạt động của hệ thống tệp, bộ nhớ quá trình sẽ được loại bỏ và lỗi trang sẽ tăng lên. Ngoài ra, băng thông I / O đĩa ít hơn có sẵn để di chuyển các trang bộ nhớ từ và sang đĩa. Kết quả là quá trình có thể bị đình trệ.


Tôi biết điều này cũng cũ như bụi bẩn, nhưng tùy thuộc vào cách thức hoạt động, số lượng I / O cao có thể dẫn đến rất nhiều gián đoạn được tạo ra và bối cảnh chuyển đổi gây lãng phí thời gian của CPU.
Bratchley 20/03/2015

5

Theo tôi hiểu, IOwait có nghĩa là một quá trình, không phải bộ xử lý, đang chờ IO sẵn sàng. Bộ xử lý đã đạt được tốc độ nhanh hơn nhiều so với ổ đĩa cứng, có nghĩa là nhiều mã sẽ hoàn thành nhanh hơn và sau đó đĩa sẽ cần phải được đọc. Khi nhiều nhu cầu được đọc hơn ổ đĩa có thể làm đủ nhanh, bạn sẽ phải chờ bộ xử lý. Cách quyết định ai sẽ đọc / ghi vào đĩa được xác định bởi bộ lập lịch khối, trong hầu hết các trường hợp bây giờ là CFQ. Nếu bạn đang sử dụng CFQ và bạn cần một quy trình sử dụng ít thời gian IO tổng thể để tăng khả năng phản hồi của hệ thống, bạn có thể sử dụng ionice -c3 <processid>. Điều này nói với hệ thống chỉ cung cấp cho quá trình này IO chỉ khi không có gì khác cần nó.

Điều này vẫn còn thú vị và giải thích vấn đề iowait tốt hơn.

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.