Máy chủ MySQL nào cung cấp hiệu suất tốt hơn cho Magento


30

Bạn sử dụng máy chủ MySQL cho Magento là gì?

  • MySQL (Oracle)
  • Percona
  • những người khác (MariaDB)

Percona cung cấp một bộ ứng dụng cho bộ lưu trữ InnoDB được Magento sử dụng rất nhiều, nhưng những cải tiến này tạo ra sự khác biệt khi chạy một cửa hàng Magento.

Làm thế nào để bạn cải thiện hiệu suất (cách tiếp cận chung về kiến ​​trúc, không phải thông tin cụ thể về việc đặt các biến cụ thể như thế nào innodb_flush_log_at_trx_commit=2). Tôi biết NBS đã thử sao chép master-master nhưng điều đó không ổn định.

Tôi đã gặp phải một số vấn đề với bản sao chủ-nô với các lần đọc được chuyển hướng về phía nô lệ, vì có một số chậm trễ trong việc sao chép dữ liệu.

Di chuyển ra khỏi MySQL càng nhiều càng tốt? (tìm kiếm solr và như vậy).


1
FlorinelChis, Cảm ơn bạn về câu hỏi, nhưng đây là một chủ đề rất rộng (cải thiện hiệu suất) và lựa chọn một công cụ cơ sở dữ liệu là một lĩnh vực cho chính nó. Trừ khi có một thành phần mạnh mẽ của câu hỏi này liên quan cụ thể đến Magento, điều này có thể được hỏi tốt hơn trong Hỏi & Đáp DBA của chúng tôi . Nhưng bất cứ nơi nào bạn đặt ra câu hỏi của mình, bạn sẽ phải cung cấp nhiều thông tin hơn về các vấn đề cụ thể mà bạn đang gặp phải. Xin lỗi về sự nhầm lẫn, và chúc may mắn!
Robert Cartaino

Tôi hiểu rằng câu hỏi mơ hồ và có vẻ như là một chủ đề rất rộng. Về Magento không phải là rộng, nó liên quan đến các chi tiết rất cụ thể. MySQL là nút cổ chai khi bạn cần mở rộng quy mô Magento và từ kinh nghiệm của tôi chỉ cần thay đổi thành percona trong một số thiết lập sẽ tăng hiệu suất. Tôi muốn biết các sysadmin khác làm như thế nào. Tôi không tìm kiếm thông tin cụ thể như bạn cần đặt innodb-flush-log-at-trx-commit = 2, mà hướng tới cách tiếp cận về việc sử dụng Mysql, percona hoặc những người khác (MariaDB) để đạt được hiệu suất tốt hơn.
FlorinelChis

FlorinelChris, tôi không phải là chuyên gia về miền, nhưng dựa trên biểu quyết và cờ, tôi nghi ngờ câu hỏi này cần / đảm bảo thêm thông tin để nhận được phản hồi hữu ích. Nhưng tôi rất vui khi mở lại nó để cho cộng đồng xử lý nó một cách thích hợp. Bạn có thể muốn xem những thông tin nào bạn có thể thêm vào để mọi người không đoán được cách tốt nhất để giúp bạn.
Robert Cartaino

Câu trả lời:


73

Bạn đang bước vào một thế giới tối ưu hóa rộng lớn ở đây và chắc chắn không có một kích thước nào phù hợp với mọi phương pháp.

Xác định hiệu suất

Bạn có nghĩa là thời gian tải trang cho một người dùng, hoặc tổng dung lượng / tổng đồng thời? Hai là rất khác nhau rõ ràng - và không liên quan chặt chẽ. Hoàn toàn có thể có một cửa hàng nhanh với khả năng hạn chế; hoặc một cửa hàng chậm với nhiều công suất.

Vì vậy, khi giải quyết một trong hai loại hiệu suất:

  1. Thời gian tải trang cảm nhận của một người dùng
  2. Tổng công suất / đồng thời

