GTA Közösség - A magyar GTA fórum
San Andreas Multiplayer (SA-MP) => SA-MP: Szerverfejlesztés => Segítségkérés => A témát indította: ColdFly - 2011. December 05. - 20:06:48
-
Üdv!
Lenne egy olyan problémám, hogy a szerver alkalmanként kifagy. Hibát nem ír, de az egyik CPU magot teljesen megzabálja, ezáltal nõ a load avg.
Arra tippelünk, hogy a MYSQL a hibás. Az angol fórumon azt írták, hogy threadelni kell a queryket. Egy hétbe telt, de megcsináltuk. Azonban még mindig fentáll az eset.
my.cnf:
key_buffer<----><------>= 96M
wait_timeout = 60
max_allowed_packet<---->= 32M
thread_stack<--><------>= 256K
thread_cache_size = 32
Valami ötletetek van esetleg?
-
Milyen gyakran kerül meghívásra mysql_query funkció?
Ugyanazon a gépen van a mysql szerver, mint a samp szerver?
-
durván 2000 query van a cuccban, egy szerveren van a mysql és a szerver.
Pluginok:
Incognito Streamer 2.52
Incognito Audio 0.5
sscanf
SAMP MYSQL 2.1.1
gvar
4:29: Bár szívtam vele kicsit (pár órát), fordítottam egy mysql plugint. Arra gondoltam, hogy a letöltött változat az kifagyást eredményezhet. Igaz, hogy 64 bites a rendszer, de az -m32 sokat segített, 2 megás lett a .so fájl, de elindult vele. Írni fogok, hogy mi a helyzet.
-
Na nekem pont a többszálas lekérdezésekkel voltak ilyen problémák.
Én BlueG pluginját használom, abban nekem soha nem mûködött jól a többszálas lekérdezés :/
De nem tudom, hogy Ethan pluginjával mi a helyzet.
-
OnPlayerUpdate alatt szerepel mysql_query?
Én is Blue_G mysql pluginját használom és ezt is javaslom.
-
Nem jó ez így, még mindig csinálja. Plz help!
-
OnPlayerUpdate alatt szerepel mysql_query?
-
Nem lehet egy kiakadó ciklus? Nem tudtok esetleg egy scriptet ami riaszt ha kiakad egy ciklus?
-
http://forum.sa-mp.com/showthread.php?t=262796
-
Próbáltam, de nem írt ki semmit sem.
-
Mit módosítottál a forráskódban? Hogyan és mivel fordítottad le a nyelvet?
-
Ez nem mások által írt mod, a mi csapatunk írta.
-
Úgy értve hogy a plugin lett-e módosítva, vagy más programmal lett lefordítva?
-
A static release-t használtuk egy ideig, akkor is ez volt. A napokban forgattam linuxon egy .so-t. viszont az kb 4x akkora volt mint a static build.
-
Ha kompatibilis a rendszerrel, akkor nincs vele probléma.
A módban túl nagyok a query cellák, ezért van túlterhelve a plugin SQLHandle.size lekérdezés.
-
Szerintem meg egy ciklussal van a baj.
-
Ha már ciklus sorozatban szerepel mysql_query akkor már régen rossz.
Nézd meg mi az utolsó bejegyzés mysql logban mikor a problémát tapasztalod elsõként.
Jha igen, éles szerveren ne használj semmilyen mysql_debug dolgot, csak olyan helyeken kapcsold be és rögtön ki ahol valami probléma lehetséges.
-
Arra rájöttünk, hogy az sql csak egy bizonyos felhasználószám felett akad ki. SQL log offolva van. 1 cikluson belül van query, de az elkerülhetetlen.
-
Pont az a ciklus miatt akadhat ki ahol a mysql_query van.
Minél többen vannak a szerveren annál többször kerül meghívásra az a bizonyos mysql_query rövid idõn belül.
Ha bemásolod a kódot biztos lesz jobb ötlet annak megoldására.
-
inkább leírom röviden, tömören mi a probléma, és hogy hogyan épül fel a rendszer.
Régebben is ugyan ez a fajta kifagyásunk volt, ami annyit tesz hogy egy bizonyos idõn belül rengeteg sok incomming connection-t jelez a log a játékosok neveivel, és IP -jével. Ekkor a szerver nem állt le, hanem futott azzal a játékosszámmal ami a fagyás elõtt volt, de nem lehetett fellépni a szerverre, sõt a szervergépnek a processzorát is 100% -ra terhelte. Ekkoriban írtunk egy segélykérõ topicot a hivatalos fórumra ( http://forum.sa-mp.com/showthread.php?t=294180 ). Itt összehordtak pár baromságot, viszont többen is írták hogy próbáljuk átírni a mysql rendszerünket multi-thread használatával. Ezt eleinte elleneztem, ugyanis elég hatalmas rendszerrõl van szó, továbbá rengetek sok visszatérõ értékes funckió is van (pl. GetVehilceOwner ) amit viszont nem lehet beletenni. (vagyis lehet, de külön-külön kellene mindig beírogatni). Ekkor megpróbálkozunk a MYSQL R6 plugint lecserélni a StrickenKid féle MySQL 2.1.1 -re. A rendszer stabilabb lett, viszont a kifagyás nem szûnt meg.
Ekkor olyan módszert alkalmaztam, miszerint 4db mysql kapcsolatot hozok létre. Elsõben az összes lehetséges lekérdezést átírtam multi-thread-ot használva. A másodikban a visszatérõ értékes lekérdezéseket tettem. A harmadikban a multi-threados ciklusos (loopos) lekérdezések vannak. (aminek több mint egy értéke van. pl. amikor a házak betöltését csinálja). A negyediben pedig ugyancsak a ciklusos lekérdetések vannak, de itt a visszatérõ értékesek. (ebbõl csak pár db van).
A rendszer gyorsabb, viszont a fagyás ismételten elõfordul. Egyedül az változott hogy a fagyás után nem fagy be a szerver a 100% -os processzorhasználattal, hanem simán leáll.
Mielõtt valaki félreértené, a ciklusos lekérdetések alatt nem arra gondolok hogy van egy ciklus, és abban van mysql_query meghívva, hanem amikor több adatról van szó, akkor ciklussal megy végig az egészen.
pl..
[pawn]
new temp[256], id, Float:x, Float:y, Float:z;
mysql_query(\"SELECT `id`, `x`, `y`, `z` FROM `houses`\");
mysql_store_result();
while ( mysql_fetch_row(temp,\"|\") )
{
sscanf(temp,\"p<|>ifff\",id, x, y, z);
CreateHouse(id, x, y, z);
}
mysql_free_result();
[/pawn]
-
Szerintem mindenféleképpen kellene egy mysql_debug logot készítenetek és megnézni melyikek az utolsó mysql adatcserék, mikor a fagyás bekövetkezik. (sajnos ez plusz leterhelés lesz a szervernek de hát hiba keresés erejéig miért is ne? :D (Hallottam már pár GB-os debug .txt fájlról. :D)
Tegyétek be Zeex crashdetect pluginját, hátha jelezne valami hibát. ( A leállásnak oka van, valahogy nyerni kell információt a körülményeirõl, ha javítani akarjátok.)
Másik ötletem még az lenne hogy, szedjetek le valami mysql-es gamemódot és megnézni annál is jelentkezik-e valami hasonló probléma.
-
próbáltuk már mind2-õt. egyik sem jelzett semmit.
-
Még egy ötlet közben, próbáljatok meg másik hostot ideiglenesen ott is jelentkezik-e a probléma.
Minél több infót szereztek a fagyás/crash pillanatáról annál közelebb kerültök a hiba elhárításához.
A crashdetect pluginhoz másképp kell elkészíteni az .amx fájlokat hogy hasznosabb információt tudjon visszaadni. ( -d2 or -d3 )
Mivel a módot senki mással nem akarjátok megosztani ezt innentõl kezdve nektek kell megoldani, véleményem szerint amiket eddig írtak nektek annál többet senki se fog tudni írni.
-
pontosan tudom hogyan kell lefordítani a crachdetecthez a módot, azért köszi :)
Most egyenlõre a foreach -re gyanakszok, most ugyanis 2x is úgy fagyott ki a szerver hogy utolsó használt parancsban csak az szerepel.