Bản ghi báo cáo năm 2015 của Ilya Kosmodemyansky "Điều chỉnh Linux để cải thiện hiệu suất PostgreSQL"
Tuyên bố miễn trừ trách nhiệm: Tôi lưu ý rằng báo cáo này được lập vào tháng 2015 năm 4 - đã hơn 9.4 năm trôi qua và rất nhiều thời gian đã trôi qua. Phiên bản 4 được thảo luận trong báo cáo không còn được hỗ trợ. Trong 5 năm qua, 15 bản phát hành PostgreSQL mới đã được phát hành và XNUMX phiên bản nhân Linux đã được phát hành. Nếu bạn viết lại những đoạn này, bạn sẽ có một báo cáo khác. Nhưng ở đây chúng tôi xem xét việc điều chỉnh Linux cơ bản cho PostgreSQL, điều này vẫn còn phù hợp cho đến ngày nay.
Tên tôi là Ilya Kosmodemyansky. Tôi làm việc tại PostgreSQL-Consulting. Và bây giờ tôi sẽ nói một chút về những việc cần làm với Linux liên quan đến cơ sở dữ liệu nói chung và PostgreSQL nói riêng, vì các nguyên tắc khá giống nhau.
Chúng ta sẽ nói về điều gì? Nếu bạn giao tiếp với PostgreSQL thì ở một mức độ nào đó bạn cần phải là quản trị viên UNIX. Nó có nghĩa là gì? Nếu chúng ta so sánh Oracle và PostgreSQL, thì trong Oracle, bạn cần phải là 80% quản trị viên cơ sở dữ liệu DBA và 20% quản trị viên Linux.
Với PostgreSQL thì phức tạp hơn một chút. Với PostgreSQL bạn cần hiểu rõ hơn nhiều về cách Linux hoạt động. Đồng thời, hãy chạy theo đầu máy một chút, vì gần đây mọi thứ đã được cập nhật khá đẹp mắt. Và các hạt nhân mới được phát hành, chức năng mới xuất hiện, hiệu suất được cải thiện, v.v.
Tại sao chúng ta lại nói về Linux? Hoàn toàn không phải vì chúng ta đang tham dự hội nghị Linux mà vì trong điều kiện hiện đại, một trong những hệ điều hành hợp lý nhất để sử dụng cơ sở dữ liệu nói chung và PostgreSQL nói riêng là Linux. Bởi vì thật không may, FreeBSD đang phát triển theo một hướng rất kỳ lạ. Và sẽ có vấn đề cả về hiệu suất và nhiều thứ khác. Hiệu suất của PostgreSQL trên Windows nói chung là một vấn đề nghiêm trọng riêng biệt, dựa trên thực tế là Windows không có cùng bộ nhớ dùng chung như UNIX, trong khi PostgreSQL đều liên quan đến vấn đề này, vì đây là một hệ thống đa quy trình.
Và tôi nghĩ mọi người ít quan tâm đến những thứ ngoại lai như Solaris, vậy nên đi thôi.
Một bản phân phối Linux hiện đại có hơn 1 tùy chọn syctl, tùy thuộc vào cách bạn xây dựng kernel. Đồng thời, nếu nhìn vào các loại hạt khác nhau, chúng ta có thể điều chỉnh một thứ gì đó theo nhiều cách. Có các tham số hệ thống tập tin về cách gắn kết chúng. Nếu bạn có thắc mắc về cách khởi động nó: kích hoạt những gì trong BIOS, cách định cấu hình phần cứng, v.v.
Đây là một khối lượng rất lớn có thể được thảo luận trong vài ngày chứ không phải trong một báo cáo ngắn, nhưng bây giờ tôi sẽ tập trung vào những điều quan trọng, làm thế nào để tránh những hành vi cào được đảm bảo ngăn cản bạn sử dụng tốt cơ sở dữ liệu của mình trên Linux nếu bạn đừng sửa chúng. Và đồng thời, một điểm quan trọng là nhiều tham số mặc định không được đưa vào cài đặt chính xác cho cơ sở dữ liệu. Nghĩa là, theo mặc định nó sẽ hoạt động kém hoặc hoàn toàn không hoạt động.
Những mục tiêu điều chỉnh truyền thống nào có trong Linux? Tôi nghĩ rằng vì tất cả các bạn đều đang làm việc với quản trị Linux nên không cần phải giải thích cụ thể mục tiêu là gì.
Bạn có thể điều chỉnh:
- CPU.
- Ký ức.
- Lưu trữ.
- Khác. Chúng ta sẽ nói về điều này vào cuối bữa ăn nhẹ. Ví dụ, thậm chí, các thông số như chính sách tiết kiệm năng lượng có thể ảnh hưởng đến hiệu suất theo cách rất khó lường và không mấy dễ chịu.
Các chi tiết cụ thể của PostgreSQL và cơ sở dữ liệu nói chung là gì? Vấn đề là bạn không thể điều chỉnh bất kỳ đai ốc riêng lẻ nào và thấy rằng hiệu suất của chúng tôi đã được cải thiện đáng kể.
Vâng, có những tiện ích như vậy, nhưng cơ sở dữ liệu là một thứ phức tạp. Nó tương tác với tất cả các tài nguyên mà máy chủ có và thích tương tác ở mức tối đa. Nếu bạn nhìn vào các khuyến nghị hiện tại của Oracle về cách sử dụng hệ điều hành máy chủ, nó sẽ giống như trò đùa về nhà du hành vũ trụ người Mông Cổ đó - cho chó ăn và không được chạm vào bất cứ thứ gì. Hãy cung cấp cho cơ sở dữ liệu tất cả các tài nguyên, cơ sở dữ liệu sẽ tự sắp xếp mọi thứ.
Về nguyên tắc, ở một mức độ nào đó, tình hình hoàn toàn giống với PostgreSQL. Sự khác biệt là cơ sở dữ liệu vẫn chưa thể tự mình lấy tất cả tài nguyên, tức là ở đâu đó ở cấp độ Linux, bạn cần phải tự mình sắp xếp tất cả.
Ý tưởng chính không phải là chọn một mục tiêu duy nhất và bắt đầu điều chỉnh nó, chẳng hạn như bộ nhớ, CPU hoặc thứ gì đó tương tự, mà là phân tích khối lượng công việc và cố gắng cải thiện thông lượng nhiều nhất có thể để tải mà các lập trình viên giỏi đã tạo ra nó. cho chúng tôi, bao gồm cả người dùng của chúng tôi.
Đây là một hình ảnh để giải thích nó là gì. Có bộ đệm của hệ điều hành Linux, có bộ nhớ dùng chung và có bộ đệm dùng chung PostgreSQL. PostgreSQL, không giống như Oracle, chỉ hoạt động trực tiếp thông qua bộ đệm hạt nhân, tức là để một trang từ đĩa đi vào bộ nhớ dùng chung của nó, nó phải đi qua bộ đệm hạt nhân và quay lại, tình huống tương tự.
Đĩa sống theo hệ thống này. Tôi đã vẽ cái này dưới dạng đĩa. Trên thực tế, có thể có bộ điều khiển RAID, v.v.
Và đầu vào-đầu ra này bằng cách này hay cách khác xảy ra thông qua vấn đề này.
PostgreSQL là một cơ sở dữ liệu cổ điển. Có một trang bên trong. Và tất cả đầu vào và đầu ra đều xảy ra bằng cách sử dụng các trang. Chúng tôi đang nâng các khối vào bộ nhớ bằng các trang. Và nếu không có gì xảy ra, chúng tôi chỉ đọc chúng, sau đó dần dần chúng biến mất khỏi bộ đệm này, khỏi bộ đệm dùng chung và quay trở lại đĩa.
Nếu chúng ta thay thế thứ gì đó ở đâu đó thì toàn bộ trang sẽ bị đánh dấu là bẩn. Tôi đã đánh dấu chúng ở đây bằng màu xanh lam. Và điều này có nghĩa là trang này phải được đồng bộ hóa với bộ nhớ khối. Nghĩa là, khi chúng tôi làm bẩn nó, chúng tôi đã tạo một mục trong WAL. Và vào một thời điểm tuyệt vời nào đó, một hiện tượng gọi là trạm kiểm soát đã xuất hiện. Và thông tin được ghi lại trong nhật ký này là anh đã đến. Và điều này có nghĩa là tất cả các trang bẩn có mặt tại thời điểm đó trong các bộ đệm dùng chung này đã được đồng bộ hóa với đĩa lưu trữ bằng cách sử dụng fsync thông qua bộ đệm kernel.
Tại sao việc này lại được thực hiện? Nếu mất điện áp thì chúng ta không gặp phải tình trạng mất hết dữ liệu. Trí nhớ liên tục, điều mà mọi người đã nói với chúng tôi, cho đến nay vẫn nằm trong lý thuyết cơ sở dữ liệu - đây là một tương lai tươi sáng, tất nhiên, chúng tôi phấn đấu và chúng tôi thích nó, nhưng hiện tại họ sống trong âm 20 năm. Và tất nhiên, tất cả điều này cần phải được theo dõi.
Và nhiệm vụ tối đa hóa thông lượng là tinh chỉnh ở tất cả các giai đoạn này để tất cả di chuyển qua lại nhanh chóng. Bộ nhớ dùng chung về cơ bản là bộ đệm trang. Trong PostgreSQL, chúng tôi đã gửi một truy vấn chọn lọc hoặc thứ gì đó, nó đã lấy dữ liệu này từ đĩa. Họ đã kết thúc trong bộ đệm được chia sẻ. Theo đó, để cái này hoạt động tốt hơn thì phải có nhiều bộ nhớ.
Để tất cả những điều này hoạt động tốt và nhanh chóng, bạn cần cấu hình chính xác hệ điều hành ở tất cả các giai đoạn. Và hãy chọn phần cứng cân bằng, vì nếu bạn mất cân bằng ở một chỗ nào đó, thì bạn có thể tạo ra rất nhiều bộ nhớ, nhưng nó sẽ không được phục vụ ở tốc độ đủ.
Và chúng ta hãy đi qua từng điểm này.
Để làm cho các trang này di chuyển qua lại nhanh hơn, bạn cần đạt được những điều sau:
- Đầu tiên, bạn cần làm việc hiệu quả hơn với trí nhớ.
- Thứ hai, quá trình chuyển đổi này khi các trang từ bộ nhớ chuyển sang đĩa sẽ hiệu quả hơn.
- Và thứ ba, phải có đĩa tốt.
Nếu bạn có 512 GB RAM trong máy chủ và tất cả RAM đó nằm trên ổ cứng SATA mà không có bất kỳ bộ đệm nào, thì toàn bộ máy chủ cơ sở dữ liệu sẽ không chỉ trở thành một quả bí ngô mà còn là một quả bí ngô có giao diện SATA. Bạn sẽ gặp trực tiếp nó. Và không có gì sẽ cứu bạn.
Về điểm đầu tiên với trí nhớ, có ba điều có thể khiến cuộc sống trở nên rất khó khăn.
Đầu tiên trong số đó là NUMA. NUMA là thứ được tạo ra để cải thiện hiệu suất. Tùy thuộc vào khối lượng công việc, những thứ khác nhau có thể được tối ưu hóa. Và ở dạng mới hiện tại, nó không tốt lắm cho các ứng dụng như cơ sở dữ liệu sử dụng nhiều bộ đệm chia sẻ bộ đệm trang.
Tóm lại. Làm thế nào bạn có thể biết được có điều gì đó không ổn với NUMA? Bạn gặp phải một số tiếng gõ khó chịu, đột nhiên một số CPU bị quá tải. Đồng thời, bạn phân tích các truy vấn trong PostgreSQL và thấy rằng không có gì tương tự ở đó. Những truy vấn này không nên sử dụng nhiều CPU. Bạn có thể nắm bắt điều này trong một thời gian dài. Việc sử dụng đề xuất chính xác ngay từ đầu về cách định cấu hình NUMA cho PostgreSQL sẽ dễ dàng hơn.
Chuyện gì đang thực sự xảy ra vậy? NUMA là viết tắt của Truy cập bộ nhớ không đồng nhất. Vấn đề ở đây là gì? Bạn có một CPU, bên cạnh nó là bộ nhớ cục bộ của nó. Và các kết nối bộ nhớ này có thể lấy bộ nhớ từ các CPU khác.
Nếu bạn chạy numactl --hardware, thì bạn sẽ có được một tờ giấy lớn như vậy. Trong số những thứ khác, sẽ có một trường khoảng cách. Sẽ có những con số - 10-20, đại loại như vậy. Những con số này không gì khác hơn là số bước nhảy để nhận bộ nhớ từ xa này và sử dụng nó cục bộ. Về nguyên tắc, đó là một ý tưởng tốt. Điều này tăng tốc hiệu suất tốt trong một loạt khối lượng công việc.
Bây giờ hãy tưởng tượng rằng trước tiên bạn có một CPU đang cố gắng sử dụng bộ nhớ cục bộ của nó, sau đó cố gắng lấy một bộ nhớ khác thông qua kết nối để làm gì đó. Và CPU này lấy toàn bộ bộ đệm trang PostgreSQL của bạn - chỉ vậy thôi, vài gigabyte. Bạn luôn gặp trường hợp xấu nhất, vì trên CPU thường có ít bộ nhớ trong chính mô-đun đó. Và tất cả bộ nhớ được phục vụ đều đi qua các kết nối này. Hóa ra chậm và buồn. Và bộ xử lý phục vụ nút này của bạn liên tục bị quá tải. Và thời gian truy cập bộ nhớ này kém, chậm. Đây là tình huống bạn không mong muốn nếu bạn đang sử dụng cơ sở dữ liệu này.
Do đó, một lựa chọn đúng đắn hơn cho cơ sở dữ liệu là hệ điều hành Linux không biết chuyện gì đang xảy ra ở đó. Vì vậy, nó truy cập vào bộ nhớ như nó làm.
Tại sao vậy? Có vẻ như mọi chuyện phải diễn ra theo cách khác. Điều này xảy ra vì một lý do đơn giản: chúng ta cần nhiều bộ nhớ cho bộ đệm trang - hàng chục, hàng trăm gigabyte.
Và nếu chúng ta phân bổ tất cả những thứ này và lưu trữ dữ liệu của mình vào bộ nhớ đệm ở đó, thì lợi ích thu được từ việc sử dụng bộ nhớ đệm sẽ lớn hơn đáng kể so với lợi ích thu được từ việc truy cập bộ nhớ phức tạp như vậy. Và do đó, chúng ta sẽ được hưởng lợi không thể so sánh được so với việc chúng ta sẽ truy cập bộ nhớ hiệu quả hơn bằng cách sử dụng NUMA.
Do đó, hiện tại có hai cách tiếp cận, cho đến khi tương lai tươi sáng đến và bản thân cơ sở dữ liệu không thể tìm ra CPU nào nó đang chạy và nó cần lấy thứ gì đó từ đâu.
Do đó, cách tiếp cận đúng là tắt hoàn toàn NUMA, ví dụ: khi khởi động lại. Trong hầu hết các trường hợp, số tiền thắng cược có mức độ lớn đến mức câu hỏi về cái nào tốt hơn hoàn toàn không được đặt ra.
Có một lựa chọn khác. Chúng tôi sử dụng nó thường xuyên hơn cái đầu tiên, bởi vì khi một khách hàng đến với chúng tôi để được hỗ trợ, việc khởi động lại máy chủ là một vấn đề lớn đối với anh ta. Anh ấy có công việc kinh doanh ở đó. Và họ gặp vấn đề vì NUMA. Do đó, chúng tôi cố gắng vô hiệu hóa nó theo những cách ít xâm lấn hơn so với khởi động lại, nhưng hãy cẩn thận kiểm tra xem nó có bị vô hiệu hóa hay không. Bởi vì, như kinh nghiệm cho thấy, thật tốt khi chúng tôi tắt NUMA trên quy trình PostgreSQL gốc, nhưng không nhất thiết là nó sẽ hoạt động. Chúng ta cần kiểm tra xem cô ấy có thực sự tắt máy hay không.
Có một bài viết hay của Robert Haas. Đây là một trong những người cam kết PostgreSQL. Một trong những nhà phát triển chính của tất cả các sản phẩm cấp thấp. Và nếu bạn theo dõi các liên kết từ bài đăng này, chúng sẽ mô tả một số câu chuyện đầy màu sắc về việc NUMA đã gây khó khăn cho cuộc sống của mọi người như thế nào. Hãy xem, nghiên cứu danh sách kiểm tra của quản trị viên hệ thống về những gì cần được cấu hình trên máy chủ để cơ sở dữ liệu của chúng tôi hoạt động tốt. Những cài đặt này cần phải được ghi lại và kiểm tra, vì nếu không nó sẽ không tốt lắm.
Xin lưu ý rằng điều này áp dụng cho tất cả các cài đặt mà tôi sẽ nói đến. Nhưng thông thường cơ sở dữ liệu được thu thập ở chế độ chủ-nô lệ để có khả năng chịu lỗi. Đừng quên thực hiện những cài đặt này trên Slave vì một ngày nào đó bạn sẽ gặp tai nạn và bạn sẽ chuyển sang Slave và nó sẽ trở thành Master.
Trong tình huống khẩn cấp, khi mọi thứ đang rất tồi tệ, điện thoại của bạn liên tục đổ chuông và sếp cầm gậy lớn chạy đến, bạn sẽ không còn thời gian để nghĩ đến việc kiểm tra. Và kết quả có thể khá thảm khốc.
Điểm tiếp theo là các trang lớn. Rất khó để kiểm tra các trang lớn một cách riêng biệt và chẳng ích gì khi làm như vậy, mặc dù có những điểm chuẩn có thể làm được điều này. Họ rất dễ dàng với Google.
Vấn đề ở đây là gì? Bạn có một máy chủ không đắt lắm với nhiều RAM, chẳng hạn như hơn 30 GB. Bạn không sử dụng các trang lớn. Điều này có nghĩa là bạn chắc chắn phải tốn chi phí sử dụng bộ nhớ. Và chi phí này không phải là điều dễ chịu nhất.
Tại sao vậy? Vì vậy những gì đang xảy ra? Hệ điều hành phân bổ bộ nhớ thành từng phần nhỏ. Thật tiện lợi, đó là cách nó đã diễn ra trong lịch sử. Và nếu chúng ta đi vào chi tiết, hệ điều hành phải dịch địa chỉ ảo thành địa chỉ vật lý. Và quá trình này không phải là đơn giản nhất, vì vậy hệ điều hành sẽ lưu trữ kết quả của thao tác này trong Bộ đệm tra cứu dịch thuật (TLB).
Và vì TLB là bộ đệm nên tất cả các vấn đề vốn có trong bộ đệm đều phát sinh trong tình huống này. Thứ nhất, nếu bạn có nhiều RAM và tất cả đều được phân bổ thành từng phần nhỏ thì bộ đệm này sẽ trở nên rất lớn. Và nếu bộ đệm lớn thì việc tìm kiếm trong đó sẽ chậm hơn. Chi phí hoạt động tốt và bản thân nó chiếm dung lượng, tức là RAM đang bị tiêu thụ bởi một thứ gì đó không chính xác. Thời gian này.
Thứ hai - bộ nhớ đệm càng phát triển trong tình huống như vậy thì càng có nhiều khả năng bạn sẽ bị thiếu bộ nhớ đệm. Và hiệu quả của bộ đệm này giảm nhanh khi kích thước của nó tăng lên. Do đó, hệ điều hành đã đưa ra một cách tiếp cận đơn giản. Nó đã được sử dụng trong Linux từ lâu. Nó xuất hiện trong FreeBSD cách đây không lâu. Nhưng chúng ta đang nói về Linux. Đây là những trang lớn.
Và ở đây cần lưu ý rằng các trang lớn, về mặt ý tưởng, ban đầu được thúc đẩy bởi các cộng đồng bao gồm Oracle và IBM, tức là các nhà sản xuất cơ sở dữ liệu thực sự nghĩ rằng điều này cũng sẽ hữu ích cho cơ sở dữ liệu.
Và làm thế nào điều này có thể trở thành bạn bè với PostgreSQL? Đầu tiên, các trang lớn phải được kích hoạt trong nhân Linux.
Thứ hai, chúng phải được chỉ định rõ ràng bằng tham số sysctl - có bao nhiêu. Những con số ở đây là từ một số máy chủ cũ. Bạn có thể tính toán xem bạn có bao nhiêu vùng đệm được chia sẻ để có thể chứa các trang lớn ở đó.
Và nếu toàn bộ máy chủ của bạn được dành riêng cho PostgreSQL, thì điểm khởi đầu tốt là phân bổ 25% RAM cho bộ đệm dùng chung hoặc 75% nếu bạn chắc chắn rằng cơ sở dữ liệu của mình chắc chắn sẽ phù hợp với 75% này. Điểm khởi đầu một. Và hãy cân nhắc, nếu bạn có 256 GB RAM thì tương ứng, bạn sẽ có 64 GB bộ đệm lớn. Tính toán gần đúng với một số lề - con số này sẽ được đặt thành bao nhiêu.
Trước phiên bản 9.2 (nếu tôi không nhầm, kể từ phiên bản 8.2), có thể kết nối PostgreSQL với các trang lớn bằng thư viện của bên thứ ba. Và điều này phải luôn luôn được thực hiện. Đầu tiên, bạn cần có kernel để có thể phân bổ các trang lớn một cách chính xác. Và thứ hai, để ứng dụng hoạt động với chúng có thể sử dụng chúng. Nó sẽ không chỉ được sử dụng theo cách đó. Do PostgreSQL cấp phát bộ nhớ theo kiểu hệ thống 5 nên việc này có thể được thực hiện bằng cách sử dụng libhugetlbfs - đây là tên đầy đủ của thư viện.
Trong phiên bản 9.3, hiệu năng của PostgreSQL đã được cải thiện khi làm việc với bộ nhớ và phương pháp phân bổ bộ nhớ của hệ thống 5 đã bị loại bỏ. Mọi người đều rất vui vì nếu không bạn cố chạy hai phiên bản PostgreSQL trên một máy và anh ấy nói rằng tôi không có đủ bộ nhớ dùng chung. Và anh ấy nói rằng sysctl cần phải được sửa chữa. Và có một sysctl mà bạn vẫn cần phải khởi động lại, v.v. Nói chung, mọi người đều vui vẻ. Nhưng việc cấp phát bộ nhớ mmap đã phá vỡ việc sử dụng các trang lớn. Hầu hết khách hàng của chúng tôi sử dụng bộ đệm chia sẻ lớn. Và chúng tôi thực sự khuyên bạn không nên chuyển sang 9.3, vì chi phí ở đó bắt đầu được tính theo tỷ lệ phần trăm tốt.
Nhưng cộng đồng đã chú ý đến vấn đề này và ở phiên bản 9.4 họ đã làm lại sự kiện này rất tốt. Và trong phiên bản 9.4, một tham số đã xuất hiện trong postgresql.conf trong đó bạn có thể bật thử, bật hoặc tắt.
Hãy thử là lựa chọn an toàn nhất. Khi PostgreSQL khởi động, khi nó phân bổ bộ nhớ dùng chung, nó sẽ cố lấy bộ nhớ này từ các trang lớn. Và nếu nó không hoạt động thì nó sẽ quay trở lại lựa chọn bình thường. Và nếu bạn có FreeBSD hoặc Solaris thì bạn có thể dùng thử, nó luôn an toàn.
Nếu được bật, thì nó sẽ không khởi động nếu không thể chọn từ các trang lớn. Ở đây nó đã nói về ai và cái gì đẹp hơn. Nhưng nếu bạn đã thử, hãy kiểm tra xem bạn có thực sự đánh dấu được những gì bạn cần hay không, vì có rất nhiều chỗ có thể xảy ra lỗi. Hiện tại chức năng này chỉ hoạt động trên Linux.
Một lưu ý nhỏ nữa trước khi chúng ta đi xa hơn. Các trang lớn trong suốt vẫn chưa nói về PostgreSQL. Anh ấy không thể sử dụng chúng một cách bình thường. Và với các trang lớn trong suốt dành cho khối lượng công việc như vậy, khi cần một lượng lớn bộ nhớ dùng chung, lợi ích chỉ đến với khối lượng rất lớn. Nếu bạn có bộ nhớ hàng terabyte thì điều này có thể phát huy tác dụng. Nếu chúng ta đang nói về nhiều ứng dụng hàng ngày hơn, khi bạn có bộ nhớ 32, 64, 128, 256 GB trên máy của mình, thì các trang lớn thông thường vẫn ổn và chúng tôi chỉ cần tắt Minh bạch.
Và điều cuối cùng về trí nhớ không liên quan trực tiếp đến trái cây, nó thực sự có thể hủy hoại cuộc đời bạn. Tất cả thông lượng sẽ bị ảnh hưởng rất lớn bởi việc máy chủ liên tục bị hoán đổi.
Và điều này sẽ rất khó chịu theo một số cách. Và vấn đề chính là các nhân hiện đại hoạt động hơi khác so với các nhân Linux cũ hơn. Và điều này khá khó chịu khi bước tiếp, bởi vì khi chúng ta nói về một số loại công việc có trao đổi, nó kết thúc với sự xuất hiện không đúng lúc của kẻ giết người OOM. Và OOM-killer không xuất hiện kịp thời và làm rơi PostgreSQL, thật khó chịu. Mọi người sẽ biết về điều này, nghĩa là cho đến người dùng cuối cùng.
Chuyện gì đang xảy ra vậy? Bạn có một lượng RAM lớn ở đó, mọi thứ đều hoạt động tốt. Nhưng vì lý do nào đó mà máy chủ bị treo trong trao đổi và hoạt động chậm lại vì điều này. Có vẻ như có rất nhiều bộ nhớ, nhưng điều này vẫn xảy ra.
Trước đây, chúng tôi khuyên bạn nên đặt vm.swappiness về 32, tức là tắt tính năng trao đổi. Trước đây, có vẻ như XNUMX GB RAM và bộ đệm chia sẻ tương ứng là một con số rất lớn. Mục đích chính của việc hoán đổi là có chỗ để ném vỏ bánh nếu chúng ta rơi ra. Và nó không còn được thực hiện một cách đặc biệt nữa. Và sau đó bạn sẽ làm gì với lớp vỏ này? Đây là một nhiệm vụ mà không rõ tại sao lại cần trao đổi, đặc biệt là ở quy mô như vậy.
Nhưng trong phiên bản hiện đại hơn, tức là phiên bản thứ ba của hạt nhân, hành vi đã thay đổi. Và nếu bạn đặt trao đổi thành XNUMX, tức là tắt nó đi, thì sớm hay muộn, ngay cả khi còn một ít RAM, một kẻ giết người OOM sẽ đến với bạn để tiêu diệt những người tiêu dùng chuyên sâu nhất. Bởi vì anh ấy sẽ cho rằng với khối lượng công việc như vậy, chúng tôi vẫn còn một chút và chúng tôi sẽ nhảy ra ngoài, tức là không phải hoàn thành quy trình hệ thống mà là giải quyết một số việc ít quan trọng hơn. Người ít quan trọng hơn này sẽ là người sử dụng nhiều bộ nhớ dùng chung, cụ thể là người quản lý bưu điện. Và sau đó sẽ tốt hơn nếu không phải khôi phục lại căn cứ.
Do đó, bây giờ là mặc định, theo như tôi nhớ, hầu hết các bản phân phối đều ở khoảng 6, tức là bạn nên bắt đầu sử dụng trao đổi vào thời điểm nào tùy thuộc vào dung lượng bộ nhớ còn lại. Bây giờ chúng tôi khuyên bạn nên đặt vm.swappiness = 1, vì điều này thực tế sẽ tắt nó nhưng không mang lại hiệu ứng tương tự như với một kẻ giết người OOM bất ngờ xuất hiện và giết chết toàn bộ.
Cái gì tiếp theo? Khi chúng ta nói về hiệu suất của cơ sở dữ liệu và dần dần chuyển sang đĩa, mọi người bắt đầu bối rối. Bởi vì sự thật là đĩa chậm, bộ nhớ nhanh đã quen thuộc với mọi người từ thuở còn thơ ấu. Và mọi người đều biết rằng cơ sở dữ liệu sẽ gặp vấn đề về hiệu suất ổ đĩa.
Vấn đề chính về hiệu suất của PostgreSQL liên quan đến điểm kiểm tra tăng đột biến không xảy ra do ổ đĩa chậm. Điều này rất có thể là do băng thông bộ nhớ và đĩa không được cân bằng. Tuy nhiên, chúng có thể không được cân bằng ở những nơi khác nhau. PostgreSQL không được cấu hình, hệ điều hành không được cấu hình, phần cứng không được cấu hình và phần cứng không chính xác. Và vấn đề này không chỉ xảy ra nếu mọi thứ diễn ra như bình thường, tức là không có tải hoặc cài đặt và phần cứng được chọn tốt.
Nó là gì và nó trông như thế nào? Thông thường những người làm việc với PostgreSQL đã nhiều lần quan tâm đến vấn đề này. Tôi sẽ giải thích. Như tôi đã nói, PostgreSQL định kỳ tạo các điểm kiểm tra để chuyển các trang bẩn trong bộ nhớ dùng chung vào đĩa. Nếu chúng ta có một lượng lớn bộ nhớ dùng chung thì điểm kiểm tra sẽ bắt đầu có tác động mạnh mẽ đến đĩa vì nó sẽ loại bỏ các trang này bằng fsync. Nó đến bộ đệm kernel và được ghi vào đĩa bằng fsync. Và nếu khối lượng hoạt động kinh doanh này lớn, thì chúng ta có thể quan sát thấy một hiệu ứng khó chịu, đó là việc sử dụng đĩa rất lớn.
Ở đây tôi có hai bức ảnh. Bây giờ tôi sẽ giải thích nó là gì. Đây là hai đồ thị tương quan thời gian. Biểu đồ đầu tiên là việc sử dụng đĩa. Ở đây nó đạt gần 90% vào thời điểm này. Nếu bạn gặp lỗi cơ sở dữ liệu với các ổ đĩa vật lý, với mức sử dụng bộ điều khiển RAID ở mức 90% thì đây là tin xấu. Điều này có nghĩa là thêm một chút nữa nó sẽ đạt tới 100 và I/O sẽ dừng lại.
Nếu bạn có một mảng đĩa thì đó lại là một câu chuyện hơi khác. Nó phụ thuộc vào cách nó được cấu hình, nó là loại mảng gì, v.v.
Và song song, một biểu đồ từ chế độ xem postgres nội bộ được định cấu hình ở đây, biểu đồ này cho biết điểm kiểm tra diễn ra như thế nào. Và màu xanh ở đây cho biết có bao nhiêu bộ đệm, những trang bẩn này, tại thời điểm đó đã đến điểm kiểm tra này để đồng bộ hóa. Và đây là điều chính bạn cần biết ở đây. Chúng ta thấy ở đây có rất nhiều trang và có lúc chúng ta đánh lên bảng, tức là chúng ta viết và viết, ở đây hệ thống đĩa rõ ràng là rất bận. Và trạm kiểm soát của chúng tôi có tác động rất mạnh đến đĩa. Lý tưởng nhất là tình huống sẽ giống thế này hơn, tức là chúng ta có ít bản ghi hơn ở đây. Và chúng ta có thể khắc phục bằng cách cài đặt để nó tiếp tục như thế này. Nghĩa là, việc tái chế là nhỏ, nhưng ở đâu đó chúng ta đang viết điều gì đó ở đây.
Cần phải làm gì để khắc phục vấn đề này? Nếu bạn đã dừng IO trong cơ sở dữ liệu, điều này có nghĩa là tất cả người dùng đến thực hiện yêu cầu của họ sẽ chờ.
Nếu nhìn từ góc độ Linux, nếu bạn lấy phần cứng tốt, cấu hình đúng, cấu hình PostgreSQL bình thường để nó ít tạo ra các điểm kiểm tra này hơn, dàn trải chúng theo thời gian với nhau, thì bạn bước vào các tham số mặc định của Debian. Đối với hầu hết các bản phân phối Linux, đây là hình ảnh: vm.dirty_ratio=20, vm.dirty_background_ratio=10.
Nó có nghĩa là gì? Một con quỷ đỏ bừng xuất hiện từ kernel 2.6. Pdglush, tùy thuộc vào ai đang sử dụng cái nào, tham gia vào việc loại bỏ nền các trang bẩn khỏi bộ đệm kernel và loại bỏ khi cần loại bỏ các trang bẩn bất kể thế nào, khi việc loại bỏ backgroind không giúp ích gì.
Khi nào thì nền đến? Khi 10% tổng RAM khả dụng trên máy chủ bị chiếm bởi các trang bẩn trong bộ đệm kernel, một chức năng xóa đặc biệt sẽ được gọi ở chế độ nền. Tại sao lại là nền? Là một tham số, nó tính đến số trang cần xóa. Và giả sử anh ấy viết được N trang. Và trong một thời gian thứ này chìm vào giấc ngủ. Và sau đó cô ấy lại đến và sao chép thêm một số trang nữa.
Đây là một câu chuyện cực kỳ đơn giản. Vấn đề ở đây giống như một bể bơi, khi đổ vào đường ống này thì nó lại chảy sang đường ống khác. Điểm kiểm tra của chúng tôi đã đến và nếu nó gửi một vài trang bẩn để loại bỏ, thì dần dần toàn bộ vấn đề sẽ được giải quyết gọn gàng từ bộ đệm kernel pgflush.
Nếu những trang bẩn này tiếp tục tích tụ, chúng sẽ tích lũy tới 20%, sau đó ưu tiên của HĐH là ghi toàn bộ nội dung vào đĩa, vì mất điện và mọi thứ sẽ trở nên tồi tệ đối với chúng ta. Chúng tôi sẽ mất dữ liệu này, ví dụ.
Bí quyết là gì? Bí quyết là những thông số này trong thế giới hiện đại chiếm 20 và 10% tổng RAM trên máy, chúng hoàn toàn khủng khiếp về mặt thông lượng của bất kỳ hệ thống đĩa nào bạn có.
Hãy tưởng tượng bạn có 128 GB RAM. 12,8 GB sẽ đến trong hệ thống đĩa của bạn. Và cho dù bạn có bộ đệm nào ở đó, bất kể bạn có mảng nào ở đó, chúng sẽ không tồn tại lâu như vậy.
Do đó, chúng tôi khuyên bạn nên điều chỉnh ngay những con số này dựa trên khả năng của bộ điều khiển RAID của bạn. Tôi ngay lập tức đưa ra đề xuất ở đây về bộ điều khiển có bộ nhớ đệm 512 MB.
Mọi thứ được coi là rất đơn giản. Bạn có thể đặt vm.dirty_background theo byte. Và các cài đặt này hủy bỏ hai cài đặt trước đó. Theo mặc định, tỷ lệ này hoặc tỷ lệ có byte được kích hoạt thì tỷ lệ có byte sẽ hoạt động. Nhưng vì tôi là nhà tư vấn DBA và làm việc với nhiều khách hàng khác nhau nên tôi cố gắng rút ra các ống hút và do đó, nếu tính bằng byte thì tính bằng byte. Không ai đưa ra bất kỳ lời đảm bảo nào rằng một quản trị viên giỏi sẽ không bổ sung thêm bộ nhớ vào máy chủ, khởi động lại nó và con số vẫn như cũ. Chỉ cần tính toán những con số này để mọi thứ phù hợp với sự đảm bảo.
Điều gì xảy ra nếu bạn không phù hợp? Tôi đã viết rằng mọi hoạt động xả nước đều được ngăn chặn một cách hiệu quả, nhưng thực tế đây chỉ là một cách nói tu từ. Hệ điều hành có một vấn đề lớn - nó có rất nhiều trang bẩn, do đó IO mà khách hàng của bạn tạo ra đã bị dừng thực sự, tức là ứng dụng đã gửi truy vấn sql đến cơ sở dữ liệu, nó đang chờ. Bất kỳ đầu vào/đầu ra nào của nó đều có mức ưu tiên thấp nhất vì cơ sở dữ liệu bị chiếm giữ bởi một điểm kiểm tra. Và khi nào cô ấy sẽ hoàn thành thì hoàn toàn không rõ ràng. Và khi bạn đã đạt được tính năng xóa không nền, điều đó có nghĩa là tất cả IO của bạn đã bị nó chiếm giữ. Và cho đến khi nó kết thúc, bạn sẽ không làm gì cả.
Có hai điểm quan trọng hơn ở đây nằm ngoài phạm vi của báo cáo này. Các cài đặt này phải khớp với cài đặt trong postgresql.conf, tức là cài đặt điểm kiểm tra. Và hệ thống đĩa của bạn phải được cấu hình đầy đủ. Nếu bạn có bộ đệm trên RAID thì nó phải có pin. Người ta mua RAID có bộ nhớ đệm tốt mà không cần pin. Nếu bạn có ổ SSD trong RAID thì chúng phải là ổ SSD của máy chủ, phải có tụ điện ở đó. Dưới đây là danh sách kiểm tra chi tiết. Liên kết này chứa báo cáo của tôi về cách định cấu hình đĩa hiệu suất trong PostgreSQL. Có tất cả những danh sách kiểm tra ở đó.
Điều gì khác có thể khiến cuộc sống trở nên khó khăn? Đây là hai tham số. Chúng tương đối mới. Theo mặc định, chúng có thể được đưa vào các ứng dụng khác nhau. Và chúng có thể khiến cuộc sống trở nên khó khăn nếu chúng được bật không đúng cách.
Có hai điều tương đối mới. Chúng đã xuất hiện ở lõi thứ ba. Đây là sched_migration_cost tính bằng nano giây và sched_autogroup_enabled, theo mặc định là một.
Và họ hủy hoại cuộc sống của bạn như thế nào? sched_migration_cost là gì? Trên Linux, bộ lập lịch có thể di chuyển một tiến trình từ CPU này sang CPU khác. Và đối với PostgreSQL thực thi các truy vấn, việc di chuyển sang CPU khác là hoàn toàn không rõ ràng. Từ quan điểm của hệ điều hành, khi bạn chuyển đổi các cửa sổ giữa openoffice và terminal, điều này có thể tốt, nhưng đối với cơ sở dữ liệu thì điều này rất tệ. Do đó, một chính sách hợp lý là đặt Migration_cost thành một giá trị lớn nào đó, ít nhất là vài nghìn nano giây.
Điều này có ý nghĩa gì đối với người lập lịch trình? Nó sẽ được coi là trong thời gian này quá trình vẫn còn nóng. Nghĩa là, nếu bạn có một giao dịch dài hạn và đã làm một việc gì đó trong một thời gian dài thì người lên lịch sẽ hiểu điều này. Anh ta sẽ cho rằng cho đến khi hết thời gian chờ này, không cần phải di chuyển quá trình này đi bất cứ đâu. Nếu đồng thời quá trình thực hiện điều gì đó, thì nó sẽ không được di chuyển đi đâu cả, nó sẽ lặng lẽ hoạt động trên CPU được phân bổ cho nó. Và kết quả là tuyệt vời.
Điểm thứ hai là autogroup. Có một ý tưởng hay cho các khối lượng công việc cụ thể không liên quan đến cơ sở dữ liệu hiện đại - đây là nhóm các quy trình theo thiết bị đầu cuối ảo mà từ đó chúng được khởi chạy. Điều này thuận tiện cho một số nhiệm vụ. Trong thực tế, PostgreSQL là một hệ thống đa quy trình với một prefork chạy từ một thiết bị đầu cuối duy nhất. Bạn có trình ghi khóa, điểm kiểm tra và tất cả các yêu cầu máy khách của bạn sẽ được nhóm thành một bộ lập lịch cho mỗi CPU. Và họ sẽ đồng loạt chờ đợi anh ta được tự do ở đó, nhằm can thiệp lẫn nhau và khiến anh ta bận rộn lâu hơn. Đây là một câu chuyện hoàn toàn không cần thiết trong trường hợp tải như vậy và do đó cần phải tắt nó đi.
Đồng nghiệp của tôi Alexey Lesovsky đã thực hiện các thử nghiệm với một pgbench đơn giản, trong đó anh ấy đã tăng Migration_cost lên một bậc độ lớn và tắt tính năng tự động nhóm. Sự khác biệt trên phần cứng xấu là gần 10%. Có một cuộc thảo luận trên danh sách gửi thư postgres nơi mọi người đưa ra kết quả về những thay đổi tương tự đối với tốc độ truy vấn ảnh hưởng 50%. Có khá nhiều câu chuyện như vậy.
Và cuối cùng là về chính sách tiết kiệm điện. Điều đáng mừng là giờ đây Linux có thể được sử dụng trên máy tính xách tay. Và nó được cho là sẽ sử dụng tốt pin. Nhưng đột nhiên hóa ra điều này cũng có thể xảy ra trên máy chủ.
Hơn nữa, nếu bạn thuê máy chủ từ một số nhà cung cấp dịch vụ lưu trữ, thì những nhà cung cấp dịch vụ lưu trữ “tốt” đó sẽ không quan tâm đến việc bạn có hiệu suất tốt hơn hay không. Nhiệm vụ của họ là đảm bảo rằng bàn ủi của họ được sử dụng hiệu quả nhất có thể. Vì vậy, mặc định họ có thể kích hoạt chế độ tiết kiệm điện năng laptop trên hệ điều hành.
Nếu bạn sử dụng nội dung này trên máy chủ có cơ sở dữ liệu đang tải nặng thì lựa chọn của bạn là acpi_cpufreq + permormance. Ngay cả với ondemand cũng sẽ có vấn đề.
Intel_pstate là một trình điều khiển hơi khác. Và bây giờ ưu tiên cho cái này, vì nó ra đời muộn hơn và hoạt động tốt hơn.
Và, theo đó, thống đốc chỉ mang tính biểu diễn. Theo yêu cầu, powersave và mọi thứ khác không phải về bạn.
Kết quả phân tích giải thích PostgreSQL có thể khác nhau theo một số bậc độ lớn nếu bạn bật tiết kiệm năng lượng, vì trên thực tế, CPU trong cơ sở dữ liệu của bạn sẽ chạy theo cách hoàn toàn không thể đoán trước.
Những mục này có thể được bao gồm theo mặc định. Hãy xem kỹ xem họ có bật nó theo mặc định hay không. Đây có thể là một vấn đề thực sự lớn.
Và cuối cùng, tôi muốn gửi lời cảm ơn đến những người trong nhóm DBA Tư vấn PosgreSQL của chúng tôi, cụ thể là Max Boguk và Alexey Lesovsky, những người đang tiến bộ trong vấn đề này mỗi ngày. Và chúng tôi cố gắng làm những điều tốt nhất có thể cho khách hàng của mình để mọi việc đều có lợi cho họ. Nó giống như hướng dẫn an toàn hàng không. Mọi thứ ở đây đều được viết bằng máu. Mỗi loại hạt này được tìm thấy trong quá trình giải quyết một số loại vấn đề. Tôi rất vui được chia sẻ chúng với bạn.
câu hỏi:
Cảm ơn! Ví dụ: nếu một công ty muốn tiết kiệm tiền và đặt cơ sở dữ liệu cũng như logic ứng dụng trên một máy chủ hoặc nếu công ty đó đi theo xu hướng thời thượng về kiến trúc vi dịch vụ, trong đó PostgreSQL chạy trong một thùng chứa. Bí quyết là gì? Sysctl sẽ ảnh hưởng đến toàn bộ kernel trên toàn cầu. Tôi chưa nghe nói về việc sysctls được ảo hóa bằng cách nào đó để chúng hoạt động riêng biệt trên một vùng chứa. Chỉ có một cgroup và chỉ có một phần quyền kiểm soát ở đó. Làm thế nào bạn có thể sống với điều này? Hoặc nếu bạn muốn hiệu năng thì hãy chạy PostgreSQL trên một máy chủ phần cứng riêng biệt và điều chỉnh nó?
Chúng tôi đã trả lời câu hỏi của bạn theo khoảng ba cách. Nếu chúng ta không nói về một máy chủ phần cứng có thể điều chỉnh, v.v., thì hãy thư giãn, mọi thứ sẽ hoạt động tốt nếu không có những cài đặt này. Nếu bạn có khối lượng công việc lớn đến mức cần thực hiện các cài đặt này, thì bạn sẽ đến máy chủ sắt sớm hơn các cài đặt này.
Vấn đề là gì? Nếu đây là một máy ảo thì rất có thể bạn sẽ gặp nhiều vấn đề, chẳng hạn như trên hầu hết các máy ảo, độ trễ của đĩa khá không nhất quán. Ngay cả khi thông lượng ổ đĩa tốt, thì một giao dịch I/O không thành công không ảnh hưởng nhiều đến thông lượng trung bình xảy ra tại thời điểm điểm kiểm tra hoặc tại thời điểm ghi vào WAL, thì cơ sở dữ liệu sẽ bị ảnh hưởng nặng nề từ điều này. Và bạn sẽ nhận thấy điều này trước khi gặp phải những vấn đề này.
Nếu bạn có NGINX trên cùng một máy chủ, bạn cũng sẽ gặp vấn đề tương tự. Anh ấy sẽ chiến đấu vì ký ức chung. Và bạn sẽ không gặp phải những vấn đề được mô tả ở đây.
Nhưng mặt khác, một số thông số này vẫn sẽ phù hợp với bạn. Ví dụ: đặt dirty_ratio với sysctl để nó không quá điên rồ - trong mọi trường hợp, điều này sẽ hữu ích. Bằng cách này hay cách khác, bạn sẽ có sự tương tác với đĩa. Và nó sẽ theo mô hình sai. Đây thường là mặc định cho các tham số mà tôi đã hiển thị. Và trong mọi trường hợp, tốt hơn là thay đổi chúng.
Nhưng có thể có vấn đề với NUMA. Ví dụ: VmWare hoạt động tốt với NUMA với các cài đặt hoàn toàn ngược lại. Và ở đây bạn phải chọn - máy chủ sắt hoặc máy chủ không sắt.
Tôi có một câu hỏi liên quan đến Amazon AWS. Họ có hình ảnh được cấu hình sẵn. Một trong số đó được gọi là Amazon RDS. Có bất kỳ cài đặt tùy chỉnh nào cho hệ điều hành của họ không?
Có những cài đặt ở đó, nhưng chúng là những cài đặt khác nhau. Ở đây chúng tôi định cấu hình hệ điều hành về cách cơ sở dữ liệu sẽ sử dụng thứ này. Và có những thông số quyết định nơi chúng ta nên đi bây giờ, chẳng hạn như việc định hình. Tức là chúng ta cần rất nhiều tài nguyên, bây giờ chúng ta sẽ ăn hết chúng. Sau đó, Amazon RDS thắt chặt các tài nguyên này và hiệu suất sẽ giảm ở đó. Có những câu chuyện riêng lẻ về việc mọi người bắt đầu gặp rắc rối với vấn đề này. Đôi khi thậm chí khá thành công. Nhưng điều này không liên quan gì đến cài đặt hệ điều hành. Nó giống như hack đám mây vậy. Đó là một câu chuyện khác.
Tại sao các trang lớn trong suốt không có tác dụng gì so với TLB lớn?
Đưng đưa. Điều này có thể được giải thích theo nhiều cách. Nhưng trên thực tế, họ chỉ đơn giản là không cho nó. Lịch sử của PostgreSQL là gì? Khi khởi động, nó phân bổ một phần lớn bộ nhớ dùng chung. Việc chúng có minh bạch hay không là hoàn toàn không liên quan. Việc họ nổi bật ngay từ đầu đã giải thích mọi thứ. Và nếu có nhiều bộ nhớ và bạn cần xây dựng lại phân đoạn Shared_memory thì các trang lớn trong suốt sẽ phù hợp. Trong PostgreSQL, ngay từ đầu nó chỉ được phân bổ thành một phần lớn và thế là xong, sau đó không có gì đặc biệt xảy ra ở đó. Tất nhiên, bạn có thể sử dụng nó, nhưng có khả năng bị hỏng Shared_memory khi nó phân bổ lại thứ gì đó. PostgreSQL không biết về điều này.
Nguồn: www.habr.com