Ăn cắp: kẻ ăn cắp thời gian CPU từ máy ảo

Ăn cắp: kẻ ăn cắp thời gian CPU từ máy ảo

Xin chào! Tôi muốn nói một cách đơn giản về cơ chế xuất hiện hành vi ăn cắp bên trong các máy ảo và về một số hiện vật không rõ ràng mà chúng tôi đã tìm ra trong quá trình nghiên cứu của anh ấy, mà tôi đã phải đi sâu vào với tư cách là giám đốc kỹ thuật của nền tảng đám mây Giải pháp đám mây Mail.ru. Nền tảng chạy trên KVM.

Thời gian đánh cắp CPU là thời gian mà máy ảo không nhận được tài nguyên bộ xử lý để thực thi. Thời gian này chỉ được xem xét trong các hệ điều hành khách trong môi trường ảo hóa. Lý do những nguồn lực được phân bổ này đi đâu, cũng như trong cuộc sống, rất mơ hồ. Nhưng chúng tôi quyết định tìm ra nó, thậm chí thiết lập một số thử nghiệm. Không phải bây giờ chúng tôi biết mọi thứ về ăn cắp, nhưng chúng tôi sẽ cho bạn biết một điều thú vị ngay bây giờ.

1. Thế nào là ăn cắp

Vì vậy, ăn cắp là một số liệu cho thấy thiếu thời gian của bộ xử lý cho các quy trình bên trong một máy ảo. Như mô tả trong bản vá nhân KVM, ăn trộm là lượng thời gian mà trình ảo hóa đang thực thi các quy trình khác trên Hệ điều hành máy chủ mặc dù nó đã xếp hàng cho quy trình máy ảo để thực thi. Tức là, ăn cắp được tính là sự khác biệt giữa thời gian khi quy trình sẵn sàng chạy và thời gian khi quy trình được phân bổ thời gian CPU.

Nhân máy ảo nhận số liệu đánh cắp từ trình ảo hóa. Đồng thời, trình ảo hóa không chỉ định những quy trình khác mà nó đang thực hiện, chỉ "trong khi tôi đang bận, tôi không thể cho bạn thời gian." Trên KVM, hỗ trợ tính toán ăn cắp được thêm vào bản vá lỗi. Có hai điểm chính ở đây:

  • Máy ảo tìm hiểu về hành vi ăn cắp từ trình ảo hóa. Đó là, từ quan điểm về tổn thất, đối với các quy trình trên chính máy ảo, đây là một phép đo gián tiếp, có thể chịu nhiều biến dạng khác nhau.
  • Trình ảo hóa không chia sẻ thông tin với máy ảo về những gì nó đang làm - điều chính yếu là nó không dành thời gian cho nó. Do đó, bản thân máy ảo không thể phát hiện các biến dạng trong chỉ báo ăn cắp, vốn có thể được đánh giá theo bản chất của các quy trình cạnh tranh.

2. Điều gì ảnh hưởng đến việc ăn cắp

2.1. tính ăn cắp

Trên thực tế, việc đánh cắp được xem xét theo cách tương tự như thời gian sử dụng CPU thông thường. Không có nhiều thông tin về cách tái chế được xem xét. Có lẽ bởi vì đa số coi câu hỏi này là hiển nhiên. Nhưng ở đây cũng vậy, có những cạm bẫy. Để biết tổng quan về quá trình này, hãy đọc bài viết của Brendan Gregg: bạn sẽ tìm hiểu về một loạt các sắc thái khi tính toán thời gian sử dụng và về các tình huống khi phép tính này bị sai vì những lý do sau:

  • Quá nóng của bộ xử lý, trong đó các chu kỳ bị bỏ qua.
  • Bật/tắt tăng cường turbo, thay đổi tần số xung nhịp của bộ xử lý.
  • Sự thay đổi về độ dài của lát cắt thời gian xảy ra khi sử dụng các công nghệ tiết kiệm năng lượng của bộ xử lý như SpeedStep.
  • Tính toán vấn đề trung bình: ước tính mức sử dụng trong một phút là 80% có thể che giấu mức bùng nổ ngắn hạn là 100%.
  • Khóa quay khiến bộ xử lý được thu hồi, nhưng quy trình người dùng không thấy tiến trình thực thi. Do đó, mức sử dụng ước tính của bộ xử lý theo quy trình sẽ là XNUMX%, mặc dù quy trình sẽ không tiêu tốn thời gian của bộ xử lý về mặt vật lý.

