Tôi đã bối rối và tôi hy vọng người khác sẽ nhận ra các triệu chứng của vấn đề này.
Phần cứng: Dell T110 II mới, Pentium G850 lõi kép 2.9 GHz, bộ điều khiển SATA trên bo mạch, một ổ cứng 500 GB 7200 RPM mới bên trong hộp, các ổ khác bên trong nhưng chưa được gắn. Không có RAID. Phần mềm: máy ảo CentOS 6.5 mới trong VMware ESXi 5.5.0 (bản dựng 1746018) + vSphere Client. RAM 2,5 GB được phân bổ. Đĩa là cách CentOS cung cấp để thiết lập nó, cụ thể là một ổ đĩa trong Nhóm âm lượng LVM, ngoại trừ việc tôi bỏ qua việc có một nhà riêng / nhà và chỉ cần có / và / khởi động. CentOS được vá, ESXi được vá, các công cụ VMware mới nhất được cài đặt trong VM. Không có người dùng trên hệ thống, không có dịch vụ đang chạy, không có tệp trên đĩa nhưng cài đặt hệ điều hành. Tôi đang tương tác với VM thông qua bảng điều khiển ảo VM trong vSphere Client.
Trước khi đi xa hơn, tôi muốn kiểm tra xem tôi đã cấu hình mọi thứ ít nhiều hợp lý. Tôi đã chạy lệnh sau với quyền root trong shell trên VM:
for i in 1 2 3 4 5 6 7 8 9 10; do
dd if=/dev/zero of=/test.img bs=8k count=256k conv=fdatasync
done
Tức là chỉ cần lặp lại lệnh dd 10 lần, kết quả là in tốc độ truyền mỗi lần. Kết quả thật đáng lo ngại. Nó khởi đầu tốt:
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 20.451 s, 105 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 20.4202 s, 105 MB/s
...
nhưng sau 7-8 trong số này, nó sẽ in
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GG) copied, 82.9779 s, 25.9 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 84.0396 s, 25.6 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 103.42 s, 20.8 MB/s
Nếu tôi đợi một khoảng thời gian đáng kể, nói 30-45 phút và chạy lại, nó sẽ quay trở lại 105 MB / s và sau vài vòng (đôi khi một vài, đôi khi 10+), nó giảm xuống ~ 20- 25 MB / s một lần nữa.
Dựa trên tìm kiếm sơ bộ cho các nguyên nhân có thể, cụ thể là VMware KB 2011861 , tôi đã thay đổi bộ lập lịch i / o của Linux thành " noop" thay vì mặc định. cat /sys/block/sda/queue/schedulercho thấy nó có hiệu lực Tuy nhiên, tôi không thể thấy rằng nó đã tạo ra bất kỳ sự khác biệt nào trong hành vi này.
Vẽ độ trễ của đĩa trong giao diện của vSphere, nó cho thấy các khoảng thời gian có độ trễ đĩa cao đạt 1,2-1,5 giây trong thời gian ddbáo cáo thông lượng thấp. (Và vâng, mọi thứ trở nên không phản hồi trong khi điều đó xảy ra.)
Điều gì có thể gây ra điều này?
Tôi cảm thấy thoải mái vì đó không phải là do đĩa bị hỏng, vì tôi cũng đã cấu hình hai đĩa khác dưới dạng một ổ đĩa bổ sung trong cùng hệ thống. Lúc đầu, tôi nghĩ rằng tôi đã làm gì đó sai với âm lượng đó, nhưng sau khi nhận xét âm lượng từ / etc / fstab và khởi động lại, và thử các thử nghiệm trên / như được hiển thị ở trên, rõ ràng vấn đề là ở nơi khác. Đây có thể là một vấn đề cấu hình ESXi, nhưng tôi không có nhiều kinh nghiệm với ESXi. Có lẽ điều gì đó thật ngu ngốc, nhưng sau khi cố gắng tìm ra điều này trong nhiều giờ trong nhiều ngày, tôi không thể tìm ra vấn đề, vì vậy tôi hy vọng ai đó có thể chỉ cho tôi đi đúng hướng.
(PS: vâng, tôi biết bộ kết hợp phần cứng này sẽ không giành được bất kỳ giải thưởng tốc độ nào với tư cách là máy chủ và tôi có lý do để sử dụng phần cứng cấp thấp này và chạy một VM, nhưng tôi nghĩ đó là điểm trừ cho câu hỏi này [trừ khi nó thực sự là một vấn đề phần cứng].)
ĐỊA CHỈ # 1 : Đọc các câu trả lời khác như câu trả lời này khiến tôi thử thêm oflag=directvào dd. Tuy nhiên, nó không tạo ra sự khác biệt trong mô hình kết quả: ban đầu các con số cao hơn trong nhiều vòng, sau đó chúng giảm xuống còn 20-25 MB / s. (Các số tuyệt đối ban đầu nằm trong phạm vi 50 MB / s.)
ĐỊA CHỈ # 2 : Thêm sync ; echo 3 > /proc/sys/vm/drop_cachesvào vòng lặp hoàn toàn không tạo ra sự khác biệt.
ĐỊA CHỈ # 3 : Để loại bỏ các biến tiếp theo, bây giờ tôi chạy ddsao cho tệp mà nó tạo ra lớn hơn dung lượng RAM trên hệ thống. Lệnh mới là dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct. Số lượng thông lượng ban đầu với phiên bản lệnh này là ~ 50 MB / s. Chúng giảm xuống 20-25 MB / s khi mọi thứ đi về phía nam.
ĐỊA CHỈ # 4 : Đây là đầu ra của iostat -d -m -x 1việc chạy trong một cửa sổ đầu cuối khác trong khi hiệu suất là "tốt" và sau đó một lần nữa khi nó "xấu". (Trong khi điều này đang diễn ra, tôi đang chạy dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct.) Đầu tiên, khi mọi thứ "tốt", nó cho thấy điều này:
Khi mọi thứ trở nên "xấu", iostat -d -m -x 1hiển thị điều này:
ĐỊA CHỈ # 5 : Theo đề nghị của @ewwhite, tôi đã thử sử dụng tunedvới các cấu hình khác nhau và cũng đã thử iozone. Trong phần phụ lục này, tôi báo cáo kết quả thử nghiệm xem các tunedcấu hình khác nhau có ảnh hưởng gì đến ddhành vi được mô tả ở trên không. Tôi đã cố gắng thay đổi hồ sơ thành virtual-guest, latency-performancevà throughput-performance, giữ mọi thứ khác như cũ, khởi động lại sau mỗi thay đổi, và sau đó mỗi lần chạy dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct. Nó không ảnh hưởng đến hành vi: giống như trước đây, mọi thứ bắt đầu tốt và nhiều lần chạy lặp lại ddcho thấy hiệu suất tương tự, nhưng sau đó tại một số điểm sau 10-40 lần chạy, hiệu suất giảm một nửa. Tiếp theo, tôi đã sử dụng iozone. Những kết quả đó được mở rộng hơn, vì vậy tôi sẽ đưa chúng vào phần phụ lục số 6 dưới đây.
ĐỊA CHỈ # 6 : Theo đề nghị của @ewwhite, tôi đã cài đặt và sử dụng iozoneđể kiểm tra hiệu suất. Tôi đã chạy nó trong các tunedcấu hình khác nhau và sử dụng tham số kích thước tệp tối đa rất lớn (4G) để iozone. (VM có 2,5 GB RAM được phân bổ và máy chủ có tổng cộng 4 GB.) Các lần chạy thử này mất khá nhiều thời gian. FWIW, các tệp dữ liệu thô có sẵn tại các liên kết dưới đây. Trong mọi trường hợp, lệnh được sử dụng để sản xuất các tệp là iozone -g 4G -Rab filename.
- Hồ sơ
latency-performance:- kết quả thô: http://cl.ly/0o043W442W2r
- Bảng tính Excel (phiên bản OSX) với các ô: http://cl.ly/2M3r0U2z3b22
- Hồ sơ
enterprise-storage:- kết quả thô: http://cl.ly/333U002p2R1n
- Bảng tính Excel (phiên bản OSX) với các ô: http://cl.ly/3j0T2B1l0P46
Sau đây là tóm tắt của tôi.
Trong một số trường hợp, tôi đã khởi động lại sau lần chạy trước, trong những trường hợp khác tôi đã không làm và chỉ đơn giản là chạy iozonelại sau khi thay đổi hồ sơ tuned. Điều này dường như không tạo ra sự khác biệt rõ ràng đối với kết quả chung.
Các tunedhồ sơ khác nhau dường như không (với đôi mắt thiếu kinh nghiệm của tôi) ảnh hưởng đến hành vi rộng được báo cáo bởi iozone, mặc dù các hồ sơ đã ảnh hưởng đến một số chi tiết nhất định. Đầu tiên, không có gì đáng ngạc nhiên, một số cấu hình đã thay đổi ngưỡng mà hiệu suất bị giảm khi ghi các tệp rất lớn: vẽ sơ đồ iozonekết quả, bạn có thể thấy một vách đá tuyệt đối ở mức 0,5 GB cho cấu hình latency-performancenhưng sự sụt giảm này biểu hiện ở mức 1 GB trong hồ sơenterprise-storage. Thứ hai, mặc dù tất cả các cấu hình thể hiện sự biến đổi kỳ lạ đối với sự kết hợp của kích thước tệp nhỏ và kích thước bản ghi nhỏ, mẫu biến đổi chính xác khác nhau giữa các cấu hình. Nói cách khác, trong các ô hiển thị bên dưới, mô hình lởm chởm ở phía bên trái tồn tại cho tất cả các cấu hình nhưng vị trí của các hố và độ sâu của chúng khác nhau trong các cấu hình khác nhau. (Tuy nhiên, tôi đã không lặp lại các lần chạy của cùng một cấu hình để xem liệu mô hình biến đổi có thay đổi đáng chú ý giữa các lần chạy trong iozonecùng một cấu hình hay không, vì vậy có thể những gì có vẻ khác biệt giữa các cấu hình thực sự chỉ là biến thiên ngẫu nhiên.)
Sau đây là các sơ đồ bề mặt của các iozonethử nghiệm khác nhau cho tunedhồ sơ của latency-performance. Các mô tả của các bài kiểm tra được sao chép từ tài liệu cho iozone.
Kiểm tra đọc: Kiểm tra này đo hiệu suất của việc đọc một tệp hiện có.
Kiểm tra viết: Kiểm tra này đo lường hiệu suất của việc viết một tệp mới.
Đọc ngẫu nhiên: Thử nghiệm này đo hiệu suất của việc đọc tệp với quyền truy cập được thực hiện đến các vị trí ngẫu nhiên trong tệp.
Viết ngẫu nhiên: Thử nghiệm này đo hiệu suất ghi một tệp với các truy cập được thực hiện đến các vị trí ngẫu nhiên trong tệp.
Fread: Kiểm tra này đo hiệu suất của việc đọc tệp bằng hàm thư viện fread (). Đây là một thói quen thư viện thực hiện các hoạt động đọc đệm và bị chặn. Bộ đệm nằm trong không gian địa chỉ của người dùng. Nếu một ứng dụng được đọc ở mức chuyển kích thước rất nhỏ thì chức năng I / O được đệm và chặn của fread () có thể nâng cao hiệu suất của ứng dụng bằng cách giảm số lượng cuộc gọi hệ điều hành thực tế và tăng kích thước chuyển khi hệ điều hành các cuộc gọi được thực hiện.
Fwrite: Thử nghiệm này đo hiệu suất ghi tệp bằng hàm thư viện fwrite (). Đây là một thói quen thư viện thực hiện các hoạt động ghi đệm. Bộ đệm nằm trong không gian địa chỉ của người dùng. Nếu một ứng dụng được ghi bằng chuyển kích thước rất nhỏ thì chức năng I / O được đệm và chặn của fwrite () có thể nâng cao hiệu suất của ứng dụng bằng cách giảm số lượng cuộc gọi hệ điều hành thực tế và tăng kích thước chuyển khi hệ điều hành các cuộc gọi được thực hiện. Thử nghiệm này đang viết một tệp mới để một lần nữa chi phí siêu dữ liệu được đưa vào phép đo.
Cuối cùng, trong thời gian iozonethực hiện công việc của mình, tôi cũng đã kiểm tra các biểu đồ hiệu suất cho VM trong giao diện máy khách của vSphere 5. Tôi chuyển đổi qua lại giữa các lô thời gian thực của đĩa ảo và kho dữ liệu. Các tham số âm mưu có sẵn cho kho dữ liệu lớn hơn so với đĩa ảo và các biểu đồ hiệu suất kho dữ liệu dường như phản ánh những gì các lô đĩa và ổ đĩa ảo đang làm, vì vậy ở đây tôi chỉ gửi một ảnh chụp nhanh của biểu đồ kho dữ liệu được chụp sau khi iozonehoàn thành (trong tunedhồ sơ latency-performance). Màu sắc hơi khó đọc, nhưng điều đáng chú ý nhất là các gai dọc sắc nét khi đọcđộ trễ (ví dụ: lúc 4:25, sau đó lại hơi sau 4:30 và một lần nữa trong khoảng 4: 50-4: 55). Lưu ý: cốt truyện không thể đọc được khi được nhúng ở đây, vì vậy tôi cũng đã tải nó lên http://cl.ly/image/0w2m1z2T1z2b
Tôi phải thừa nhận, tôi không biết phải làm gì với tất cả những thứ này. Tôi đặc biệt không hiểu các hồ sơ ổ gà kỳ lạ trong khu vực hồ sơ nhỏ / kích thước tệp nhỏ của các iozoneô.
iostatvà nó cho thấy việc sử dụng ~ 90% cả trước và sau. Nhưng tôi không phải là một chuyên gia trong việc đánh giá những điều này - có lẽ sự bão hòa đang xảy ra ở đâu đó. Tôi đang cập nhật câu hỏi của mình để hiển thị iostatđầu ra trong trường hợp nó hữu ích.
