Перенагрузка сервера - вариант решения проблемы... - Joomla 1.0: Установка, обновление и настройка

Столкнулся с проблемой - перенагрузка на сервер по вине скриптов Джумлы

то есть - скрипт загружается и по несколько часов выполняется по циклу, не завершаясь.
Хостинг - Hostpro

Добрый день, за последние пару дней ко мне как веб-програмисту
обращалось более десяти людей с идентичными проблемами.
Все они использовали движок Joomla. Всем им ихние хостеры
заблокировали акаунты.
На форуме движка Joomla есть топик где десятки людей рапортуют о такой
проблеме.

Локализовать проблемный участок мне удалось лишь частично. Это
практически любой компонент который в цикле делает выборки из СУБД. Но
"криворукие" програмисты Joomla используют подавление ошибок через @ и
не делают обработки ошибок/исключений если mysql_query или
mysql_result возвращают не тот результат или вобще утрачен конект.
Практически если во время работы скрипта утрачивается конект к БД,
скрипт завершить работу может только по таймауту (php.ini:
max_execution_time)

Предполагаю что на вашем хостинге кроме моих есть ещё много сайтов
которые используеют этот популярный движок, но "оптимизировать"
владельцам вряд ли удастся пока Joomla не выпустит обновление.

Так же, я был удивлен что max_execution_time у вас по умолчанию 7200
секунд (это 2 часа).
Кардинальным решением проблемы до выхода обновлений Joomla я считаю
выставить всем или каждому лично max_execution_time=5-15 секунд, т.е.
если проблема зацикливания проявится, скрипт не будет 2 часа грузить
CPU, а через 5 секунд (достаточно для нормальной работы любого
веб-сайта) будет принудеительн озавершен интерпретатором PHP.

В этом сайте я уже установил в скриптах
set_time_limit(5);
и ходатайствую об открытии доступа к этой папке.
Возможно такая просьба недавно приходила по e-mail от другого человека
который курирет этот сайт.


ahcu> Здравствуйте, .

ahcu>     Ваш сайт создаёт нагрузку на нашем сервере. Это негативно
ahcu>     сказывается на всей работе сервера. Оптимизируйте пожалуйста
ahcu>     данный скрипты. Это не нормально когда php скрипт работает такое
ahcu>     количество времени.

если такое происходит - мне порекомендовали прописать в
configuration.php
строчку
set_time_limit(5);

это должно предотвратить цикличное выполнение завснувшего скрипта и перенагрузку на сервер из-за етого.

Вот здесь человек запостил свое мнение:
http://php.com.ua/forum/viewtopic.php?t=6628


Далее  нашел вот такую инфу о возможности зависа самой MySQL

"I suppose it's some kind of stack overflow in the IF() function."
http://bugs.mysql.com/bug.php?id=21476

Локализовать проблемный участок мне удалось лишь частично. Это практически любой компонент который в цикле делает выборки из СУБД. Но "криворукие" програмисты Joomla используют подавление ошибок через @ и не делают обработки ошибок/исключений если mysql_query или mysql_result возвращают не тот результат или вобще утрачен конект.

мдя, интересно, а автор этих строк вообще смотрел как в самой Joomla происходит работа с БД? то, что он нашел проблему в галерее DatsoGallery, где за многовековую историю компонента (сначала AkoGallery, затем PonyGallery) набралось куча мусора, отнюдь не означает, что виновата Joomla...

В Joomla и ее расширениях, вся работа с базой данных осуществляется через 2 класса database и mosDBTable. И поверьте, единственное место, где в них происходит подавление вывода ошибки, это при подключении к БД, и то, сама ошибка прекрасно обрабатывается... В этом вы можете сами убедиться внимательно изучив код внутри файла /includes/database.php. Поэтому все расширения, которые используюьт предложенный ядром системы интерфейс работы с базой данных описанных проблем создавать не могут...

Так что приведенные заявления, к самой Joomla никакого отношения не имеют... А что касается качества сторонних расширений, то это уже собственно на совести их разработчиков.

