Điểm:1

Tại sao ứng dụng Java Tomcat của chúng tôi đột nhiên mở hàng trăm kết nối đến cơ sở dữ liệu của chúng tôi?

lá cờ it

Chúng tôi có một ứng dụng Tomcat chạy trên Elastic Beanstalk và cơ sở dữ liệu MySQL của chúng tôi được lưu trữ trên AWS RDS (2 hoặc 3 phiên bản t3.medium). Kể từ khi chúng tôi nâng cấp từ MySQL 5 lên MySQL 8 (hiện tại là 8.0.23), chúng tôi đã gặp sự cố xảy ra khoảng một lần một tuần.Hầu hết các cơ sở dữ liệu đều ổn, nhưng sau đó, đột nhiên, số lượng kết nối tăng vọt (thậm chí đôi khi vượt quá giới hạn 307 kết nối trong phạm vi 1 phút, đây cũng là điều chúng tôi không hiểu. nó có khả năng vượt quá giới hạn đó không?) và điều đó khiến các phiên bản Elastic Beanstalk bị xuống cấp. Đôi khi toàn bộ cơ sở dữ liệu gặp sự cố sau khi kết nối đạt đến đỉnh điểm.

Trong khi giám sát JVM của ứng dụng bằng VisualVM, tôi nhận thấy rằng, trong các đỉnh kết nối đó, Tomcat đột nhiên tạo ra hàng tá chuỗi công nhân. Tôi đoán là mỗi một trong những chủ đề đó thiết lập một kết nối mới với cơ sở dữ liệu. Mặc dù chúng tôi có thể giới hạn số lượng luồng đó (xét cho cùng, máy chủ sẽ không thể xử lý nhiều luồng như vậy ngay từ đầu), nhưng chúng tôi muốn hiểu nguyên nhân gây ra điều đó. Tại sao Tomcat tạo ra quá nhiều chủ đề và kết nối đến cơ sở dữ liệu của chúng tôi? Đó là nguyên nhân hay hậu quả của các vấn đề trong cơ sở dữ liệu? Chúng ta nên nhìn vào đâu để tìm ra gốc rễ của vấn đề?

Tôi đã Google rất nhiều, cố gắng tìm những người gặp phải vấn đề tương tự để làm sáng tỏ vấn đề. Chúng tôi cũng đã thử phân tích các truy vấn tốn kém nhất và các thông tin chuyên sâu khác về hiệu suất cơ sở dữ liệu nhưng dường như không có mẫu nào rõ ràng.

Wilson Hauck avatar
lá cờ jp
Liệu sự tăng đột biến rõ ràng trong một thời gian - bao lâu? Làm thế nào để bạn đưa hệ thống của mình hoạt động trở lại?
Helder Sérvio avatar
lá cờ it
@WilsonHauck, khi mức tăng đột biến xảy ra, quá trình kiểm tra tình trạng của bộ cân bằng tải bắt đầu không thành công, điều này khiến Elastic Beanstalk hạ các phiên bản xuống và thay thế chúng, do đó, giải quyết được sự cố.
Điểm:1
lá cờ ua

Chúng ta nên nhìn vào đâu để tìm ra gốc rễ của vấn đề?

  • Kích hoạt tính năng ghi chậm trong MySQL và (sau khi tăng đột biến) điều tra những truy vấn nào đang chạy vào thời điểm đó. Nếu chậm không hiển thị nhiều, thấp hơn long_query_time trước khi tăng đột biến tiếp theo.
  • (Tôi không biết liệu Tomcat có nhật ký hay không.)
  • Nó có xảy ra vào cùng một thời điểm hàng ngày hoặc hàng tuần không?
  • Khi nào Amazon thực hiện sao lưu?
  • Nếu bạn đang trực tuyến khi điều đó xảy ra, hãy xem liệu bạn có thể làm được không HIỂN THỊ DANH SÁCH QUY TRÌNH;. Giữ cho mình được kết nối; có thể khó kết nối khi bạn nhìn thấy mức tăng đột biến.
  • MySQL 'BIẾN' max_connections kiểm soát 307. Việc tăng nó có thể trì hoãn đỉnh tăng đột biến, nhưng lại khiến mọi thứ trở nên tồi tệ hơn. (Tôi không coi đây là một "giải pháp".)
  • Tomcat có thể [có thể] giữ các kết nối dư thừa mà không làm hỏng mọi thứ quá nhiều; có khả năng tốt hơn là điều tiết Tomcat hơn là thay đổi 307. Khi MySQL có "rất nhiều kết nối bận rộn", nó sẽ cấp cho mỗi người quyền truy cập tài nguyên như nhau; điều này có tác dụng làm chậm lại tất cả các kết nối.
