Hệ thống tập tin Linux tốt nhất cho MySQL (InnoDB) là gì?


48

Tôi đã cố gắng tìm kiếm điểm chuẩn về hiệu suất của các hệ thống tệp khác nhau với MySQL InnoDB nhưng không thể tìm thấy.

Khối lượng công việc cơ sở dữ liệu của tôi là OLTP dựa trên web điển hình, khoảng 90% đọc, 10% viết. IO ngẫu nhiên.

Trong số các hệ thống tập tin phổ biến như ext3, ext4, xfs, jfs, Reiserfs, Reiser4, v.v ... bạn nghĩ cái nào là tốt nhất cho MySQL?

Câu trả lời:


44

Bạn định giá dữ liệu bao nhiêu?

Nghiêm túc mà nói, mỗi hệ thống tập tin có sự đánh đổi riêng của nó. Trước khi tôi đi xa hơn, tôi là một fan hâm mộ lớn của cả XFS và Reiser, mặc dù tôi thường chạy Ext3. Vì vậy, không có sự thiên vị hệ thống tập tin thực sự tại nơi làm việc ở đây, chỉ cho bạn biết ...

Nếu hệ thống tập tin ít hơn một container cho bạn, thì hãy đi với bất cứ điều gì cung cấp cho bạn thời gian truy cập tốt nhất.

Nếu dữ liệu có giá trị đáng kể, bạn sẽ muốn tránh XFS. Tại sao? Bởi vì nếu nó không thể khôi phục một phần của tệp được ghi nhật ký, nó sẽ loại bỏ các khối và làm cho dữ liệu không thể phục hồi được. Sự cố này được khắc phục trong Linux Kernel 2.6.22 .

ReiserFS là một hệ thống tập tin tuyệt vời, với điều kiện là nó không bao giờ gặp sự cố . Khôi phục nhật ký hoạt động tốt, nhưng vì lý do nào đó bạn làm mất thông tin phân vùng của mình hoặc các khối cốt lõi của hệ thống tệp bị thổi bay, bạn có thể gặp khó khăn nếu có nhiều phân vùng ReiserFS trên đĩa - vì về cơ bản cơ chế khôi phục sẽ quét toàn bộ đĩa, từng khu vực, tìm kiếm những gì nó "nghĩ" là sự khởi đầu của hệ thống tập tin . Nếu bạn có ba phân vùng với ReiserFS nhưng chỉ có một phân vùng bị thổi, bạn có thể tưởng tượng sự hỗn loạn này sẽ gây ra khi quá trình khôi phục kết hợp một mớ hỗn độn Frankenstein từ hai hệ thống khác ...

Ext3 là "chậm", trong một "Tôi có 32.000 tệp và phải mất thời gian để tìm thấy tất cả chúng đang chạy ls". Nếu bạn sẽ có hàng ngàn bàn nhỏ tạm thời ở khắp mọi nơi, bạn sẽ có một chút đau buồn. Các phiên bản mới hơn hiện nay bao gồm một tùy chọn chỉ mục giúp giảm đáng kể việc duyệt qua thư mục nhưng nó vẫn có thể gây đau đớn.

Tôi chưa bao giờ sử dụng JFS. Tôi chỉ có thể nhận xét rằng mọi đánh giá về nó tôi từng đọc là một cái gì đó dọc theo dòng chữ "rắn, nhưng không phải là đứa trẻ nhanh nhất trong khối". Nó có thể đáng để điều tra.

Đủ các nhược điểm, chúng ta hãy nhìn vào Ưu điểm:

XFS:

  • hét lên với các tập tin khổng lồ, thời gian phục hồi nhanh
  • tìm kiếm thư mục rất nhanh
  • Nguyên thủy để đóng băng và giải phóng hệ thống tập tin để bán phá giá

ReiserFS:

  • Truy cập tệp nhỏ tối ưu cao
  • Gói một số tệp nhỏ vào cùng một khối, bảo tồn không gian hệ thống tệp
  • phục hồi nhanh, đối thủ lần XFS phục hồi

Ext3:

  • Đã thử và đúng, dựa trên mã Ext2 được kiểm tra tốt
  • Rất nhiều công cụ xung quanh để làm việc với nó
  • Có thể được gắn lại dưới dạng Ext2 trong một nhúm để phục hồi
  • Có thể được thu hẹp và mở rộng (các hệ thống tập tin khác chỉ có thể được mở rộng)
  • Các phiên bản mới nhất có thể được mở rộng "trực tiếp" (nếu bạn táo bạo)

Vì vậy, bạn thấy, mỗi người có quirks riêng của mình. Câu hỏi là, đó là ít kỳ quặc nhất đối với bạn?


