Danh sách quy trình MySQL Ngủ

Thường thì bạn không cần, nhưng khi bạn muốn xem truy vấn nào mà máy chủ MySQL của bạn hiện cần xử lý (và nếu có khóa, v.v.), bạn có thể nói SHOW PROCESSLIST trong trình bao MySQL

Nhóm phát triển của bạn có đầy đủ hồ sơ tồn đọng?

• Chúng tôi xây dựng các giải pháp đám mây đáng tin cậy với Cơ sở hạ tầng dưới dạng mã
• Chúng tôi là chuyên gia về bảo mật, Linux và cơ sở dữ liệu
• Chúng tôi hỗ trợ nhóm nhà phát triển của bạn thực hiện

Thật không may, SHOW PROCESSLIST không cho phép lọc. Khi bạn đang sử dụng MySQL ≥ 5. 1. 7, làm điều này thay vì

SELECT * FROM information_schema.processlist WHERE command != 'Sleep' ORDER BY id;

Điều đó cũng cho phép bạn chỉ hiển thị một số giá trị hoặc sắp xếp khác nhau, như vậy

SELECT user, time, state, info FROM information_schema.processlist WHERE command != 'Sleep' ORDER BY time DESC, id;

Một ví dụ khác -- xem tất cả các truy vấn không ngủ mất một chút thời gian, ví dụ: ít nhất 2 giây

SELECT user, time, state, info FROM information_schema.processlist WHERE command != 'Sleep' AND time >= 2 ORDER BY time DESC, id;

Gợi ý

Khi kiểm tra danh sách quy trình trong trình bao mysql, bố cục dọc thường hữu ích hơn. Sử dụng \G thay vì ;

Khi máy chủ Mysql của bạn gặp sự cố và bạn cần xác định các SQL có hiệu suất kém nhất, điều đầu tiên mà mọi quản trị viên máy chủ đang làm là mở bảng điều khiển mysql và bắt đầu đào trong SHOW PROCESSLIST hoặc SHOW FULL PROCESSLIST

Trên các máy chủ có nhiều kết nối đồng thời tới nhiều cơ sở dữ liệu, bạn sẽ thấy rất nhiều hàng có các lệnh có văn bản. Ngủ

Trong thời gian khi tôi đang tìm kiếm các sqls chậm, tôi không muốn bị làm phiền với các kết nối đang ngủ đó và tôi chỉ muốn xem các SQL gây rắc rối thực sự

Giải pháp cho tôi trên các phiên bản Mysql mới hơn là không sử dụng lệnh SHOW PROCESSLIST, nhưng SQL tải dữ liệu từ lược đồ thông tin

@runtime - Bài đăng trên blog này từ Percona có một vài gợi ý về lý do tại sao các quy trình ngủ này đang được tạo. Một số nguyên nhân phổ biến là sự cố hết thời gian chờ với máy chủ web của bạn, các truy vấn đang chạy trong thời gian dài hoặc nhiều kết nối đang chờ truy vấn hoàn tất. Cũng có thể các ứng dụng truy vấn MySQL chỉ tạo nhiều kết nối theo mặc định, như đã đề cập tại đây. Tôi đặc biệt muốn thu hút sự chú ý đến dòng này. "trừ khi ứng dụng của bạn là một ứng dụng rất bận rộn, điều bình thường là hầu như không phải mọi quy trình SQL đều có việc phải làm, vì vậy chúng ngủ. " Tùy thuộc vào số lượng quy trình đang ngủ mà bạn thấy, điều đó có thể là bình thường và không ảnh hưởng đến hiệu suất. Tuy nhiên, nếu có hàng nghìn, bạn sẽ muốn kiểm tra cấu hình của mình và điều tra thêm

Bạn đã bao giờ thấy một kết nối trong đầu ra SHOW PROCESSLIST ở trạng thái "Ngủ" trong một thời gian dài và bạn không biết tại sao điều này lại xảy ra?

MySQL ngủ

Tôi thấy nếu thường xuyên với các ứng dụng web và đó thường là dấu hiệu của sự cố. Điều đó không chỉ có nghĩa là bạn có thể hết kết nối MySQL nhanh hơn dự kiến ​​mà còn thường xuyên chỉ ra các sự cố nghiêm trọng trong ứng dụng. Nếu bạn không sử dụng các kết nối liên tục và bạn có kết nối ở chế độ Ngủ trong 600 giây thì đó có thể là gì? . Hoặc có thể bạn có một số kết nối với máy chủ MySQL và hiện đang chạy truy vấn mất nhiều thời gian như vậy?

Nhiệm vụ đầu tiên là tìm xem kết nối thuộc về tiến trình nào. Sử dụng các tên người dùng khác nhau cho các ứng dụng khác nhau là một cách thực hành tốt, tuy nhiên, nó sẽ không cho bạn biết con apache nào đang xử lý yêu cầu được đề cập. Nếu bạn chỉ muốn sửa nó, tức là bằng cách khởi động lại apache thì thế là đủ nhưng nếu bạn muốn tìm hiểu tại sao nó lại xảy ra, bạn cần thêm thông tin

