Hiệu suất Ubuntu rất tệ với thiết lập cryptsetup / lvm


1

Tôi hiện có thiết lập sau trên máy tính xách tay của mình - ổ cứng được chia thành 3 phần, phần đầu là / boot cho ubfox của tôi, phần thứ ba là cài đặt windows và một ở giữa là phân vùng được mã hóa, có lvm với 3 phân vùng - / và / nhà với btfs và / trao đổi. Trên những cái tôi đã cài đặt Ubuntu 10.10.

Tôi thực hiện mã hóa với cryptsetup / luks.

Thật không may, tôi có một hiệu suất rất kém trong thiết lập này - khởi động mất gần 3 phút và sau khi hệ thống khởi động "nóng lên" thành hiệu suất bình thường trong một / hai phút. Tôi nghi ngờ rằng đĩa i / o là một vấn đề, vì những thứ như apt-get đôi khi rất chậm đối với các hoạt động chuyên sâu ("đọc cơ sở dữ liệu"). Tôi tự hỏi tại sao hiệu suất i / o của tôi có thể chậm. Tôi có 3 ý tưởng - hoặc lvm hoạt động xấu trên phân vùng được mã hóa luks hoặc btrfs hoạt động kém vì một số lý do hoặc cài đặt Ubuntu vì lý do nào đó bị vặn (tôi nghi ngờ).

Tôi tự hỏi nếu bất kỳ đề xuất nào trong số đó là có thể và nếu không những gì khác có thể ảnh hưởng mạnh mẽ đến hiệu suất.

PS: Trước khi hiệu suất cài đặt này ổn với thiết lập luks-on-lvm (phân vùng 3 lvm được mã hóa bởi luks) và cài đặt ext4 fs, vì vậy đây là cài đặt này, không phải máy tính xách tay.

PPS: Mã hóa là 512 bit aes-xts-plain.


1
Bạn đang sử dụng phần cứng nào và bạn đã chọn tùy chọn mã hóa nào? Bản cài đặt 10.10 của tôi trên netbook sử dụng luks và ext4 khởi động ở tốc độ bình thường để có thể liên quan đến các lựa chọn phần cứng hoặc mã hóa của bạn.
Cry Havok

Phần cứng không nên liên quan, vì tôi đã thiết lập khác nhau trên cùng một phần cứng và nó hoạt động tốt.
freiksenet

Đó là giả định của bạn, nhưng nó có thể không hợp lệ do đó tôi hỏi. Hãy nhớ rằng mã hóa / giải mã thêm một chi phí để nó chạy tốt không được mã hóa có nghĩa là không có gì.
Cry Havok

Nó chạy mã hóa tốt, nhưng với thiết lập khác nhau - đó là lvm, phân vùng được mã hóa, không phải phân vùng được mã hóa trên lvm. Bài viết đề cập rằng.
freiksenet

Có thể chỉ bởi fluke là một bản cài đặt xấu hoặc cấu hình khác có trên phần xấu / chậm của ổ đĩa.
wag2639

Câu trả lời:


2

Xin chào, tôi nghĩ rằng bạn đã chọn một mã hóa quá mạnh, gây ra vấn đề về hiệu suất. 512 bit là một chút quá mức cần thiết, 256 sẽ rất khó khăn, vì nó vẫn an toàn và có lẽ sẽ còn rất nhiều năm nữa.


Ok, nghe có vẻ hợp lý. Tôi không nghĩ rằng mã hóa có thể làm giảm đáng kể hiệu suất. Tôi sẽ cố gắng mã hóa lại mọi thứ với tốc độ bit thấp hơn.
freiksenet

Nếu lược đồ mã hóa được chọn (hoặc thiết lập phân vùng của bạn) xảy ra xếp hàng kém với hình dạng ổ đĩa gốc, bạn có thể thấy hiệu suất (đặc biệt đối với mận IO ngẫu nhiên nhỏ như apt) khi đĩa đọc 2 khối trước đó (trong một căn chỉnh chính xác thiết lập) nó chỉ đọc một.
Paul McMillan

0

Tôi đoán vấn đề là btrfs trên LVM. Tôi đã có trải nghiệm kém với sự kết hợp đó (độ trễ chủ yếu là tồi tệ hơn nhiều cho các yêu cầu I / O riêng lẻ so với dự kiến). Hiệu suất tổng thể có thể ổn vì vậy nó thực sự phụ thuộc vào khối lượng công việc của bạn. Nếu bạn cần độ trễ thấp cho mỗi yêu cầu, tôi khuyên bạn nên sử dụng EXT4 trên LVM hoặc btrfs trên thiết bị thô.


Vấn đề cũng có thể liên quan đến thực tế là OP đã hỏi câu hỏi này vào năm 2010, trước khi AES-NI là phổ biến.
duskwuff

@duskwuff đúng là câu hỏi khá cũ. Tuy nhiên, tôi đã sử dụng LUKS trong khoảng thời gian tương tự mà tôi nói rằng so với hiệu suất của ổ cứng quay, LUKS đã / đủ nhanh rồi.
Mikko Rantalainen
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.