но человек ведь не спец в джумле - он посмотрел только кусок кода - увидел ошибку - и сообщил, ведь хочет помочь человек
http://forge.joomla.org/sf/tracker/do/viewArtifact/projects.joomla/tracker.bugs/artf6121?_message=1159293810550

Странные люди

 

Такие и машин то себе не покупают потому что те об стены бетонные мнутся, ломаются если заднию на полной скорости врубить.
Криворукое автомобилестроение!!!!!!!!

ответ по аське от автора приведенных выше строк:
"Ядро системы Joomla никак не обрабатывает ошибку утраты конекта к БД которая появляется в т.ч. из-за бага http://bugs.mysql.com/bug.php?id=21476
Когда $this->_resource уже ни на что не указывает, @subpackage Database будет продолжать пытаться выполнить запрос и/или рапортовать о ошибке выполнения запроса (если включен дебаг) но mysql_error() тоже не сможет выполниться т.к. переданный ей  $this->_resource не существует
"
@
 /**
 * Execute the query
 * @return mixed A database resource if successful, FALSE if not.
 */
 function query() {
  global $mosConfig_debug;
  if ($this->_debug) {
   $this->_ticker++;
     $this->_log[] = $this->_sql;
  }
  if ($this->_limit > 0 || $this->_offset > 0) {
   $this->_sql .= "\nLIMIT $this->_offset, $this->_limit";
  }
  $this->_errorNum = 0;
  $this->_errorMsg = '';
  $this->_cursor = mysql_query( $this->_sql, $this->_resource );
  if (!$this->_cursor) {
   $this->_errorNum = mysql_errno( $this->_resource );
   $this->_errorMsg = mysql_error( $this->_resource )." SQL=$this->_sql";
   if ($this->_debug) {
    trigger_error( mysql_error( $this->_resource ), E_USER_NOTICE );
    //echo "<pre>" . $this->_sql . "</pre>\n";
    if (function_exists( 'debug_backtrace' )) {
     foreach( debug_backtrace() as $back) {
      if (@$back['file']) {
       echo '<br />'.$back['file'].':'.$back['line'];
      }
     }
    }
   }
   return false;
  }
  return $this->_cursor;
 }


что будет с этим скриптом если $this->_resource не будет указывать на валидный конект?
@

http://phpclub.ru/paste/index.php?show=1462

но человек ведь не спец в джумле - он посмотрел только кусок кода - увидел ошибку - и сообщил, ведь хочет помочь человек

я понимаю что хочет, но я очень сомневаюсь, что у него есть право безапелляционно называть разработчиков Joomla "криворукими"...

Когда $this->_resource уже ни на что не указывает, @subpackage Database будет продолжать пытаться выполнить запрос и/или рапортовать о ошибке выполнения запроса

когда $this->_resource не валиден, то после строки:


$this->_cursor = mysql_query( $this->_sql, $this->_resource ); 


переменная $this->_cursor будет иметь значени FALSE, затем мы попадем в блок обработки ошибок (да, ошибки не отработаются, бо $this->_resource не валиден, но беды не произойдет) и затем функция query вернет значение FALSE. И где тут возможно зацикливание?

Если кто-то из сторонних разработчиков игнорирует возвращаемый результат, то разработчики Joomla тут не виноваты, хотя все-таки стоило бы сделать более полную обработку ошибок...

P.S. кстати, приведенная ошибка, по которой MySQL может терять коннект, подтверждена пока вроде только для версии 5.0.22, а Joomla официально вообще-то MySQL 5.x не поддерживает. Совместимость с пятеркой обещали в версии 1.5:

To achieve cross database support, a database abstraction library will be implemented. Core scripting will also be improved to prepare for compatibility with other platforms.  The first step towards this goal will be compatability with MySQL 5.0 which is tentatively slated for Joomla! 1.5

> я понимаю что хочет, но я очень сомневаюсь, что у него есть право
> безапелляционно называть разработчиков Joomla "криворукими"...
я был не в курсе чем разработчик com_joomfish или com_dartsogallery отличается от разработчика Joomla, т.к. джумлу в глаза не видел, но надо было в кратчайшие сроки добиться разблокировки акаунта хостером. Извините что выразился не по адресу