Tôi không tìm thấy bài viết nào mô tả cách tính tương tự để ăn trộm (nếu bạn biết, hãy chia sẻ ở phần bình luận). Tuy nhiên, theo đánh giá của các nguồn, cơ chế tính toán giống như đối với tái chế. Chỉ là một bộ đếm khác được thêm vào nhân, trực tiếp cho quy trình KVM (quy trình máy ảo), đếm thời lượng của quy trình KVM trong trạng thái chờ thời gian của bộ xử lý. Bộ đếm lấy thông tin về bộ xử lý từ thông số kỹ thuật của nó và xem liệu tất cả các tích tắc của nó có được sử dụng bởi quy trình máy ảo hay không. Nếu tất cả mọi thứ, thì chúng tôi cho rằng bộ xử lý chỉ tham gia vào quá trình của máy ảo. Mặt khác, chúng tôi thông báo rằng bộ xử lý đang làm việc khác, ăn cắp xuất hiện.

Quá trình đếm số lần đánh cắp có thể gặp các vấn đề tương tự như số lần đánh cắp thông thường. Không phải nói rằng những vấn đề như vậy xuất hiện thường xuyên, nhưng chúng trông có vẻ nản lòng.

2.2. Các loại ảo hóa trên KVM

Nói chung, có ba loại ảo hóa và tất cả chúng đều được KVM hỗ trợ. Cơ chế xảy ra ăn cắp có thể phụ thuộc vào loại ảo hóa.

Phát sóng. Trong trường hợp này, hoạt động của hệ điều hành máy ảo với các thiết bị vật lý của trình ảo hóa diễn ra như sau:

  1. Hệ điều hành khách gửi lệnh đến thiết bị khách của nó.
  2. Trình điều khiển thiết bị khách nhận lệnh, tạo yêu cầu cho BIOS của thiết bị và gửi nó đến trình ảo hóa.
  3. Quá trình ảo hóa sẽ dịch một lệnh thành một lệnh cho một thiết bị vật lý, làm cho thiết bị đó, trong số những thứ khác, trở nên an toàn hơn.
  4. Trình điều khiển của thiết bị vật lý chấp nhận lệnh đã sửa đổi và gửi nó đến chính thiết bị vật lý.
  5. Kết quả của việc thực hiện các lệnh quay trở lại cùng một đường dẫn.

Ưu điểm của bản dịch là nó cho phép bạn mô phỏng bất kỳ thiết bị nào và không yêu cầu chuẩn bị đặc biệt cho nhân hệ điều hành. Nhưng bạn phải trả giá cho điều này, trước hết là tốc độ.

Ảo hóa phần cứng. Trong trường hợp này, thiết bị ở cấp độ phần cứng hiểu các lệnh từ hệ điều hành. Đây là cách nhanh nhất và tốt nhất. Nhưng thật không may, nó không được hỗ trợ bởi tất cả các thiết bị vật lý, trình ảo hóa và hệ điều hành khách. Hiện tại, các thiết bị chính hỗ trợ ảo hóa phần cứng là bộ vi xử lý.

Ảo hóa song song. Tùy chọn phổ biến nhất để ảo hóa thiết bị trên KVM và nói chung là chế độ ảo hóa phổ biến nhất cho các hệ điều hành khách. Điểm đặc biệt của nó là hoạt động với một số hệ thống con của trình ảo hóa (ví dụ: với mạng hoặc ngăn xếp đĩa) hoặc phân bổ các trang bộ nhớ xảy ra bằng cách sử dụng API của trình ảo hóa mà không cần dịch các lệnh cấp thấp. Nhược điểm của phương pháp ảo hóa này là nhân hệ điều hành khách cần được sửa đổi để nó có thể giao tiếp với trình ảo hóa bằng API này. Nhưng điều này thường được giải quyết bằng cách cài đặt trình điều khiển đặc biệt trên hệ điều hành khách. Trong KVM, API này được gọi là tài năng API.

Với ảo hóa song song, so với dịch thuật, đường dẫn đến thiết bị vật lý được giảm đáng kể bằng cách gửi lệnh trực tiếp từ máy ảo đến quy trình ảo hóa trên máy chủ. Điều này cho phép bạn tăng tốc độ thực hiện tất cả các hướng dẫn bên trong máy ảo. Trong KVM, virtio API chịu trách nhiệm cho việc này, API này chỉ hoạt động đối với một số thiết bị nhất định, chẳng hạn như bộ điều hợp mạng hoặc ổ đĩa. Đó là lý do tại sao trình điều khiển virtio được cài đặt bên trong máy ảo.

