Необъяснимое линейное увеличение времени SELECT к базе MySQL при одинаковых запросах в цикле?

Question

[Nastradamus]

Добрый день! Столкнулись с очень странной проблемой.

К сожалению, куски кода привести не могу. Но постараюсь описать суть.

Может кто сталкивался с проблемой и по моей информации будет понятно что мы делаем не так.


Имеем PHP 5.2.17 with Suhosin-Patch в режиме CLI. Консольное приложение считывает из битрикса через Bitrix API определенный массив юзеров. Далее, в цикле, для каждого юзера идет запрос на получение определенных свойств.

Так вот, для каждого нового юзера время на запрос увеличивается.

Например, для юзера 1 запрос занимал 0.00002 секунды, а для юзера 10000 это уже 0.54323 секунд. Время увеличивается всегда линейно. Память, занимаемая приложением тоже растет.


Пробовали на разных ОС (FreeBSD, последняя Убунта, Винда) — везде одно и тоже. Пробовали ставить и постоянное соединение к базе и НЕ постоянное (в конфиге битрикс). Пробовали даже отключаться от БД каждые 100 итераций и подключатсья заново насильно. Переменные все чистим. Уже замучались.


Вопрос: в чем может быть причина такой деградации? Код вроде уже весь вылизан и проверен несколькими весьма хорошими программистами.


Может ли это быть из-за того, что Битрикс использует стандартный модуль PHP Mysql?


Заранее, спасибо!


upd. Добавил пример кода:

 $subscriber = new Subscribers();

 
$arSubscriberList = $subscriber->getList();

 
$i = 0;

 
while ($i<=count($arSubscriberList)) {

 

 $subscriber = $arSubscriber[$i];

 

 $sql = 'SELECT NAME,LAST_NAME FROM b_user WHERE EMAIL='.subscriber['email'].';';

 $resSubscriber = $DB->Query($sql);

 

 $result[] = $resSubscriber->Fetch();

 

 $i++
}

UPD. Проблема решена.

Кому интересно: решилось всё переписыванием наших классов на singleton.

Додумались мы до этого только после использования профайлера xhprof, а точне XH Gui.

Comments

[Skpd]

Без кода, хотя бы приблизительного, сложно дать ответ.

[script88]

Может ли это быть из-за того, что Битрикс использует стандартный модуль PHP Mysql?
Битрикс сам рекомендует использовать php как mod_php

[Nastradamus]

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

script88, ну а рассылку серий писем Битрикс рекомендует запускать по крону через консольный PHP. Это как раз наш случай.

Answer 1

[Stdit]

Это замедление распространяется только на один запуск, или на каждый последующий? Я бы для начала поставил профайлер и посмотрел его отчёт по памяти на предмет метода, в котором возникает утечка памяти.
Да, и ещё: почему бы не получить сразу все свойства для всех юзеров одним запросом, а потом сгруппировать и сформировать нужный $result?

Comments

[Nastradamus]

Это замедление распространяется только на один запуск, или на каждый последующий?

Если остановиться на 2000 юзерах и начать с этой цифры, то скорость выборок начинается опять с маленькой и далее идет деградация.

Насчет профайлера думаем. Собираемся прикрутить xdebug.

По поводу получения всех свойств сразу одним запросом — интересная идея! Сейчас думаем как это можно реализовать — пока в голове не укладывается (у нас там примерно 5 запросов к каждому юзеру. и один из них по xml-rpc к другому серверу).

[Stdit]

