quá nhiều kết nối db lỗi trong bộ nhớ cache cập nhật

[krisp]

Đêm khác tôi đã xảy ra để được tỉnh táo một chút sau khi 4 vào buổi sáng, nơi diễn đàn đột nhiên giống như 20 phút:


Cơ sở dữ liệu lỗi trong vBulletin:

mysqli_real_connect () [<a href='function.mysqli-real-connect'> function.mysqli-thực sự kết nối </ a>]: (08004/1040): Quá nhiều kết nối
/ Var / www / vhosts / ... / httpdocs / includes / class_core.php on line 1138

MySQL Lỗi:
Error Number:
Yêu cầu ngày: Thứ ba, Tháng Mười Hai lần thứ 15 2009 04:28:00
Lỗi ngày: Thứ ba, Tháng Mười Hai lần thứ 15 2009 04:28:00
Script: http://.../
Giới thiệu:
Địa chỉ IP:
Tên người dùng:
Classname: vB_Database_MySQLi
MySQL Version:
-->

Bây giờ, tôi không bao giờ có kinh nghiệm này trước đây, và tôi tự hỏi, nếu nó là một sự trùng hợp ngẫu nhiên, rằng đây là xung quanh cập nhật bộ nhớ cache vb trong nhiệm vụ theo lịch trình.

Tôi đã kiểm tra sáng nay và tất cả mọi thứ đã được ok, vì vậy nó đã không lặp lại ngày hôm nay.

Các máy chủ dường như không được nhấn mạnh, kể từ khi tôi đã có một diễn đàn trên cùng một máy chủ mà không có vbet, đã được chạy tốt trong thời gian chết của diễn đàn vbet của tôi.

Nhìn ở serverlog đã dường như có một số hoạt động bot, nhưng không nhiều hoạt động người dùng. Các chương trình dường như để có được OK 200 - nhưng người dùng bình thường có dberror. Ngoài ra kỳ lạ các hồ sơ trong logfile máy chủ dường như không được sắp xếp theo thứ tự thời gian ...

Một chút của puzzele một ... có lẽ bạn có thể cho tôi biết nếu bao gồm / class_core.php on line 1138 là tham gia trong việc cập nhật bộ nhớ cache? Hoặc có lẽ một số các bạn có một ý tưởng làm thế nào để khắc phục sự cố này?

[vBET]

vBET không tạo ra các kết nối mới - nó có thể thiết lập lại kết nối nhưng điều này được thực hiện chỉ khi có trên thực tế bị mất (trong trường hợp nếu bản dịch đã đến quá muộn từ Google). Và kết nối này được thực hiện bởi $ vbulletin-> db-> kết nối vBulletin thực hiện tất cả thanh toán bù trừ cần thiết ở cuối.

Vì vậy, tại thời điểm này chúng tôi nghĩ rằng vấn đề là ở một nơi khác.

class_core.php là không phải là tập tin của chúng tôi và nó không sử dụng bộ nhớ cache trực tiếp vBET - nhưng nếu tập tin này là chịu trách nhiệm về thực hiện nhiệm vụ theo lịch trình, sau đó nó cũng sẽ thực hiện thanh toán bù trừ bộ nhớ cache.

[vBET]

Một điều nữa. Nếu bạn đang viết về thanh toán bù trừ bộ nhớ cache vBET, sau đó xin vui lòng chết tiệt có bao nhiêu dữ liệu mà bạn có trong bộ nhớ cache. Nếu nó thực sự là số lượng lớn, sau đó xin vui lòng thay đổi chiến lược xoá bộ nhớ cache của bạn.
vBET không tạo các kết nối bổ sung, nhưng nếu thanh toán bù trừ mất quá nhiều thời gian, sau đó các khách hàng khác đang chờ đợi và các kết nối mới được tạo ra bởi vB cho các khách hàng mới, trong đó bệnh chờ đợi. đây là lý do tại sao chúng ta thêm một số chiến lược thanh toán bù trừ. Đối với số tiền thực sự lớn của dữ liệu, hãy sử dụng chiến lược cuối cùng.

Xin lưu ý rằng vấn đề này sẽ được giảm thiểu trong 3.3.0 kể từ khi chúng tôi sẽ chia bảng bộ nhớ cache cho mỗi ngôn ngữ, do đó, chỉ số của bạn sẽ được 52 lần nhỏ hơn và thanh toán bù trừ sẽ được nhanh hơn nhiều - xóa dữ liệu là nhanh chóng, nhưng cập nhật các chỉ số lớn không cần thiết. Vì vậy, tại thời điểm này, xin vui lòng xem xét việc sử dụng các chiến lược thanh toán bù trừ khác, đó là tốt hơn cho các chỉ số lớn:)

[krisp]

Happend lại từ 04-05 - tất cả các lĩnh vực với các kết nối quá nhiều. Tôi nghĩ rằng bạn là đúng. Diễn đàn là bận rộn thanh toán bù trừ bộ nhớ cache và các chương trình tìm kiếm giả mạo với một yêu cầu mỗi giây. Tôi có thể thấy serverload rất cao. Bây giờ nó là rất thấp. vbet db khoảng 1,1 GB

Tôi đã chuyển đến "Xóa tất cả các dữ liệu bộ nhớ cache một lần cho khoảng thời gian bộ nhớ cache TTL".

Âm thanh thực sự rất tốt 330 địa chỉ vấn đề này!