Bạn có thể nhận thấy trong tệp “Máy chủ” của đầu ra SHOW PROCESSLIST không chỉ máy chủ mà còn cả cổng được chỉ định, hiển thị cho bạn thông tin như “192. 168. 1. 70. 58555” Cổng này có thể được sử dụng để xác định quá trình sở hữu kết nối được đề cập

1

2

[root@w1 ~]# netstat -ntp | grep :45384

tcp        0      0 192.168.1.70. 45384          192. 168. 1. 82. 3306           ĐÃ THÀNH LẬP 28540 /< php-cgi

Như bạn có thể thấy trong trường hợp này, chúng ta có thể thấy php-cgi đang giữ kết nối được đề cập (đây là hệ thống dựa trên lighttpd với fastcgi)

Bây giờ bạn đã biết quy trình và bạn có thể sử dụng các công cụ yêu thích của mình để kiểm tra xem quy trình đó đang làm gì

1

2

3

4

5

6

7

8

[root@w1 ~]# netstat -ntp | grep 28540

tcp        0      0 192.168.1.70. 58555          192. 168. 1. 90. 11211          ĐÃ THÀNH LẬP 28540 /< php-cgi

tcp        0      0 192.168.1.70. 52711          192. 168. 1. 88. 8080           ĐÃ THÀNH LẬP 28540 /< php-cgi

tcp        0      0 192.168.1.70. 45384          192. 168. 1. 82. 3306           ĐÃ THÀNH LẬP 28540 /< php-cgi

tcp        0      0 192.168.1.70. 45399          192. 168. 1. 82. 3306           ĐÃ THÀNH LẬP 28540 /< php-cgi

tcp        0      0 192.168.1.70. 45407          192. 168. 1. 82. 3306           ĐÃ THÀNH LẬP 28540 /< php-cgi

tcp        0      0 192.168.1.70. 45408          192. 168. 1. 82. 3306           ĐÃ THÀNH LẬP 28540 /< php-cgi

tcp        0      0 192.168.1.70. 35556          192. 168. 1. 92. 11211          ĐÃ THÀNH LẬP 28540 /< php-cgi

Sử dụng cùng một lệnh netstat và lọc trên PID, chúng ta có thể tìm thấy quá trình này có những kết nối nào. Ở đây bạn có thể thấy nó có vài kết nối memcached. Ít kết nối MySQL (với cùng một máy chủ, nếu thường là ý tưởng tồi) và kết nối với một số máy chủ web bên ngoài

Bạn có thể sử dụng strace -p để xem máy chủ đang làm gì, nó thường đưa ra manh mối. Trong trường hợp này, ví dụ, tôi đã tìm thấy quy trình bị kẹt trong cuộc gọi hệ thống pool() đọc từ mạng. Sử dụng netstat có thể cho bạn biết nó có thể là gì nhưng nếu bạn không thích đoán, bạn có thể sử dụng gdb -p. Nó sẽ không in dòng mã chính xác của bạn trong PHP đang chạy nhưng có thể cung cấp cho bạn một số ý tưởng hay – ví dụ như trong trường hợp này, tôi có thể tìm thấy dấu vết ngăn xếp có nguồn gốc từ các hàm luồng php chứ không phải từ libmysql hoặc memcache. vì vậy, điều đó có nghĩa là không phải kết nối MySQL hoặc memcache khiến ứng cử viên cuối cùng là lựa chọn duy nhất. Tôi cũng có thể thấy một số biến trong đầu ra lệnh GDB “bt” cũng gợi ý vấn đề có thể là gì

Nhân tiện, có ai biết bất kỳ trình gỡ lỗi nào có thể kết nối với tiến trình PHP hoặc apache với mod_php và cung cấp backtrace theo thuật ngữ PHP không phải trình gỡ lỗi cho công cụ zend không?

Một công cụ tuyệt vời khác mà bạn có thể sử dụng là server-status nếu bạn đang chạy apache. Bằng cách này, bạn sẽ thấy URL mà quy trình đó đang xử lý và do đó, bạn sẽ nhận được thêm một số gợi ý về những gì có thể đang xảy ra hoặc thậm chí nhận được ví dụ có thể lặp lại trong một số trường hợp

Các công cụ tôi đã đề cập liên quan đến việc tìm hiểu những gì đang xảy ra với quy trình của chúng tôi không chỉ hữu ích để gỡ lỗi các kết nối đang ngủ với MySQL mà còn nhiều trường hợp khác khi bạn thấy ứng dụng web bị khóa hoặc bắt đầu chạy trong vòng lặp chặt chẽ tiêu tốn quá nhiều thời gian của CPU

Nếu bạn biết bất kỳ công cụ nào khác có thể hữu ích về vấn đề này sẽ đánh giá cao nhận xét của bạn. Có thể có một số công cụ thông minh hơn để theo dõi quá trình sản xuất

Làm cách nào để kiểm tra kết nối ngủ trong MySQL?

Làm cách nào để tránh truy vấn ngủ trong MySQL?

Làm cách nào để xử lý truy vấn ngủ trong MySQL?

Cột thời gian trong danh sách quy trình hiển thị là gì?