Я имел в виду запуск скрипта, а не запроса. Если каждый запуск ведёт себя одинаково и не связан с предыдущим, то проблема сужается до анализа php-кода. Профайлер я обычно использую xhprof, но тут уж как кому больше нравится. В любом случае, для задач оптимизации это намного быстрее и эффективнее, чем ручной поиск подозрительных мест. Организовать единый запрос можно двумя способами: через прямой sql (select * fro, b_user where email in (...)"), или через bitrix api, передав в CUser::GetList качестве фильтра email-ов массив (об этом лучше всего спраишвать на соответствующем форуме).
Когда выборка будет получена, нужно её обойти (через GetNext) и записать свойства в словарь, ключами которого будут id или email юзеров, а значениями — формируемые массивы свойств. Потом преобразовать словарь в нужный массив (array_values).

[Stdit]

Соответственно, при наполнении словаря, можно делать раздельно каждый тип запросов (включая xml-rpc). Главное, чтобы памяти хватило на хранение промежуточных результатов.

[Nastradamus]

Спасибо за наводку на xhprof. XH Gui невероятно удобная вещь. С помощью него и нашли проблему: создавалось слишком много экземпляров одного и того же класса.

[Stdit]

Рад был помочь.

Answer 2

[DrNemo]

я бы попробовал бы для начала реализовать этот же пример на чистом php, хотя бы отправку запроса и посмотреть итоги.
если потери по времени не будет, поздравляю, битрикс.
*но по теме, но код я бы написал так
$subscriber = new Subscribers(); $arSubscriberList = $subscriber->getList(); foreach($arSubscriberLis as $subscriber) { $sql = 'SELECT NAME,LAST_NAME FROM b_user WHERE EMAIL='.subscriber['email'].';'; $resSubscriber = $DB->Query($sql); $result[] = $resSubscriber->Fetch(); }

Comments

[Nastradamus]

foreach в несколько раз медленнее while.

[DrNemo]

можно ссылку на сравнение
то что я нагуглил:
«для перебора простых индексных массивов нужно использовать for или while
для перебора ассоциативных массивов нужно использотьва foreach»

Answer 3

[Skpd]

Попробуйте сделать стриминг, если это возможно.

У Вас, насколько я понял, собираются все данные вместе в $result. Если данных действительно много, то может банально не хватить памяти для кэша, или даже для работы без подкачки.

Comments

[Nastradamus]

Но ведь $result заменяется новым при каждой итерации цикла while.

А что такое стриминг? Быстрым гуглением не обнаружил что вы имели в виду конкретно.

[Stdit]

Он ведь не заменяется, при итерации добавляется элемент в массив $result.

[Skpd]

У Вас массив увеличивается с каждой итерацией цикла.
Под словом стриминг я имел в виду потоковую обработку данных. Т.е. используете выбранные из БД данные сразу же, и на следующем шаге цикла заменяете их.

[Nastradamus]

Пардон… Это такой псевдокод мне набросал программист. На самом деле он там не увеличивается, а заменяется новым. Я имею в виду $result[].

[Skpd]

Попробуйте в конце цикла делать unset всех используемых переменных, аещё лучше установите 5.3. В php 5.2 нет garbage collector.

[Nastradamus]

Бинго! Похоже, как раз дело в Garbage Collection. Почитал — он и правда не высвобождает память при unset() в PHP 5.1.

Кстати, мы подумываем сделать псевдомногопоточность: скармливать через STDIN другому скрипту e-mail'ы для обработки порциями по 8 штук (на каждый email будет запускаться 1 копия обработчика) — т.е. равное числу ядер на сервере. Дожидаться выполнения скриптов и запускать следующие 8.

[Skpd]

Посмотрите библиотеку Gearman, задача подходящая, мне кажется.

[Stdit]

Вот оно как, оказывается. А сколько занимает обработка одного юзера, сколько из этого времени уходит на xml-prc? Поддерживает ли xml-rpc пакетные запросы?
Может, просто разбить всех юзеров на 8 групп и скормить 8 скриптам, которые их за один проход всех обработают? Вариантов разбить много: по остатку от деления на 8 айдишника например, или контрольной суммы, или просто сортировать по индексу и разбивать на 8 частей. Обрабатывать пользователей по одному мне не кажется хорошей идеей, за исключением случая, когда требуется обработка конкретного юзера по событию его обновления.

[Nastradamus]

В начале выполнения скрипта первые юзеры обрабатываются примерно 0.008379 секунд за штуку. В конце — около полусекунды.
В процессе отладки мы отключали вообще эти xml-rpc и сводили все запросы к 1 самому примитивному на 1 юзера.
Но производительность даже в таком случае падала примерно ровно также.

Наверняка что-то там не чистится в области памяти PHP.

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

[Вячеслав Слинько]

примерно 0.008379 :)

Answer 4

[script88]

