Изпечатай

[gat3way]

То не е точно web development, става въпрос за един демон, който пиша, който стои една зад уеб-фронтенда. За демонът е характерно, че е нещо като dispatcher за job-ове. Когато изчислителните ресурси се освободят, демонът засилва следващият job в опашката, който е наред да бъде изпълнен.

Job-а се изпълнява малко странно, форква се нов дъщерен процес, който засилва през ssh задачата на отдалечена машина и събира резултата от изпълнението. Parent процеса създава mysql връзка малко преди да се форкне дъщерния. Дърщерния съответно преизползва connection-a. Съответно гърми с:

mysql server has gone away

Сега това е логично, понеже понякога job-овете отнемат часове докато се изпълнят и за това време връзката до mysql сървъра отдавна е таймаутнала. По-интересното е че когато се опитам да отворя последваща връзка и да засиля заявка към базата, тя умира точно по същият начин. Отварянето на връзката е ОК, но заявката гърми със същата грешка.

Проблемът е workaround-нат по идиотски начин: mysql сървъра слухти на на един ethernet интерфейс, както и на loopback-а. Ако умре връзката към 127.0.0.1, създавам нова като я отварям към IP адреса на етернетския интерфейс и тогава всичко минава без проблеми. Проблемът е че това е просто тъпо.

Не мога да си обясня този проблем. Според мен тъпото PHP просто се опитва да преизползва връзката без да вземе предвид че е таймаутнала, един вид някакъв connection reuse механизъм. Но това е безумно малоумно и води дотам че и без това отвратителния код става още по-отвратителен.

Някой забелязвал ли е този проблем и дали е открил по-добро решение ако го е забелязал?

[wfw]

wait_timeout и interactive_timeout на mysql защо не ги вдигнеш?

[gat3way]

Мога да ги вдигна, но не е там проблема. Проблемът не е в mysql, проблемът е в PHP. Рових в bugtracking системата им, засега не съм открил точно същият казус. Това ме навежда на мисълта, че съм нацелил някакъв feature, а не бъг. За жалост не съм толкова чак толкова навътре в PHP за да знам със сигурност, в интерес на истината не съм пипал PHP сигурно от година. Обаче досега не съм го виждал това поведение в интерес на истината.

[wfw]

На няколко мои машини има подобен проблем - започва да работи скрипт, който в началото на работа си отваря връзка към базата данни. Извършва някакви сложни сметки, сортира и т.н. и след 5 минути започва да се обръща към базата, но времето, за което връзката не е била използвана е по-голямо от въпросните 2 променливи, които споменах. Тогава връща същата грешка, че mysql-a е затворил връзката.
Нашите interactive и wait timeouts са малки (5-10сек), защото има безумно написани приложения, които са прекалено тъпи да си затварят връзките и така ги форсираме да ги затварят, иначе при голямо натоварване понякога mysql-a остава без връзки, а реално нищо не го натоварва.

Пробвай да затвориш връзката към mysql и да я отвориш в края нa job-a, така би трябвало да се унищожи конструктура, в случай, че ползваш mysql_connect. ако ползваш mysql_pconnect, пробвай да ползва mysql_connect.

Можеш да пробваш и връзка през сокета...

[gat3way]

Там е проблемът. Викам mysql_close(), отварям нова връзка (няма проблеми), правя заявката, гръмва ми с тази грешка. Алтернативно обаче ако отворя новата връзка към другия IP адрес на който слухти сървъра, тогава няма проблеми. Няма много логика, единственото което ми хрумва е че PHP може би прави някакви хитрости с connection management-а си. Както и да е, така или иначе имам workaround, ще си карам с него.

[go_fire]

Така си е устроен. Отвориш ли една връзка да си я ползваш до края. Златно правило си е да не се затварят връзки и отварят нови. Това е може би първото, на което учат начинаещия при работа със СУБД в php. Дали е тъпо или не не съм компетентен да кажа, но ми звучи логично да е така.

[neter]

Не съм попадал на това, но изглежда целта на функцията mysql_ping() е да спомага точно в такива случаи - проверява дали връзката е timeout-нала, и ако е, съобщава за това и пробва да се свърже отново, преизползвайки същия отворен канал. Странно, въпреки написаното в описанието към функцията, в коментар на потребител отдолу пише, че mysql_ping() само проверява дали връзката е още активна, но не се свързва автоматично, ако е timeout-нала, но дори да е така, с повторно изпълнение на mysql_connect() след това може да се задейства.
И въпреки това, нещо не е читава тази работа да не можеш да се вържеш към същото IP с друга връзка, но към другото да можеш. Ако намеря време тия дни ще си поиграя да видя какъв feature или бъг са спретнали в PHP

[gat3way]

Така си е устроен. Отвориш ли една връзка да си я ползваш до края. Златно правило си е да не се затварят връзки и отварят нови. Това е може би първото, на което учат начинаещия при работа със СУБД в php. Дали е тъпо или не не съм компетентен да кажа, но ми звучи логично да е така.

Може и да върши работа за apache скрипт, от който не се очаква да отнеме повече от няколко секунди за изпълнение, но не виждам как ще се случи с демон, който работи в background-a. Това примерно би означавало като рестартирам mysql-а да ходя и да рестартирам и демона (и ако има schedule-нат job става красиво - базата остава в неконсистентно състояние, а job-а съответно увисва завинаги в състояние "изпълнява се".

Това също би налагало mysql връзките никога да не таймаутват.

[borovaka]

@gat3way Разгледай атрибута Persistent connections при PDO:
http://bg2.php.net/manual/en/pdo.connections.php
Абе изобщо пробвай PDO как ще се държи в подобна ситуация.
А ако продължи да прави номера, може да пробваш ODBC.

[Neo2SHYAlien]

Аз имам същия проблем с демонче пак на php  аз лично ползвам mysqli и така и не открих логично обяснение защо аджеба се случва така