Mặt trái của việc tăng tốc này là không phải tất cả các quy trình chạy bên trong máy ảo đều ở bên trong nó. Điều này tạo ra một số hiệu ứng đặc biệt có thể khiến xuất hiện ăn trộm. Tôi khuyên bạn nên bắt đầu một nghiên cứu chi tiết về vấn đề này với Một API cho I/O ảo: virtio.

2.3. Lịch trình "công bằng"

Trên thực tế, một máy ảo trên trình ảo hóa là một quy trình thông thường tuân theo quy luật lập lịch (phân phối tài nguyên giữa các quy trình) trong nhân Linux, vì vậy chúng ta hãy xem xét kỹ hơn về nó.

Linux sử dụng cái gọi là CFS, Bộ lập lịch hoàn toàn công bằng, đã trở thành bộ lập lịch mặc định kể từ kernel 2.6.23. Để hiểu thuật toán này, bạn có thể đọc Linux Kernel Architecture hoặc nguồn. Bản chất của CFS nằm ở việc phân phối thời gian của bộ xử lý giữa các quy trình tùy thuộc vào thời lượng thực hiện của chúng. Quá trình yêu cầu thời gian CPU càng nhiều thì thời gian CPU càng ít. Điều này đảm bảo việc thực thi "công bằng" của tất cả các quy trình - để một quy trình không chiếm tất cả các bộ xử lý mọi lúc và các quy trình khác cũng có thể được thực thi.

Đôi khi mô hình này dẫn đến các đồ tạo tác thú vị. Những người dùng Linux lâu năm chắc chắn sẽ nhớ sự cố đóng băng trình soạn thảo văn bản thông thường trên máy tính để bàn trong quá trình khởi chạy các ứng dụng sử dụng nhiều tài nguyên như trình biên dịch. Điều này xảy ra do các tác vụ không sử dụng nhiều tài nguyên của ứng dụng máy tính để bàn cạnh tranh với các tác vụ tiêu tốn nhiều tài nguyên, chẳng hạn như trình biên dịch. CFS cho rằng điều này là không công bằng nên định kỳ dừng trình soạn thảo văn bản và để bộ xử lý xử lý các tác vụ của trình biên dịch. Điều này đã được khắc phục bằng cơ chế lập lịch_autogroup, nhưng vẫn còn nhiều tính năng phân bổ thời gian của bộ xử lý giữa các tác vụ. Trên thực tế, câu chuyện này không phải về mọi thứ tồi tệ như thế nào trong CFS, mà là một nỗ lực nhằm thu hút sự chú ý đến thực tế rằng việc phân phối thời gian của bộ xử lý "công bằng" không phải là nhiệm vụ tầm thường nhất.

Một điểm quan trọng khác trong lịch trình là quyền ưu tiên. Điều này là cần thiết để trục xuất quá trình cười khúc khích khỏi bộ xử lý và để những người khác làm việc. Quá trình lưu đày được gọi là context switching, một bộ xử lý context switch. Đồng thời, toàn bộ bối cảnh của tác vụ được lưu lại: trạng thái của ngăn xếp, các thanh ghi, v.v., sau đó quá trình này được chuyển sang chế độ chờ và một quá trình khác sẽ diễn ra. Đây là một thao tác tốn kém cho hệ điều hành và hiếm khi được sử dụng, nhưng thực tế không có gì sai với nó. Việc chuyển ngữ cảnh thường xuyên có thể chỉ ra sự cố trong HĐH, nhưng thông thường nó diễn ra liên tục và không biểu thị điều gì cụ thể.

Một câu chuyện dài như vậy là cần thiết để giải thích một thực tế: một quy trình cố gắng tiêu thụ càng nhiều tài nguyên bộ xử lý trong một bộ lập lịch Linux trung thực, thì nó sẽ bị dừng càng nhanh để các quy trình khác cũng có thể hoạt động. Điều này có đúng hay không là một câu hỏi khó, được giải quyết khác nhau dưới các tải trọng khác nhau. Trong Windows, cho đến gần đây, bộ lập lịch tập trung vào việc xử lý ưu tiên các ứng dụng trên máy tính để bàn, điều này có thể khiến các quá trình nền bị treo. Sun Solaris có năm loại bộ lập lịch khác nhau. Khi ảo hóa được khởi chạy, cái thứ sáu đã được thêm vào, lịch chia sẻ công bằngbởi vì năm phần trước không hoạt động đầy đủ với ảo hóa Solaris Zones. Tôi khuyên bạn nên bắt đầu nghiên cứu chi tiết về vấn đề này với những cuốn sách như Nội bộ Solaris: Kiến trúc hạt nhân Solaris 10 và OpenSolaris hoặc Hiểu về nhân Linux.

