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


Разбухание b_sale_fuser на активных проектах

Если у вас проект активен, то обращали ли вы внимание на количество записей b_sale_fuser (идентификаторов корзин)?
в идеале он должен содержать только записи не старее, чем интервал хранения корзин в настройках системы.

Если же это не так, тогда:
1. Смотрим, работает ли агент CSaleUser::DeleteOldAgent();
2. Анализируем, успевает ли агент удалять старые корзины

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

По умолчанию интервал работы агента 28800 секунд (8ч)
Но агент при срабатывании удаляет не более 300 старых записей
Вот пример кода функции отвечающей за удаление старых корзин:
function DeleteOld($nDays)
   {
      global $DB;

      $nDays = IntVal($nDays);
      $strSql =
         "SEL ECT ID ".
         "FR OM b_sale_fuser ".
         "WHERE TO_DAYS(DATE_UPDATE)<(TO_DAYS(NOW())-".$nDays.") LIMIT 300";
      $db_res = $DB->Query($strSql, false, "File: ".__FILE__."<br>Line: ".__LINE__);
      while ($ar_res = $db_res->Fetch())
      {
         CSaleBasket::DeleteAll($ar_res["ID"], false);
         CSaleUser::Delete($ar_res["ID"]);
      }
      return true;
   }


Т.е. если за 8 ч. у вас в таблице b_sale_fuser появляется более 300 записей, она обречена на "разбухание".

Ну и вывод таков:
так как нескромно лезть в ядро и менять жестко заданные лимиты в запросах (да и скорость теряем при этом на работе агента), то уменьшаем интервал таким образом, чтобы держать размер таблицы "под контролем".

Пишу данный пост, так как уже встречал проекты с "распухшими корзинами".
Да вот и на одном из своих недавно обнаружил 600000 записей

 

 

Источник: http://dev.1c-bitrix.ru/community/webdev/user/10337/blog/2323/

Назад в раздел

Подписаться на новые материалы раздела:














CAPTCHA