Bạn phải giải quyết từng vấn đề một cách độc lập bằng các giải pháp riêng - đặc biệt là mỗi giải pháp đều có những điểm nghẽn riêng.

Hãy đưa ra giả định rằng bạn đang ở với một máy chủ có thẩm quyền đã cấu hình tối ưu các khía cạnh khác của máy chủ cho cửa hàng của bạn.

Thời gian tải trang cảm nhận của một người dùng

Có phải MySQL là nút cổ chai
số Không trực tiếp. Đó là tất cả về độ trễ, trong phần lớn các trường hợp khi kiểm tra thời gian tải trang - chỉ bộ nhớ cache sẽ bị tấn công. Vì vậy, chìa khóa ở đây là để giảm thiểu độ trễ.

  • Điều chỉnh kích thước bộ đệm của MySQL một cách thích hợp (không có câu trả lời đúng, chúng tôi điều chỉnh các cài đặt hoàn toàn khác nhau, hàng tháng, trên mỗi cửa hàng)
  • Giảm độ trễ mạng. Đối với khung 64 byte; 51,2 Lời đề nghị cho 10Mb / giây, 5,12 Chuyển đổi cho 100Mb / giây và 4,096 Lát cho 1Gb / giây. Điều này giúp cải thiện 20% chỉ bằng cách chuyển từ 100Mbps sang 1Gbps. s1
  • Tăng dung lượng mạng. Bạn sẽ ngạc nhiên khi nhiều megabyte mỗi giây được trao đổi giữa máy chủ Web và DB, thường vượt quá 10MB / s - vì vậy cần tối thiểu 100Mb / giây s1 . Hoặc, chỉ cần di chuyển máy chủ DB cục bộ.
  • Sử dụng SOLR. Các công cụ bên ngoài đôi khi phù hợp hơn, chắc chắn SOLR nhanh hơn cho các danh mục LARGER (và tôi nhấn mạnh, các danh mục lớn hơn ). Ngay cả SOLR không được điều chỉnh sẽ tạo ra điều hướng lớp và kết quả tìm kiếm nhanh hơn MySQL có thể.

Nhưng những thay đổi này sẽ có tác động phân đoạn như vậy đối với thời gian tải trang - nơi mà nút cổ chai thực sự ở nơi khác.

  • Điều chỉnh ứng dụng. Magento có một số lỗi khá lớn với cách nó xây dựng các bộ sưu tập và lưu trữ chúng; chúng tôi đã gặp một số vấn đề về mã lõi lớn có thể làm tê liệt hiệu năng. Trong một số trường hợp, chỉ cần xóa màn hình đếm sản phẩm trên kết quả điều hướng được xếp lớp đã cạo 2 giây khi tải một bộ sưu tập lớn.
  • Xem lại nhật ký chậm của MySQL. Kiểm tra các truy vấn chậm và thêm các chỉ mục khi cần thiết. Sự khác biệt giữa việc chạy một truy vấn phức tạp có nhiều phép nối có và không có chỉ mục thích hợp có thể là hàng chục giây .

Ứng dụng này là nút cổ chai. Không phải phần mềm. Vì vậy, chỉ cần cải thiện mã lõi hoặc làm cho mẫu của bạn bớt nặng hơn sẽ có hiệu quả rõ rệt hơn về hiệu suất so với BẤT K change thay đổi cấu hình MySQL nào.