2.4. Làm thế nào để giám sát ăn cắp?

Giám sát ăn cắp bên trong một máy ảo, giống như bất kỳ chỉ số bộ xử lý nào khác, rất đơn giản: bạn có thể sử dụng bất kỳ công cụ đo lường bộ xử lý nào. Điều chính là máy ảo phải có trên Linux. Vì một số lý do, Windows không cung cấp thông tin đó cho người dùng. 🙁

Ăn cắp: kẻ ăn cắp thời gian CPU từ máy ảo
Đầu ra của lệnh trên cùng: chi tiết tải trên bộ xử lý, ở cột ngoài cùng bên phải - ăn trộm

Khó khăn phát sinh khi cố gắng lấy thông tin này từ trình ảo hóa. Ví dụ, bạn có thể cố gắng dự đoán hành vi ăn cắp trên máy chủ bằng tham số Trung bình tải (LA) - giá trị trung bình của số lượng quy trình đang chờ trong hàng đợi thực thi. Phương pháp tính toán tham số này không đơn giản, nhưng nói chung, nếu LA được chuẩn hóa bởi số lượng luồng bộ xử lý lớn hơn 1, điều này cho thấy rằng máy chủ Linux đang bị quá tải với thứ gì đó.

Tất cả những quá trình này đang chờ đợi điều gì? Câu trả lời rõ ràng là bộ vi xử lý. Nhưng câu trả lời không hoàn toàn chính xác, bởi vì đôi khi bộ xử lý rảnh rỗi và LA bị lệch tỷ lệ. Nhớ làm thế nào NFS sụp đổ và làm thế nào LA phát triển cùng một lúc. Điều tương tự cũng có thể xảy ra với đĩa và với các thiết bị đầu vào / đầu ra khác. Nhưng trên thực tế, các quy trình có thể chờ kết thúc bất kỳ khóa nào, cả vật lý, được liên kết với thiết bị I / O và logic, chẳng hạn như một mutex. Nó cũng bao gồm các khóa ở cấp độ phần cứng (cùng một phản hồi từ đĩa) hoặc logic (cái gọi là khóa nguyên thủy, bao gồm một loạt các thực thể, mutex Adaptive và spin, semaphores, biến điều kiện, khóa rw, khóa ipc . ..).

Một tính năng khác của LA là nó được coi là một giá trị trung bình cho hệ điều hành. Ví dụ: 100 quy trình cạnh tranh cho một tệp và sau đó LA=50. Có vẻ như một giá trị lớn như vậy chỉ ra rằng hệ điều hành không tốt. Nhưng đối với các mã được viết quanh co khác, đây có thể là trạng thái bình thường, mặc dù thực tế là chỉ có nó bị lỗi và các quy trình khác trong hệ điều hành không bị ảnh hưởng.

Do tính trung bình này (và không ít hơn một phút), việc xác định bất cứ điều gì về LA không phải là nhiệm vụ bổ ích nhất, với kết quả rất không chắc chắn trong các trường hợp cụ thể. Nếu bạn cố gắng tìm hiểu, bạn sẽ thấy rằng các bài viết trên Wikipedia và các tài nguyên có sẵn khác chỉ mô tả các trường hợp đơn giản nhất mà không có giải thích sâu về quy trình. Tôi gửi tất cả những người quan tâm, một lần nữa, gửi tới Brendann Gregg đây  - làm theo các liên kết. Ai lười học tiếng Anh - bản dịch bài báo nổi tiếng của anh ấy về LA.

3. Hiệu ứng đặc biệt

Bây giờ chúng ta hãy tập trung vào các trường hợp ăn cắp chính mà chúng ta đã gặp phải. Tôi sẽ cho bạn biết cách chúng tuân theo tất cả những điều trên và cách chúng tương quan với các chỉ báo trên trình ảo hóa.

