Sau 30 phút thời gian hoạt động bằng Ubuntu 14.04 với ổ SSD lai, tôi thấy nhiều quy trình chặn IO sử dụng iotop. Đây là trong quá trình ghi đĩa, ví dụ nếu tôi mở và đóng một tệp trống trong gedit, có thể mất 2 giây để đóng do cài đặt ghi dcs, điều này ảnh hưởng đến các ứng dụng khác theo cách tương tự; làm chậm toàn bộ hệ thống xuống khá nghiêm trọng.
Sử dụng strace tôi đã quản lý để theo dõi điều này trở lại cuộc gọi fsync và từ đó quản lý để tái tạo nó bằng lệnh đồng bộ hóa.
Vì vậy, để tóm tắt lại, chỉ cần chạy syncliên tục từ thiết bị đầu cuối có thể mất theo thứ tự 1 - 2 giây nhưng CHỈ sau 30 phút thời gian hoạt động.
Để chứng minh điều này, tôi đã tạo một tập lệnh tạo ra thời gian hoạt động tính bằng giây so với thời gian thực hiện để đồng bộ hóa và chạy nó mỗi giây:
while true;
do
cat /proc/uptime | awk '{printf "%f ",$1}'; /usr/bin/time -f '%e' sync;
sleep 1;
done;Tôi đã chạy đoạn script trên, đợi khoảng một giờ (hệ thống không hoạt động) và sau đó vẽ kết quả trong gnuplot (y = thời gian tính bằng giây để thực hiện đồng bộ hóa, x = thời gian hoạt động tính bằng giây):
Thời điểm mà đồ thị tăng đột biến vào khoảng 1780 (1780/60 = khoảng 30 phút).
Không có gì nên ghi vào đĩa tại thời điểm này ngoài tập lệnh, do đó, không có gì bên trong bộ đệm trang sau khi đồng bộ hóa đầu tiên, mỗi lần đồng bộ hóa tiếp theo sẽ ghi chính xác những gì được ghi vào tập lệnh sẽ có khoảng 100 byte hoặc vì thế.
Vấn đề này vẫn tồn tại sau khi khởi động lại; ví dụ: nếu tôi đợi 30 phút cho quá trình chậm lại thì khởi động lại, sự chậm lại vẫn sẽ ở đó. Nếu tôi tắt nguồn thì khởi động lại vấn đề sẽ biến mất cho đến 30 phút sau.
Một sự tò mò khác là khi tôi kiểm tra biểu đồ trên và phóng to một khu vực xảy ra sự chậm lại, tôi đã nhận được điều này:
Các đỉnh và đáy lặp lại - điều này xảy ra gần như chính xác cứ sau 10 giây từ máng đến máng và cũng là các kẽ đỉnh khi nó rơi xuống.
Tôi cũng đã chạy thử nghiệm hdparm ( hdparm -t /dev/sdavà hdparm -T /dev/sda) trước khi chậm lại:
/dev/sda:
Timing cached reads: 23778 MB in 2.00 seconds = 11900.64 MB/sec
/dev/sda:
Timing buffered disk reads: 318 MB in 3.01 seconds = 105.63 MB/sec
và trong thời gian chậm lại:
/dev/sda:
Timing cached reads: 2 MB in 2.24 seconds = 915.50 kB/sec
/dev/sda:
Timing buffered disk reads: 300 MB in 3.01 seconds = 99.54 MB/sec
Hiển thị rằng các lần đọc đĩa thực tế không bị ảnh hưởng nhưng các lần đọc được lưu trong bộ nhớ cache, điều đó có nghĩa là điều này có liên quan đến bus hệ thống chứ không phải HD?
Đây là những giải pháp tôi đã thử:
Thay đổi cài đặt spindown của HD, có thể HD sẽ chuyển sang chế độ tiết kiệm năng lượng:
hdparm /dev/sda -S252 #(set it to 5 hours before spindown)Thay đổi loại nhật ký của hệ thống tập tin thành văn bản thay vì ra lệnh để chúng tôi có được cải tiến hiệu suất - điều này không giải quyết được vấn đề mặc dù nó không giải thích được thời gian hoạt động chậm 30 phút.
CRON bị vô hiệu hóa vì dường như xảy ra sau 30 phút.
Việc sử dụng CPU vẫn ổn và hoàn toàn không hoạt động nên không có quy trình nào có thể bị đổ lỗi tuy nhiên tôi đã thử tắt mọi dịch vụ kể cả trình quản lý phiên (lightdm), điều này không có gì vì tôi tin rằng vấn đề ở mức thấp hơn.
Phân tích bất kỳ quy trình mới nào diễn ra sau 30 phút cho thấy không có thay đổi - Tôi đã làm giảm sản lượng của PS trước và sau và không có sự khác biệt.
Điều này chỉ bắt đầu xảy ra khoảng 2 tuần trước, không có gì được cài đặt và không có bản cập nhật nào được thực hiện trong khoảng thời gian đó. Tôi nghĩ vấn đề này ở mức độ thấp hơn nhiều nên thực sự sẽ đánh giá cao một số trợ giúp ở đây vì tôi không biết gì, thậm chí chỉ cho tôi đi đúng hướng sẽ hữu ích - ví dụ có cách nào để kiểm tra xem cái gì bị xóa khỏi bộ đệm trang?
Ghi bộ nhớ đệm được bật trên đĩa đang đề cập, tôi cũng đã thử vô hiệu hóa các rào cản ghi. Dữ liệu SMART trên HD cho thấy không có vấn đề gì với bản thân HD tuy nhiên tôi có nghi ngờ rằng đó là HD làm điều gì đó bí ẩn khi nó vẫn tồn tại sau khi khởi động lại.
BIÊN TẬP:
Tôi đã thực hiện :
watch -n 1 cat /proc/meminfo
... Để xem bộ nhớ thay đổi như thế nào, đặc biệt là nhìn vào hàng bẩn và hàng ghi lại mà tôi tin là bộ đệm đĩa HD. Tất cả đều ở mức 0 cho phần lớn nhất có lẽ là 300kb. Đồng bộ hóa cuộc gọi sẽ loại bỏ những điều này như mong đợi trở về 0 nhưng trong quá trình đồng bộ hóa cuộc gọi chậm lại khi không có trang bẩn và zero kb trong bộ đệm đĩa vẫn khóa IO. Những gì khác có thể đồng bộ hóa đang làm nếu không có gì để xóa bộ đệm trang và ghi bộ đệm?
sudo smartctl --smart=off /dev/sdakhiến vấn đề không còn nữa. Điều thú vị là tôi đã bật lại dữ liệu SMART và vấn đề không còn tồn tại nên tôi chỉ có thể đoán rằng dữ liệu SMART ở trạng thái không nhất quán và tắt và bật lại. Nếu bạn thêm nó dưới dạng câu trả lời tôi sẽ chấp nhận câu trả lời của bạn. Cảm ơn sự giúp đỡ rất nhiều đánh giá cao.