Chúng ta sẽ không bận tâm điều gì

  • Thay đổi công cụ lưu trữ. MariaDB và Percona chia sẻ cùng một công cụ InnoDB - Percona XtraDB. Họ có thể được coi là một và giống nhau. Về mặt thời gian thực hiện truy vấn duy nhất - hiệu suất sẽ phản ánh chính xác một bản dựng vanilla MySQL. Điều này đi vào chơi dưới tải / đồng thời.
  • Chạy một nô lệ MySQL. Điều này sẽ không cải thiện hiệu suất trừ khi nô lệ được đặt gần hơn về mặt vật lý (từ góc độ mạng) hoặc nô lệ có phần cứng tốt hơn so với máy chủ. Điều này đi vào chơi dưới tải / đồng thời.
  • Chạy một máy chủ DB bên ngoài. Đây là lời khuyên tồi tệ nhất mà chúng tôi thấy nhiều lần được đưa ra bởi nhiều máy chủ / cơ quan. Cho đến khi bạn đạt được mức trần về phần cứng / tài nguyên hoặc bạn đã có nhiều máy chủ web (đọc: tính sẵn sàng cao), MySQL trên máy cục bộ cho cửa hàng Magento là Ý tưởng hay. Nó cắt bỏ tất cả các chi phí và độ trễ mạng. Ngay cả mạng 100Gb / giây (vâng, một trăm gigabit mỗi giây) sẽ không so sánh với ổ cắm unix cục bộ về khối lượng thô, thông lượng và độ trễ.

s1 Chỉ dành cho máy chủ cơ sở dữ liệu riêng biệt. Không áp dụng cho các máy chủ DB cục bộ.

Tổng công suất / đồng thời

Có phải MySQL là nút cổ chai
Có lẽ. Nhưng chỉ khi bạn đóng đinh hiệu năng và năng lực PHP của bạn đến mức MySQL làm mọi thứ chậm lại. Nếu bạn có Varnish và FPC được cấu hình đúng cách (đừng để chúng tôi bắt đầu với bao nhiêu lần thử thất bại mà chúng tôi đã thấy) - thì MySQL sẽ trở thành một nút cổ chai.

Vì vậy, ngoài các sửa đổi trên.

  • Thay đổi công cụ MySQL. XtraDB có thể vượt trội khi tải và không hiển thị lợi ích thực sự trên bản phân phối MySQL chứng khoán.
  • Luôn cập nhật với MySQL. 5.5 thực hiện tốt hơn 5.0 dưới tải.
  • Thay đổi trình điều khiển PHP MySQL. PHP 5.3 và mới hơn có trình điều khiển MySQL gốc, nhưng trong một số trường hợp, chúng tôi đã tìm thấy PHP 5.2 với trình điều khiển riêng để vượt trội hơn MySQLND cho Magento. Tự kiểm tra
  • Thay đổi công cụ tìm kiếm. Chuyển tìm kiếm ra SOLR / Sphinx (hoặc thậm chí một số dịch vụ bên ngoài của bên thứ 3) thực sự có thể giảm bớt gánh nặng của tải không giao dịch (ví dụ: mọi người không đặt hàng)
  • Thay đổi lớp điều hướng động cơ. Một lần nữa, SOLR là một công cụ tuyệt vời để điều hướng theo lớp và do tính chất không khóa của nó nhanh hơn nhiều so với MySQL.
  • Thêm một nô lệ MySQL. Điều này giúp tải trình duyệt (không giao dịch), nhưng sẽ không giúp bạn xử lý nhiều đơn hàng hơn mỗi giờ - vì nó phụ thuộc vào Master để xử lý và sao chép dữ liệu này

Chúng ta sẽ không bận tâm điều gì

  • Sư phụ sư phụ. Do điểm bão hòa phần cứng khá cao của thiết lập Master / Slave (vượt quá 1000 đơn hàng mỗi giờ) - chúng tôi chưa bao giờ thấy yêu cầu sử dụng Master / Master trong sản xuất. Chúng tôi đã thực hiện thử nghiệm rộng rãi, nhưng chưa bao giờ thấy nó có lợi thế từ góc độ hiệu suất và với các rủi ro và vấn đề cố hữu của Master / Master, đơn giản là nó không đáng.

Đọc so với khả năng mở rộng

Đoạn cuối thực sự dẫn đến một lĩnh vực chính là khả năng mở rộng đọc và viết. Đọc tỷ lệ có thể được thực hiện khá vô hạn mà không có quá nhiều phức tạp với việc thêm ngày càng nhiều nô lệ.

