MySQL server has gone away

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • VR46
  • Registratie: Januari 2005
  • Laatst online: 08-09 12:51
Hallo,

Ik werk aan een script dat een aantal duizenden rows moet inserten met één query (indien mogelijk), maar de MySQL database lijkt dit vooralsnog niet te trekken.
De query wordt afgehandeld door de functie mysqli::multi_query zodat ik twee queries in één kan uitvoeren.
Bij het uitvoeren van de query krijg ik echter een foutmelding terug, MySQL server has gone away.

Ik vraag me dus af of ik te veel van MySQL vraag door al die records in één query af te laten handelen, of dat ik een timeout groter moet instellen. Is het mogelijk om een write timeout groter in te stellen, zonder dat ik aanpassingen aan de configuratie van mijn MySQL server moet maken? Kan ik dit bijvoorbeeld doen door middel van mysqli::real_connect in combinatie met de flag MYSQLI_CLIENT_INTERACTIVE, of heeft dat met iets anders te maken?

Alvast bedankt!

Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Ik ben, wat dit betreft, niet bekend genoeg met MySQL, maar waarom hak je de "duizenden queries" niet op in batches van, zeg, 1000 ofzo? Er staat overigens ook nog zinnige info in de comments op de pagina waar je zelf naar linkt; die ook al eens bekeken?

[ Voor 40% gewijzigd door RobIII op 04-08-2010 12:02 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • VR46
  • Registratie: Januari 2005
  • Laatst online: 08-09 12:51
RobIII schreef op woensdag 04 augustus 2010 @ 12:00:
Ik ben, wat dit betreft, niet bekend genoeg met MySQL, maar waarom hak je de "duizenden queries" niet op in batches van, zeg, 1000 ofzo?
Klopt, daar heb ik ook aan gedacht, maar het maakt het script wel eenvoudiger als ik alles in een query kan verwerken. Als ik een batch zou willen maken, heeft MySQLi daar een ingebakken functie voor die het zelf in batches kan verdelen, of zou ik dat zelf 'handmatig' moeten doen met een loop oid?
Er staat overigens ook nog zinnige info in de comments op de pagina waar je zelf naar linkt; die ook al eens bekeken?
Ah, die had ik over het hoofd gezien, bedankt. Ik word er helaas niet heel veel wijzer van, maar het lijkt er inderdaad op dat ik meer van mysql vraag dan het aankan op deze manier..

[ Voor 22% gewijzigd door VR46 op 04-08-2010 12:07 ]


Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
cbernardini schreef op woensdag 04 augustus 2010 @ 12:03:
Als ik een batch zou willen maken, heeft MySQLi daar een ingebakken functie voor die het zelf in batches kan verdelen, of zou ik dat zelf 'handmatig' moeten doen met een loop oid?
Ik neem aan dat MySQL hier niet in voorziet; in het geval dat het verschillende queries zijn die gerelateerd zijn aan elkaar (in "groepjes") zou je die namelijk het liefst natuurlijk per "groepje" uitvoeren (zodat je ze evt. nog in een transactie kunt wrappen e.d.) en MySQL zal dat niet zelf gaan uitpuzzelen ofzo. En ik ken geen enkel RDBMS dat iets dergelijks doet. Maar het is toch geen rocket science om om de 1000 (ofzo) queries even een execute aan te stampen en dan weer verder te gaan lijkt me?

Then again; het kan goed iets te maken hebben met timeouts, max. query size, max. buffer sizes of weet ik het wat. Ik ken MySQL daar niet intiem genoeg voor en for all I know kun je misschien inderdaad in de connectieflags iets meegeven of een property van een connectie setten op iets waarmee je queries wél in 1 keer goed uitgevoerd worden zonder dat MySQL op reis gaat.

[ Voor 18% gewijzigd door RobIII op 04-08-2010 12:07 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • GlowMouse
  • Registratie: November 2002
  • Niet online
http://dev.mysql.com/doc/refman/5.0/en/gone-away.html

Ik denk dat je packets te groot zijn of dat je er te lang over doet om de queries te genereren.

Acties:
  • 0 Henk 'm!

  • VR46
  • Registratie: Januari 2005
  • Laatst online: 08-09 12:51
OK bedankt, ik kom hier weer een eindje mee verder.

Even een heel andere vraag die ik nodig heb bij het maken van de batch;
Hoe kan je het laatste element van een array wijzigen (de waarde ervan veranderen)?... Ik kom er gek genoeg even niet uit.

Acties:
  • 0 Henk 'm!

  • Emmeau
  • Registratie: Mei 2003
  • Niet online

Emmeau

All your UNIX are belong to us

doe een commit na iedere X records.

Wat je nu doet is een giga query bouwen, en mysql moet dus de volledige rollback op gaan bouwen.

If you choose to criticise you choose your enemies


Acties:
  • 0 Henk 'm!

  • MueR
  • Registratie: Januari 2004
  • Laatst online: 14:53

MueR

Admin Tweakers Discord

is niet lief

Anyone who gets in between me and my morning coffee should be insecure.


Acties:
  • 0 Henk 'm!

  • GlowMouse
  • Registratie: November 2002
  • Niet online
Emmeau schreef op woensdag 04 augustus 2010 @ 12:36:
doe een commit na iedere X records.

Wat je nu doet is een giga query bouwen, en mysql moet dus de volledige rollback op gaan bouwen.
Als dingen in één transactie thuishoren, waarom zou je die opsplitsen? 'Een volledige rollback' opbouwen kost helemaal geen extra moeite. Wel duren queries op gewijzigde data wat langer zolang je niks gecommit hebt omdat de server daarvoor de undo logs moet raadplegen, maar dat heeft niets met het probleem van TS te maken.
cbernardini schreef op woensdag 04 augustus 2010 @ 12:20:
Even een heel andere vraag die ik nodig heb bij het maken van de batch;
Hoe kan je het laatste element van een array wijzigen (de waarde ervan veranderen)?... Ik kom er gek genoeg even niet uit.
Dat is wel een heel andere vraag ja. Vervelend dat je er even niet uitkomt, maar daar zijn handleidingen voor :) http://nl3.php.net/manual/en/ref.array.php

Acties:
  • 0 Henk 'm!

  • VR46
  • Registratie: Januari 2005
  • Laatst online: 08-09 12:51
GlowMouse schreef op woensdag 04 augustus 2010 @ 12:48:
[...]

Dat is wel een heel andere vraag ja. Vervelend dat je er even niet uitkomt, maar daar zijn handleidingen voor :) http://nl3.php.net/manual/en/ref.array.php
Die heb ik al geraadpleegd, nu doe ik het zo, dat ik de value van het laatste element opsla in een nieuwe variabele, het laatste element pop en een nieuwe aanmaak maar ik heb het idee dat dit omslachtig is..
PHP:
1
2
3
4
end($array);
$current = current($array) .= " toevoeging";
array_pop($current);
$array[] = $current;