> Если кто-то из сторонних разработчиков игнорирует возвращаемый результат, то
> разработчики Joomla тут не виноваты, хотя все-таки стоило бы сделать более полную
> обработку ошибок...
если кто-то из разработчиков софта вешает Windows 98 и она от этого падает то винить будут Билли. Почему централизовано не сделать full-stop скрипта при первом неотработанном SQL запросе? Или неотработка SQL запроса это не "Fatal error" а всего лишь "Notice"?

> P.S. кстати, приведенная ошибка, по которой MySQL может терять коннект, подтверждена
> пока вроде только для версии 5.0.22, а Joomla официально вообще-то MySQL 5.x не
 > поддерживает. Совместимость с пятеркой обещали в версии 1.5:
Баг проверен на трех разных серверах MySQL 4.1

если кто-то из разработчиков софта вешает Windows 98 и она от этого падает то винить будут Билли.

если ставить задачей кого-то обвинить, то обвинить можно кого угодно...

Почему централизовано не сделать full-stop скрипта при первом неотработанном SQL запросе? Или неотработка SQL запроса это не "Fatal error" а всего лишь "Notice"?

Можно и останавливать, а можно возложить это на разработчиков расширений и предоставить им решать, является ли это критической ошибкой, или нет... Хотя конечно, проблему потери коннекта с базой, должно решать ядро...

Баг проверен на трех разных серверах MySQL 4.1

ни разу не сталкивались, хотя у нас на сервере стоит 4.1...

Кстати, мне кажется, стоит задуматься вот еще о чем: если такая ошибка повторяется, значит коннект постоянно падает? Может быть предложить хостеру вместо отключения аккаунтов решить проблему с сервером?

Интересно так быть посредником в перепалке двух спецов ))

> если ставить задачей кого-то обвинить, то обвинить можно кого угодно...
задача была доказать хостеру что "оптимизировать кривые скрипты" работающие бесконечно не представляется возможным ибо они чужие

> ни разу не сталкивались, хотя у нас на сервере стоит 4.1...
так это зависит от размера злосчастного thread_stack
увеличивать его хостер категорично отказался

Вот ответ от сотрудника MySQL который подтвердил http://bugs.mysql.com/bug.php?id=21476
[19:48] <sveta> в общем от меня далее мало зависит, как этот баг фиксить будут, но спросить могу
[20:01] <sveta> вообще раз баг verified, то его фиксить будут
[20:01] <sveta> и странно, что ещё не фиксят: я узнаю почему
[20:43] <sveta> .msg Yurik послала письмо человеку, ответственному за то, чтобы верифицированные баги фиксились

Интересно так быть посредником в перепалке двух спецов ))

бывает...

задача была доказать хостеру что "оптимизировать кривые скрипты" работающие бесконечно не представляется возможным ибо они чужие

а я бы начинал разбирательство с непредоставления ими услуг, т.е. рабочего мускла...

так это зависит от размера злосчастного thread_stack
увеличивать его хостер категорично отказался

Интересненько, а какое значение там установлено? Судя по конфигурации сервера, у нас thread_stack:  196608

Вот ответ от сотрудника MySQL который подтвердил

да верю, верю... просто на странице с багом, где написано verified, указана была версия 5.0.22, и вроде не было указаний на линейку 4.1...

Мне лично сапорт ответил (после указания им ссылки на баг):

У нас из соображений стабильности сервера:
thread_cache_size=128
К сожалению, изменению это не подлежит.
=

Я сам посмотрел в настройки Мускуеля:
 table cache     1,024
table type    MyISAM
thread cache size    128
thread stack    196,608

table cache     1,024
table type    MyISAM
thread cache size    128
thread stack    196,608

а у нас:

table cache     500
table type    MyISAM
thread cache size    12
thread stack    196,608

странно... конечно, с базой у нас иногда проблемы бывают, но потерь коннекта насколько помню не было...