Với tỷ lệ Đọc trên Writes của Magento là khoảng 0,1% - việc xem xét việc viết không nên quan tâm nhiều. Đó là lý do tại sao tôi không bận tâm đến việc đề cập đến MySQL Cluster và các tính năng thông minh của nó như tự động tắt (tách bảng thành các máy riêng biệt).

Phần cứng, phần cứng, phần cứng

Phần cứng dễ dàng là câu trả lời nhanh nhất khi nói đến cải tiến, vì vậy tôi đã cố tình không đề cập đến nó ở trên trong cả hai kịch bản.

Nhưng tất cả các thay đổi phần mềm trên thế giới sẽ không tạo ra bất kỳ sự khác biệt nào nếu phần cứng cơ bản của bạn không đủ. Điều đó có nghĩa là ...

  • Công tắc chất lượng thấp với bộ đệm hạn chế
  • Liên kết mạng quá bão hòa
  • Máy chủ địa lý xa
  • QoS / CoS mạng kém
  • Tổng dung lượng RAM có hạn
  • RAM băng thông bộ nhớ thấp
  • Hệ thống con IOPs thấp
  • Bộ điều khiển RAID phần mềm
  • CPU tốc độ xung nhịp thấp
  • Chipset băng thông thấp
  • Ảo hóa phần cứng (hầu hết tất cả các loại ngoài Ảo hóa cấp hạt nhân)

Ngày nay, có một mức trần thực sự cao về mức độ bạn thực sự có thể mở rộng quy mô trên phần cứng. Hãy bỏ qua huyền thoại về quy mô vô hạn "trong đám mây" vì phần cứng đám mây có xu hướng khá tầm thường. Ví dụ, các mô hình hàng đầu của Amazon chỉ là 12 lõi @ 3,3 GHz. Nhưng bên ngoài điều này, có một số máy chủ rất mạnh có sẵn - máy chủ hàng đầu của chúng tôi có 160 lõi và 2TB (vâng, Terabyte) RAM. Chúng tôi chưa thấy ai vượt quá khả năng đó.

Vì vậy, bạn đã có một phạm vi rộng cho tỷ lệ dọc, thậm chí trước khi bạn cần xem xét tỷ lệ ngang.

Mục tiêu luôn chuyển động

Điều đáng nói của nó là trong quá trình theo đuổi hiệu suất, nút cổ chai sẽ luôn luôn di chuyển.

Đối với một cửa hàng Magento chứng khoán.

Bật bộ nhớ cache trên. PHP là nút cổ chai
Thêm bộ đệm phụ trợ. PHP là nút cổ chai
Thêm bộ đệm toàn trang ở cấp ứng dụng. PHP là nút cổ chai
Thêm bộ đệm phía trước cấp máy chủ (ví dụ: Varnish). MySQL là nút cổ chai
Thêm một công cụ điều hướng tìm kiếm / lớp thay thế (ví dụ: SOLR / Sphinx). PHP là nút cổ chai
Thêm nhiều máy chủ ứng dụng. MySQL là nút cổ chai
Thêm một nô lệ MySQL. Bộ đệm
phía trước là nút cổ chai Thêm nhiều máy chủ bộ đệm phía trước. PHP là nút cổ chai
Thêm nhiều máy chủ ứng dụng. SOLR / Sphinx là nút cổ chai

Etcetera.

Nó khá nhiều trở thành một trường hợp rửa lặp lại. Nhưng điều dễ hiểu là MySQL chắc chắn không phải là cổng đầu tiên để tối ưu hóa - và thực sự chỉ phát huy tác dụng khi MySQL tiêu thụ nhiều CPU hơn theo tỷ lệ với PHP - và điều này CHỈ xảy ra khi cả FPC và Varnish đang sử dụng và (các) máy chủ hoàn toàn xử lý các đơn đặt hàng và không có gì khác (vì mọi thứ khác đều nằm trong bộ đệm).