Acties:
  • 0 Henk 'm!

  • GlowMouse
  • Registratie: November 2002
  • Niet online
Regel twee ziet er een beetje raar uit met die = en een .= in hetzelfde statement. Om precies te doen wat je zegt, is deze code nodig:
PHP:
1
2
3
$lastelement = array_pop($array);
$lastelement = $lastelement . ' toevoeging';
$array[] = $lastelement;

Acties:
  • 0 Henk 'm!

  • VR46
  • Registratie: Januari 2005
  • Laatst online: 08-09 12:51
GlowMouse schreef op woensdag 04 augustus 2010 @ 13:03:
Regel twee ziet er een beetje raar uit met die = en een .= in hetzelfde statement. Om precies te doen wat je zegt, is deze code nodig:
PHP:
1
2
3
$lastelement = array_pop($array);
$lastelement = $lastelement . ' toevoeging';
$array[] = $lastelement;
Juist ik had het even overgetikt, foutje :-) Bedankt voor je antwoord.

Ik test mijn script nu zowel op mijn remote host als op mijn localhost (laptop), het inserten van alle records gaat nu goed en ik heb de queries verdeeld in een array. Die array loop ik nu af met een foreach-loop.

Wat me nu opvalt is dat de eerste x-keren dat ik het script uitvoerde, het inserten op mijn localhost gesmeerd ging en het hooguit 5 seconden duurde, maar nu duurt dat ineens eeuwen.. Ik doe wel aan het einde van elke query een free result. Waar kan dit mee te maken hebben?

Op de remote host gaat het vooralsnog goed. Ik heb de queries verdeeld over twee batches (een per tabel), een batch doet 86 queries, de andere 1366. Heb ik het nu weer over te veel queries verdeeld denken jullie?

[ Voor 7% gewijzigd door VR46 op 04-08-2010 15:17 ]

Pagina: 1