29
Sự cố tệp XFS NULLed đã được khắc phục hơn 3 năm trước. xfs.org/index.php/ Kẻ
Ryan Bair

5
Mặc dù đúng là tôi không có thời gian trên thế giới để theo kịp các thay đổi phát triển hạt nhân (trên hết công việc và gia đình), nhưng chắc chắn cũng có những triển khai cũ kỹ khó hiểu cần được cập nhật. Tuy nhiên, tôi sẽ gắn chip +1 để chỉ ra cách khắc phục.
Avery Payne

13

Cũng có thể đáng lưu ý rằng bạn có thể chạy InnoDB mà không cần hệ thống tệp và cải thiện hiệu suất mà không cần hệ thống tệp. Tôi không chắc chắn tôi muốn giới thiệu nó, nhưng tôi đã sử dụng nó trước đây mà không gặp vấn đề gì.

Thiết bị thô InnoDB

Ngoài ra, nếu bạn đang chạy ở 90% đọc và 10% viết, trừ khi bạn cần khả năng giao dịch của InnoDB, bạn có thể xem xét chuyển sang MyISAM để có hiệu suất đọc tốt hơn.


6
-1 để đề xuất chuyển sang MyISAM để có hiệu suất đọc tốt hơn. Có rất nhiều sai sót và nhược điểm khác. Thay vào đó, InnoDB nên được cấu hình đúng. +1 cho đề xuất InnoDB trên thiết bị thô.
gertvdijk

5
Tôi đứng trước tuyên bố của mình, MyISAM có những hạn chế nhưng có rất nhiều điều tốt để có. MyISAM vẫn là ông chủ cho khối lượng công việc đọc.
Xorlev

11

Các câu trả lời ở đây không được chấp nhận nghiêm túc và cần cập nhật vì điều này sẽ xuất hiện trong kết quả của google.

Đối với môi trường produciton, XFS. Mỗi lần. XFS được ghi nhật ký và không chặn. Đảm bảo bạn có các biến sau cho cơ sở dữ liệu MySQL hiện đại (2011/2012) bằng InnoDB trong sản xuất:

innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 1 # an ACID requirement
sync_binlog = 1 # more ACID
innodb_flush_method = O_DIRECT

Không sử dụng EXT3 hoặc thậm chí EXT4. Một ngày BTRFS sẽ đến đó.

EXT3, và có lẽ EXT4, khóa ở mức inode, không thông minh!

Nguồn: - www.mysqlperformanceblog.com - http://dev.mysql.com/doc/i INTERNals / en / index.html - Tìm hiểu về Nội bộ MySQL của Sasha Pachev - https://www.facebook.com/note.php? note_id = 10150210901610933 - http://oss.sgi.com/projects/xfs/training/ - Một số bộ dụng cụ swing, dùng thử và lỗi.

EDIT: Một bản cập nhật. EXT4 dường như đang hoạt động khá tốt vào giữa năm 2013! BTRFS vẫn không phải là một lựa chọn tốt. Và RHEL cũng có thể biến XFS thành hệ thống tệp mặc định mới. Một lần nữa, KHÔNG sử dụng EXT3.


Theo thử nghiệm của Vadim Tkachenko , EXT4 cung cấp 20% thông lượng qua XFS nếu sử dụng MySQL 5.5 với InnoDB. Vadim đề nghị sử dụng tùy chọn EXT4 'dioread_nolock' nếu có (mặc dù anh ta không sử dụng nó với thử nghiệm).
caligari

Tại sao khóa ở mức inode xấu?
jpaugh

các câu trả lời khác đã lỗi thời ngay bây giờ ,: 5 năm sau bạn
kaiser

Google "tranh chấp khóa inode" cho các vấn đề với khóa inode.
stark

9

Phiên bản ngắn nhất là khuyến nghị gần nhất mà tôi thấy MySQL đưa ra trên các hệ thống tập tin là XFS, tuy nhiên ext3 cũng ổn, ext4 hứa hẹn sẽ là một cải tiến tốt, nhưng nó vẫn chưa hoàn toàn ổn định, mặc dù nó phải trước cuối năm

Nếu bạn đang chạy các hệ thống tập tin cụm CXFS, OCFS2 và GFS đều ổn.

Tôi mạnh mẽ cảnh báo chống lại bất kỳ dẫn xuất Reiser nào và JFS mặc dù một khi tốt đẹp đã bị XFS và ext4 đánh bại, cả hai đều được triển khai rộng rãi hơn.


6