Đừng thay đổi một cách mù quáng

Đơn giản chỉ cần thêm một nô lệ MySQL bởi vì bạn đọc chúng tôi nói ở trên rằng nó sẽ giúp ích, có thể khiến bạn mất hiệu suất và độ tin cậy ở mức rất lớn. Mạng bị tắc nghẽn, máy chủ nô lệ thông số thấp hoặc thậm chí cài đặt không phù hợp có thể gây ra sự cố sao chép có thể khiến cửa hàng của bạn chậm hơn so với trước - hoặc gây ra sự cố đồng bộ hóa giữa Master và Slave.

Để đưa mọi thứ vào quan điểm - một số ví dụ thực tế.

Ví dụ 1 - 300 đơn hàng mỗi giờ

Chúng tôi đã sử dụng phần cứng sau đây để phục vụ 300 đơn hàng mỗi giờ ; và chỉ tại điểm tới hạn đó - sau đó chúng tôi cảm thấy cần phải thêm một máy chủ MySQL chuyên dụng và một nô lệ MySQL cục bộ.

1
CPU máy chủ : 2x Intel E5-4620
RAM: 64GB HDD: 4x 80k SSD IOP / s
RAID: RAID phần cứng 10
Phiên bản Magento: Magento EE
Hệ điều hành: MageStack

Trong toàn bộ thời gian, trung bình tải vẫn dưới 3.00.

Ví dụ 2 - 180 đơn hàng mỗi giờ

Chỉ hai ngày trước, một khách hàng mới của chúng tôi dễ dàng tăng vọt lưu lượng truy cập lớn. Xử lý 180 đơn hàng mỗi giờ với một máy chủ và Magento Community Edition .

1
CPU máy chủ : 2x Intel E5-4620
RAM: 64GB HDD: 4x 80k SSD IOP / s
RAID: RAID phần cứng 10
Phiên bản Magento: Magento CE
OS: MageStack
Trang web: Wellgosh.com

Trong toàn bộ thời gian, trung bình tải vẫn dưới 6,00. Tải trọng cao hơn trong kịch bản này và điều đó đã giảm xuống một vài yếu tố.

  1. Không có điều chỉnh phía cửa hàng nào được thực hiện như trong ví dụ 1
  2. Việc thiếu một FPC cấp ứng dụng

Và với sự chính xác của điều này, chúng tôi vẫn có số liệu thống kê chi tiết để đưa ra một số phản hồi bằng các biểu đồ. Chúng kể một câu chuyện tuyệt vời về cách phân phối tải giữa các thành phần chính của kiến ​​trúc Magento riêng biệt (bộ cân bằng tải, máy chủ web, máy chủ db, v.v. - sử dụng MageStack ).

Vì vậy, từ trước ra sau ... ngày bạn muốn xem là lúc 12:00 sáng ngày 22 tháng 2.

Gói tường lửa
Gói tường lửa

Giao thông mờ
Giao thông mờ

Giao thông Nginx
Giao thông Nginx

Tải MySQL
Chủ đề MySQL MySQL Byte Truy vấn MySQL

Tải CPU
Tải CPU

Và quan trọng nhất là phân phối tải

Hình ảnh này thực sự nói lên tất cả. Và đó là MySQL chắc chắn không phải là một gánh nặng - ít nhất là chưa. Vì vậy, lời khuyên của chúng tôi, tập trung vào mối quan tâm hiệu suất của bạn ở nơi khác, trừ khi bạn đang xử lý hơn vài nghìn đơn hàng mỗi giờ.

Phân phối tải

Và tóm lại

Thực hiện thay đổi hiệu suất không phải là "một kích thước phù hợp với tất cả". Đó là một trường hợp phân tích các tắc nghẽn hiện tại của bạn và thực hiện các thay đổi / điều chỉnh tinh tế cho phù hợp với cửa hàng và cơ sở hạ tầng của bạn.