Tái chế. Đơn giản nhất và phổ biến nhất: trình ảo hóa được tái chế. Thật vậy, có rất nhiều máy ảo đang chạy, mức tiêu thụ bộ xử lý bên trong chúng cao, rất nhiều sự cạnh tranh, mức sử dụng của LA lớn hơn 1 (được chuẩn hóa bởi các luồng bộ xử lý). Bên trong tất cả virtualok, mọi thứ đều chậm lại. Ăn cắp được truyền từ trình ảo hóa cũng tăng lên, cần phải phân phối lại tải hoặc tắt ai đó. Nói chung, mọi thứ đều hợp lý và dễ hiểu.

Ảo hóa song song so với các trường hợp đơn độc. Chỉ có một máy ảo trên trình ảo hóa, nó tiêu thụ một phần nhỏ của nó, nhưng cung cấp tải I / O lớn, chẳng hạn như trên đĩa. Và từ một nơi nào đó, một vụ ăn cắp nhỏ xuất hiện trong đó, lên tới 10% (như một số thí nghiệm cho thấy).

Vụ việc thật thú vị. Trộm cắp xuất hiện ở đây chỉ vì khóa ở cấp trình điều khiển ảo hóa. Một ngắt được tạo bên trong máy ảo, được trình điều khiển xử lý và chuyển đến trình ảo hóa. Do quá trình xử lý bị gián đoạn trên trình ảo hóa, điều này giống như một yêu cầu đã được gửi đến máy ảo, nó đã sẵn sàng để thực thi và đang chờ bộ xử lý, nhưng nó không được cung cấp thời gian cho bộ xử lý. Máy ảo nghĩ rằng lần này là bị đánh cắp.

Điều này xảy ra tại thời điểm bộ đệm được gửi, nó chuyển đến không gian nhân của trình ảo hóa và chúng tôi bắt đầu chờ đợi nó. Mặc dù, từ quan điểm của máy ảo, anh ta nên quay lại ngay lập tức. Do đó, theo thuật toán tính toán ăn cắp, thời gian này được coi là ăn cắp. Nhiều khả năng, có thể có các cơ chế khác trong tình huống này (ví dụ: xử lý một số lệnh gọi hệ thống khác), nhưng chúng không khác nhau nhiều.

Bộ lập lịch chống lại các máy ảo được tải cao. Khi một máy ảo bị đánh cắp nhiều hơn những máy khác, điều này chính xác là do bộ lập lịch. Quá trình tải bộ xử lý càng nhiều thì bộ lập lịch sẽ khởi động nó càng sớm để phần còn lại cũng có thể hoạt động. Nếu một máy ảo tiêu thụ một chút, thì nó sẽ khó bị đánh cắp: quá trình của nó thực sự ngồi và chờ đợi, nó sẽ có thêm thời gian. Nếu máy ảo tạo ra tải tối đa trên tất cả các lõi của nó, thì nó thường bị loại khỏi bộ xử lý hơn và họ cố gắng không cho nó nhiều thời gian.

Tệ hơn nữa, khi các quy trình bên trong máy ảo cố gắng sử dụng nhiều bộ xử lý hơn, vì chúng không thể đối phó với việc xử lý dữ liệu. Sau đó, hệ điều hành trên trình ảo hóa, do tối ưu hóa trung thực, sẽ ngày càng ít thời gian xử lý hơn. Quá trình này xảy ra giống như một trận tuyết lở và đánh cắp các cú nhảy lên bầu trời, mặc dù các máy ảo khác có thể khó nhận thấy điều đó. Và càng nhiều lõi, máy bị phân phối càng tệ. Nói tóm lại, các máy ảo được tải nhiều với nhiều lõi bị ảnh hưởng nhiều nhất.