Nó không có khả năng tạo ra nhiều sự khác biệt. Đi với bất cứ điều gì phân phối của bạn sử dụng làm mặc định của nó, miễn là nó đủ.

Dành nỗ lực của bạn để điều chỉnh những thứ khác - nhận đủ ram - nhận bộ điều khiển đột kích không hút - và sửa lỗi sử dụng cơ sở dữ liệu (ứng dụng) khập khiễng của ứng dụng (NB: đây là thủ phạm chính trong hầu hết các trường hợp chưa có đã được thực hiện).

Tuy nhiên, hãy xem xét một cách cẩn thận, hệ thống tập tin mà bạn đặt mysmp tmpdir của bạn; điều này sẽ ảnh hưởng đến hiệu suất, đặc biệt là các truy vấn thực hiện các tập tin dựa trên đĩa (xem EXPLAIN để biết thêm chi tiết).

Tôi nghĩ rằng một hệ thống tệp hỗ trợ phân bổ chậm thực sự tiện dụng ở đây, vì bạn có thể tránh IO hoàn toàn cho các tệp có thời gian sử dụng ngắn khi có đủ ram để giữ chúng trong bộ đệm. XFS, chẳng hạn, không bận tâm đến việc ghi các tập tin bị xóa và đóng trước khi chúng được phân bổ.

Tất nhiên, việc đặt một tmpdir trên một tmpfs là hấp dẫn từ góc độ hiệu suất, nhưng dẫn đến nguy cơ làm cạn kiệt dung lượng và có các truy vấn sẽ thành công (mặc dù sử dụng các tệp tạm thời của đĩa).


5

Tôi không tìm thấy bất kỳ bài viết nào gần đây với "vòng" chuẩn trên MySQL chạy trên các hệ thống tệp khác nhau. Với khối lượng công việc bạn mô tả, tôi nghi ngờ rằng sự phân mảnh ở cấp độ tệp sẽ là một vấn đề. Nếu không có điểm chuẩn chính thức, tôi không thể nói bất cứ điều gì bạn nên coi là có thẩm quyền, nhưng ruột của tôi nói rằng mọi hệ thống tập tin bạn đề cập ở trên sẽ thực hiện gần như trong cùng một sân bóng (tức là tất cả theo thứ tự độ lớn cho số hiệu suất) .

Cơ sở dữ liệu đang thực sự chạy chương trình, vì hệ thống tập tin chỉ quản lý các phạm vi lớn mà công cụ lưu trữ đang truy cập.

Tuy nhiên, sẽ rất thú vị khi thực hiện một vòng hiệu năng với tất cả các hệ thống tệp đó. (Tuy nhiên, tôi không có chút nhiệt tình nào với MySQL, vì vậy tôi sẽ không thực hiện nó. Các tiêu chuẩn Postgres, OTOH, có thể rất thú vị ...)


1
Bạn cũng là một stackoverflow.com/questions/1021854/, trùng lặp với một số tài liệu tham khảo có thể khiến bạn quan tâm
nik

3

IMHO các FS đáng chú ý có sẵn cho linux là:

XFS (tốc độ đọc kém) được biết là nhẹ về tài nguyên hệ thống và nhanh với các tệp lớn nhưng kém để xử lý nhiều tệp nhỏ.

ReiserFS (tốc độ ghi kém) không tốt về tài nguyên hệ thống nhưng hoạt động rất tốt với nhiều tệp nhỏ.

EXT3 rơi vào giữa, hoạt động có thể chấp nhận được trên tất cả các trường (lý do tại sao nó được coi là Linux linux mặc định ).

Bản thân tôi chưa sử dụng EXT4 chứ không phải ReiserFS4 nhưng tôi đã xem xét một số điểm chuẩn và ReiserFS dường như có hiệu suất tốt nhất khi nói về tốc độ đọc, điều mà bạn nói là quan trọng nhất đối với bạn.

Hãy xem điều này: ReserFS4 X Ext4 X Ext3

Tôi muốn giới thiệu Ext3 vì tính ổn định, bảo mật và trưởng thành của nó, nhưng nếu tốc độ đọc là điều quan trọng nhất với bạn, bạn nên xem xét ReiserFS.

Hãy nhớ rằng bạn cũng nên xem xét việc sử dụng CPU, tính ổn định, bảo mật như vậy trước khi chọn một FS.

Và tất nhiên, làm một thí điểm, thử nghiệm và điểm chuẩn trên môi trường cụ thể của bạn luôn là cách tốt nhất để nói điều gì sẽ làm việc tốt nhất cho bạn.

Tái bút: Tôi đã đăng nhiều điểm chuẩn hơn nhưng tôi không thể đăng nhiều hơn một liên kết.

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.