terlalu banyak sambungan db kesilapan semasa cache update

[krisp]

Malam lain yang berlaku dalam keadaan sedar sedikit selepas 4 pada waktu pagi, di mana forum itu tiba-tiba seperti 20 minit:


Kesilapan pangkalan data di vBulletin:

mysqli_real_connect () [<a href='function.mysqli-real-connect'> function.mysqli-real-menyambung </ a>]: (08004/1040): Terlalu sambungan banyak
/ Var / www / vhosts / ... / httpdocs / includes / class_core.php pada 1138 selaras

Ralat MySQL:
Nombor Ralat:
Permintaan Tarikh: Selasa, 15hb Disember 2009 @ 4:28:00 AM
Ralat Tarikh: Selasa, 15hb Disember 2009 @ 4:28:00 AM
Script: http://.../
Perujuk:
IP Address:
Nama pengguna:
Classname: vB_Database_MySQLi
MySQL Version:
-->

Sekarang, saya tidak pernah mengalami ini sebelum ini, dan saya tertanya-tanya, jika ia adalah satu kebetulan, bahawa ini adalah di sekitar update cache VB dalam tugas-tugas yang dijadualkan.

Saya check pagi ini dan semuanya ok, jadi ia tidak mengulangi hari ini.

Pelayan seolah-olah tidak tertekan, kerana saya mempunyai satu lagi forum di pelayan yang sama tanpa vbet, yang berfungsi baik semasa downtime forum vbet saya.

Di serverlog, tidak kelihatan untuk beberapa aktiviti bot, tetapi pengguna tidak banyak aktiviti. Bot seolah-olah untuk mendapatkan OK 200 - tetapi pengguna biasa mendapat dberror. Juga pelik rekod dalam fail log pelayan seolah-olah tidak boleh disusun secara kronologi ...

Sedikit puzzele satu ... mungkin anda boleh beritahu saya jika termasuk / class_core.php pada 1138 selaras terlibat dalam mengemaskini cache? Atau mungkin ada di antara kamu mempunyai idea bagaimana untuk menyelesaikan masalah ini?

[vBET]

vBET tidak membuat sambungan baru - ia dapat membina dan mencipta sambungan tetapi ini dibuat hanya jika salah satu sebenar hilang (dalam kes jika terjemahan datang terlambat dari Google). Dan sambungan ini dibuat oleh $ vBulletin-> db-> menyambung vBulletin membuat semua penjelasan yang perlu pada akhir.

Jadi, pada masa ini, kita berfikir bahawa isu itu di tempat lain.

class_core.php tidak fail kami dan ia tidak menggunakan cache secara langsung vBET - tetapi jika fail ini bertanggungjawab untuk melaksanakan tugas yang dijadualkan, maka ia juga akan melaksanakan mengosongkan cache.

[vBET]

Satu perkara lagi. Jika anda menulis mengenai mengosongkan cache vBET, kemudian sila palang pintu berapa banyak data yang anda ada dalam cache. Jika ia benar-benar jumlah yang besar, maka sila menukar strategi mengosongkan cache anda.
vBET tidak membuat sambungan tambahan, tetapi jika penjelasan mengambil masa terlalu panjang, maka pelanggan lain sedang menunggu dan sambungan baru yang dicipta oleh VB untuk pelanggan baru, yang sakit menunggu. ini adalah mengapa kita menambah beberapa strategi penjelasan. Untuk jumlah yang benar-benar besar data, sila menggunakan strategi terakhir.

Sila ambil perhatian bahawa isu ini akan dikurangkan di 3.3.0 kerana kita akan berpecah jadual cache untuk setiap bahasa, jadi indeks anda akan menjadi 52 kali lebih kecil dan penjelasan akan lebih cepat - memotong data pantas, tetapi mengemas kini indeks yang besar tidak perlu. Jadi, pada masa ini, sila mempertimbangkan penggunaan strategi penjelasan lain, yang lebih baik bagi indeks yang besar:)

[krisp]

Berlaku lagi 04-05 - semua domain dengan sambungan yang terlalu banyak. Saya rasa anda betul. Forum adalah sibuk membersihkan cache dan bots carian menyalahgunakan satu permintaan per saat. Saya dapat melihat serverload sangat tinggi. Kini ia sangat rendah sekali lagi. vbet db kira-kira 1,1 GB

Saya telah bertukar ke "Padam semua data cache sekali untuk selang TTL cache".

Bunyi yang sangat baik sekali 330 alamat masalah ini!