Làm thế nào để tôi tìm ra những gì đóng băng máy của tôi?

Tôi đang chạy Arch trên máy này:

Iac hexacore 3,40GHz (4930K)

RAM 16 GB DDR3 1600 MHz

2xSamsung 840 SSD EVO trong Raid0 (sử dụng đột kích BTRFS)

Khi tôi chạy VMware trên Arch của tôi với một vài VM (2 hoặc 3), cung cấp cho chúng khoảng 2-4 lõi mỗi lõi và RAM 2GB mỗi cái, hệ thống của tôi bắt đầu bị đóng băng ngẫu nhiên. Cứ sau vài phút, hệ thống sẽ đóng băng trong khoảng từ 10 đến 30 giây và sau đó bắt đầu di chuyển trở lại, chỉ để đóng băng 30 giây sau đó cho đến khi tôi tắt máy ảo. Khi hệ thống đóng băng, chuột vẫn di chuyển tốt, nhưng các ứng dụng ngừng phản hồi trên máy chủ - vmware không phản hồi, firefox (cũng mở trên máy chủ) không phản hồi, v.v.

Khi đóng băng xảy ra, nếu tôi có trình giám sát quá trình đang chạy, nó sẽ hiển thị một số lõi được vmware tối đa hóa, nhưng đồng thời, có các lõi khác không được sử dụng. Tôi cũng có quá nhiều RAM - máy ảo sử dụng tổng cộng 6GB và máy chủ còn lại 10GB. Tôi có 0 không gian hoán đổi, vì vậy không có cách nào hoán đổi làm chậm mọi thứ.

Có báo cáo rằng vì btrfs gây ra sự phân mảnh các tệp ở cấp độ hệ thống tệp, máy ảo có thể chạy chậm. Tuy nhiên, theo như tôi có thể nói, sự phân mảnh chỉ là một vấn đề trên các đĩa cứng truyền thống - SSD không có đầu đọc mà tìm kiếm, vì vậy họ không quan tâm nếu một tệp bị phân mảnh cao.

Điều này chưa từng xảy ra khi tôi chạy Debian 7, vì vậy tôi khá chắc chắn rằng đó không phải là vấn đề về phần cứng.

Những công cụ nào tôi có thể chạy để tìm ra lý do tại sao hệ thống của tôi tiếp tục đóng băng? Tôi đã thử top / htop và iotop (không có gì là viết hoặc đọc quá mức khi hệ thống đóng băng). Dường như không có bất kỳ loại màn hình hoạt động nào cho btrfs để biết liệu nó có vấn đề gì không theo kịp việc viết / đọc bất cứ thứ gì. Có bất cứ điều gì khác tôi có thể thử?

Từ trang btrfs gotchas :

Các tệp có nhiều lần ghi ngẫu nhiên có thể bị phân mảnh rất nhiều (hơn 10000 phạm vi) gây ra sự cố trên ổ cứng và tốc độ tải CPU quá nhiều giây trên các hệ thống có ổ SSD hoặc RAM lớn.

• Trên các máy chủ và máy trạm, điều này ảnh hưởng đến cơ sở dữ liệu và hình ảnh máy ảo.

  • Tùy chọn gắn kết gật đầu có thể được sử dụng ở đây, với các vấn đề liên quan.

  ...

• Các triệu chứng bao gồm btrfs-transacti và btrfs-endio-wri chiếm rất nhiều thời gian của CPU (trong các đột biến, có thể được kích hoạt bởi các đồng bộ hóa). Bạn có thể sử dụng filefrag để xác định vị trí các tệp bị phân mảnh nhiều (có thể không hoạt động chính xác với nén).

Tôi gặp vấn đề tương tự như bạn mô tả với Virtualbox. Các nodatacowlựa chọn cho btrfs không giúp một cách đáng chú ý trên hệ thống của tôi. Tôi cũng đã thử tùy chọn chống phân mảnh tự động (được đề cập như một giải pháp khả thi cho cơ sở dữ liệu ứng dụng trong môi trường máy tính để bàn), nhưng cũng không có kết quả sẽ khiến hành vi được chấp nhận.

Cuối cùng, tôi đã thu hẹp phần btrfs của mình và Khối lượng logic mà nó tồn tại, tôi đã tạo một LV mới và định dạng nó là ext4, sau đó đặt các hình ảnh đĩa VM mà tôi có (VirtualBox) vào "phân vùng" đó.

Nó có thể là một vấn đề trong suốt, trong đó một chuỗi nhân bị khóa , theo nghĩa đen là khai thác RAM của bạn để chống phân mảnh hoặc tạo ra các vòng đệm trong số 4k.

Kernel có thể đã quyết định kích hoạt các ôm sát với lượng RAM hệ thống khá lớn của bạn.

Kiểm tra nội dung của hai điều chỉnh nhân này:

/sys/kernel/mm/transparent_hugepage/enabled
/sys/kernel/mm/transparent_hugepage/defrag

Nếu nội dung của chúng là always, bạn có thể thay đổi nevervà xem liệu cpu tăng đột biến / đóng băng.

Vấn đề đã được giải quyết hoàn toàn bằng cách không sử dụng LUKS trên phân vùng. Vì vậy, tôi định dạng phân vùng trực tiếp bằng BTRFS chứ không phải với LUKS trước.

Cũng được gắn với các tham số sau:

/dev/sda2 /           btrfs       rw,noatime,space_cache,compress=lzo,ssd,discard,autodefrag,commit=0,thread_pool=8 0 0

Liên quan đến hiệu suất ghi dm-crypt (LUKS) của Abysmal