Helder Sérvio avatar
lá cờ it
Chúng tôi đã xem xét nhật ký truy vấn chậm và chúng tôi có thể xóa/tái cấu trúc một số truy vấn toàn thời gian tốn kém khi tình hình thực sự nghiêm trọng (DB luôn gặp sự cố), nhưng vẫn không giải thích được tại sao sự cố chỉ bắt đầu xảy ra sau khi chuyển đổi sang MySQL 8. Tomcat có một nhật ký, nhưng chúng tôi chưa lưu trữ nó sau khi các phiên bản bị hủy. Chúng tôi sẽ làm điều đó vào lần tới và xem xét các chủ đề. Và không, nó thay đổi rất nhiều về tần suất và thời gian. Không trùng lặp với các bản sao lưu.
Wilson Hauck avatar
lá cờ jp
@HelderSérvio Vui lòng yêu cầu thêm thông tin. Loại phiên bản AWS - Kích thước RAM, # lõi, Bất kỳ thiết bị SSD hoặc NVME nào trên máy chủ MySQL Host? Đăng trên pastebin.com và chia sẻ các liên kết. Từ thư mục gốc đăng nhập SSH của bạn, Kết quả văn bản của: A) CHỌN COUNT(*) TỪ information_schema.tables; B) HIỂN THỊ TRẠNG THÁI TOÀN CẦU; sau tối thiểu 24 giờ C) HIỂN THỊ BIẾN TOÀN CẦU; D) HIỂN THỊ ĐẦY ĐỦ QUY TRÌNH; E) TÌNH TRẠNG; không HIỂN THỊ TÌNH TRẠNG, chỉ TÌNH TRẠNG; để phân tích điều chỉnh khối lượng công việc của máy chủ nhằm đưa ra đề xuất.
Helder Sérvio avatar
lá cờ it
@WilsonHauck. Các máy chủ là 2-3 phiên bản t4g.small (2 GiB, 2 vCPU), trong khi cơ sở dữ liệu là (một phiên bản duy nhất, tôi đã nhầm khi nói đó là 2-3) phiên bản t3.medium (4 GiB, 2 vCPU), với SSD gp2. Tôi không có quyền truy cập trực tiếp vào cơ sở dữ liệu, vì vậy tôi e rằng tôi không thể hiển thị cho bạn kết quả của những truy vấn đó.Tuy nhiên, ông chủ của tôi đã đưa cho tôi một bảng truy vấn chậm. Về cơ bản, điều xảy ra là, tại một thời điểm nhất định, tất cả các truy vấn bắt đầu chậm hơn (mật độ của các truy vấn chậm tăng lên rất nhiều), cho đến khi một số truy vấn đạt khoảng 2 hoặc 3 phút. Thông tin chi tiết về hiệu suất RDS hiển thị thời gian chờ LOCK_table_cache lâu.
Wilson Hauck avatar
lá cờ jp
@HelderSérvio Bạn có thể đăng thông tin truy vấn chậm do sếp của bạn cung cấp không? Sếp của bạn có thể chạy danh sách ở trên, đăng dữ liệu lên pastebin.com và bạn chia sẻ liên kết với chúng tôi để phân tích khối lượng công việc của phiên bản t3.medium của bạn không?
lá cờ ua
"Mật độ tăng" -- Thông thường, một truy vấn duy nhất sẽ dẫn đến tình trạng đông đúc. `SHOW PROCESSLIST` đôi khi có thể phát hiện ra điều đó, nhưng rất khó để nhận ra điều đó. Slowlog thô đôi khi có thể hiển thị truy vấn nào là truy vấn nghịch ngợm. ("Tiêu hóa" truy vấn sẽ tốt hơn để tìm ra truy vấn nào là gánh nặng nhất cho hệ thống.)

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.