1 Конфиг в студию
2 Пробовали запрос в консоли выполнять?
3 Настроен ли кеш в мускуле?

Comments

[Nastradamus]

script88,

1) Конфиг чего? mysql, php или биртикса? :)
2) Один запрос выполняется пулей. А вот в PHP, когда они в цикле идут — начинается деградация.
Есть подозрение, что дело не в MySQL, а в php, либо в модуле libmysql.so (модуль php, используемый в Битрикс), либо в коде.
3) Настроен и перенастроен многократно. :)

Кстати, база в InnoDB. Юзеров эдак ~250 000.

[script88]

Профилирование скриптов делали? за юзайте Pinba много интересного увидите
Да, совсем забыл сказать, попробуйте вместо $resSubscriber = $DB->Query($sql); выполнить запрос через mysql_query, минуя API Bitrix
P.S. сталкивались с проблемой когда через API Битрикса точно не припомню но раз в 6 или 7 медленнее

Answer 5

[Дмитрий Рублёв]

Сложно без кода сказать.
Можеть быть, где-то есть зацикливание, или рекурсивные вызовы.

Comments

[Nastradamus]

Добавил псевдокод.

Answer 6

[Сергей Береснев]

Как время исполнения запроса измеряете?

$subscriber->getList() — возвращает массив?

Comments

[Nastradamus]

Да. Массив массивов из трех элементов. Пока в тестовом варианте 5000 юзеров.

Answer 7

[Wott]

Вы неэффективно используете базу. Каждый раз вы делаете запрос мимо кэша да еще через кучу прокладок. Если для кэша установлено достаточно большое значение то он будет расти, пока не упрется в лимит.

По хорошему запрос должен быть один — «взять всех пользователей вместе с именем».
Хотя мне сложно представить зачем вдруг вам понадобились сразу все пользователи.

Надеюсь с индексами в базе все нормально.

Comments

[Nastradamus]

Мы выгружаем не всех юзеров, а только тех, кто подписан на новость по тэгу.

Пробовали делать как вы сказали — «взять всех пользователей вместе с именем» в один массив — получается пипец с вылетом памяти за 4 гига. :)

С индексами в базе вроде все ок с первого взгляда. Но там не в них дело.

[Wott]

ну и зачем вам вся таблица?
вы хотите отправить единомоментно 250к писем? или хотите передать список во внешний сервис?
в первом случае вам надо использовать постраничный вывод таблицы ( вместе с именами ) через limit — mysql не oracle, он сразу грузит данные в память, справедливо считая что либо памяти достаточно либо админ/программер умнее его.
во втором сделать view и экспортировать его сразу в файл

[Nastradamus]

Мы берем юзеров, у которых есть тэги (подписка на новость данного типа) и отправляем им письма. Бывает что таких пользователей около 250 тысяч. Выборка самих юзеров (их id == email) по тэгу осуществляется менее чем за секунду.
Потом уже формируется персоанализированный текст новости (с именем человека, сылками на отписку и т.п.). На этом этапе и затык с селектами в цикле. В момент селекта и создания письма, письмо вставляется в таблицу b_events для дальнейшей обработки другим обработчиком — то есть, это делается 250k раз по очереди, а не сразу. Момент записи в таблицу не тормозит.

Answer 8

[Vampiro]

Я, конечн, жопорукий извращенец, но почему нельзя сделать таблицу subscribers, заполнить ее один раз всеми значениями при добавлении подписчика, а при рассылке тупо из нее дергать?

И еще, в порядке бреда, проблема может быть в пыхе, на этапе выделения оперативки. Попробуйте для теста 5.4 не меняя остального. Не помню на какой версии у меня была такая проблема.

Comments

[Nastradamus]

Там такая система: есть ТЭГИ, на которые подписаны юзеры. У каждой новости свой тэг. На этапе создания рассылки выгружаются из базы юзеры, у которых есть подписка на этот ТЭГ.

Что-то не так с выделением оперативки — нам тоже так кажется.
Но пока мы не настроили профайлер. :)

Answer 9

[Nastradamus]

Кому интересно: решилось всё переписыванием наших классов на singleton.
Додумались мы до этого только после использования профайлера xhprof, а точне XH Gui.