LA thấp, nhưng có ăn cắp. Nếu LA là khoảng 0,7 (nghĩa là trình ảo hóa dường như bị quá tải), nhưng hành vi ăn cắp được quan sát thấy bên trong các máy ảo riêng lẻ:

  • Tùy chọn đã được mô tả ở trên với ảo hóa song song. Máy ảo có thể nhận các chỉ số cho thấy ăn cắp, mặc dù trình ảo hóa đang hoạt động tốt. Theo kết quả thử nghiệm của chúng tôi, tùy chọn ăn cắp này không vượt quá 10% và sẽ không có tác động đáng kể đến hiệu suất ứng dụng bên trong máy ảo.
  • Tham số LA được coi là không chính xác. Chính xác hơn, tại mỗi thời điểm cụ thể, nó được coi là đúng, nhưng khi tính trung bình trên một phút, nó lại bị đánh giá thấp. Ví dụ: nếu một máy ảo trên một phần ba của trình ảo hóa sử dụng tất cả các bộ xử lý của nó trong đúng nửa phút, thì LA mỗi phút trên trình ảo hóa sẽ là 0,15; bốn máy ảo như vậy hoạt động đồng thời sẽ cho 0,6. Và thực tế là trong nửa phút trên mỗi người trong số họ đã có một vụ ăn cắp hoang dã ở mức 25% về LA, không còn có thể rút ra được nữa.
  • Một lần nữa, do người lên lịch đã quyết định rằng ai đó đã ăn quá nhiều và để người này đợi. Trong thời gian chờ đợi, tôi sẽ chuyển đổi ngữ cảnh, xử lý các ngắt và xử lý các công việc quan trọng khác của hệ thống. Do đó, một số máy ảo không gặp bất kỳ sự cố nào, trong khi những máy ảo khác bị suy giảm hiệu suất nghiêm trọng.

4. Các biến dạng khác

Có hàng triệu lý do khác để bóp méo sự trở lại trung thực của thời gian xử lý trên một máy ảo. Ví dụ: siêu phân luồng và NUMA thêm độ phức tạp cho các phép tính. Họ hoàn toàn nhầm lẫn giữa việc lựa chọn hạt nhân để thực hiện quy trình, bởi vì bộ lập lịch sử dụng các hệ số - trọng số, khi chuyển ngữ cảnh sẽ khiến việc tính toán trở nên khó khăn hơn.

Có những biến dạng do các công nghệ như tăng áp turbo hoặc ngược lại, chế độ tiết kiệm năng lượng, khi tính toán mức sử dụng, có thể tăng hoặc giảm tần số hoặc thậm chí định lượng thời gian trên máy chủ một cách giả tạo. Kích hoạt tăng cường turbo làm giảm hiệu suất của một luồng bộ xử lý do tăng hiệu suất của một luồng khác. Tại thời điểm này, thông tin về tần số bộ xử lý hiện tại không được truyền đến máy ảo và nó tin rằng ai đó đang ăn cắp thời gian của nó (ví dụ: nó yêu cầu 2 GHz nhưng nhận được một nửa).

Nói chung, có thể có nhiều lý do cho sự biến dạng. Trên một hệ thống cụ thể, bạn có thể tìm thấy thứ khác. Tốt hơn hết là bắt đầu với những cuốn sách mà tôi đã cung cấp liên kết ở trên và đọc số liệu thống kê từ trình ảo hóa với các tiện ích như perf, sysdig, systemtap, trong số đó hàng tá.

5. Kết luận

  1. Một số lượng ăn cắp nhất định có thể xảy ra do ảo hóa song song và nó có thể được coi là bình thường. Trên Internet họ viết rằng giá trị này có thể là 5-10%. Nó phụ thuộc vào các ứng dụng bên trong máy ảo và tải mà nó cung cấp cho các thiết bị vật lý của nó. Ở đây, điều quan trọng là phải chú ý đến cảm giác của các ứng dụng bên trong các máy ảo.
  2. Tỷ lệ tải trên trình ảo hóa và đánh cắp bên trong máy ảo không phải lúc nào cũng có mối liên hệ rõ ràng với nhau, cả hai ước tính về đánh cắp có thể sai trong các tình huống cụ thể ở các mức tải khác nhau.
  3. Bộ lập lịch có thái độ không tốt đối với các quy trình yêu cầu nhiều. Anh ta cố gắng cho ít hơn cho những người yêu cầu nhiều hơn. Máy ảo lớn là ác.
  4. Một hành vi ăn cắp nhỏ có thể là tiêu chuẩn ngay cả khi không có ảo hóa song song (có tính đến tải bên trong máy ảo, đặc điểm tải của các máy lân cận, phân phối tải giữa các luồng và các yếu tố khác).
  5. Nếu bạn muốn tìm ra cách ăn cắp trên một hệ thống cụ thể, bạn phải khám phá các tùy chọn khác nhau, thu thập số liệu, phân tích chúng cẩn thận và suy nghĩ về cách phân bổ tải đồng đều. Có thể xảy ra sai lệch trong mọi trường hợp, điều này phải được xác nhận bằng thực nghiệm hoặc xem trong trình gỡ lỗi hạt nhân.

Nguồn: www.habr.com

Thêm một lời nhận xét