Nhưng hiệu quả sang một bên, có những lợi ích khác khi sử dụng Percona

Chúng tôi sử dụng Percona XtraDB, gần như độc quyền. Chúng tôi chạy các bản dựng được biên dịch tùy chỉnh của MySQL mà chúng tôi đã phát triển riêng cho Magento và đã tham khảo Percona trong quá trình này. Nhưng đó không chỉ là hiệu suất ảnh hưởng đến sự lựa chọn này.

  • Bộ công cụ Percona
    • pt-truy vấn-tiêu hóa
    • xtrabackup
    • v.v.
  • Tần số phát hành Percona
  • Hỗ trợ tư vấn của Percona
  • Khởi động lại bộ đệm ấm với bảo quản hồ bơi InnoDB

Và nhiều hơn nữa. Vì vậy, sử dụng nó trên MySQL có những lợi thế khác ngoài hiệu năng. Trong thực tế - MySQL là và luôn là mối quan tâm tối thiểu của chúng tôi trong việc theo đuổi hiệu suất và sự ổn định.

Các bản phân phối: wellgosh.com , sonassi.com , iebmedia.com .


đó là một câu trả lời dài :) Rất nhiều đánh giá cao, Cảm ơn bạn. Về quy mô và tải trên MySQL ở đây là biểu đồ munin từ MySQL: twitter.com/ze_m0n5t3r/status/232864932482396160 . Tối ưu hóa Magento là một quá trình liên tục (nhiều lỗi khác nhau, mã không được tối ưu hóa, v.v.). Giảm tải (di chuyển tìm kiếm / điều hướng sang solr, bộ nhớ đệm tốt hơn) là cách tiếp cận đầu tiên. Nhưng ngoài ra, DB cần phải cư xử tốt hơn với bộ đệm lạnh. Và khi điều đó xảy ra, tôi đang tìm kiếm một trang web chậm hơn có dung lượng lớn hơn.
FlorinelChis

Không có chi. Không có lý do gì để nói rằng bạn không thể có một trang web nhanh dung lượng lớn - khách hàng của chúng tôi làm được . Rõ ràng có một chút hiệu năng của MySQL hơn là tôi đã chọn đề cập ở trên. Nhưng điều đó sẽ cho đi phần nào 'nước sốt bí mật' của chúng ta. Tôi đã hướng câu trả lời đó cho các chủ cửa hàng nhỏ (<25k đơn vị / ngày) theo hướng dẫn 'khởi đầu' đối với MySQL.
Ben Lessani - Sonassi

Chỉ là một sidenote. Nhìn vào biểu đồ của bạn, các phần chèn của bạn đạt mức cao nhất khoảng 10 lần tải thông thường của bạn, các cập nhật vẫn ở mức thấp và các lựa chọn cho thấy gánh nặng lớn nhất. Tôi muốn đánh cược các phần chèn là nhật ký khách hàng, mức độ liên quan / truy vấn tìm kiếm hoặc các phiên cấm. Nhưng vẫn là một con số đủ nhỏ để không gây ra vấn đề hoặc thậm chí xem xét Master / Master. Vì vậy, dựa trên biểu đồ của bạn, việc bổ sung đơn giản nhiều phần cứng sẽ là quá đủ; với một nô lệ theo đó. Và giữ ấm bộ nhớ cache giữa các lần khởi động lại thật dễ dàng với Percona, s.onas.si/5g8s
Ben Lessani - Sonassi 23/2/13

tìm kiếm là solr, phiên - memcache. Bạn có biết ai đang điều hành một bậc thầy thành công không? (NBS thất bại về vấn đề này, chúng tôi đã thất bại với điều này là tốt, nó không ổn định với Magento, hoạt động tốt trên các ứng dụng php nhẹ khác)
FlorinelChis

1
Đây là một câu trả lời đáng kinh ngạc. Chỉ muốn nói điều đó.
thùng rác
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.