Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
Привет. Не могу найти объяснение такому долгому выполнению выполнению запроса, 1.5 сек. И так себя ведут все таблицы, практически, и при update, и при insert. В среднем 1 секунда и больше - запрос. Из файла slow_query.log: # Thread_id: 10379 Schema: exchanges QC_hit: No # Query_time: 1.534451 Lock_time: 0.000103 Rows_sent: 0 Rows_examined: 35 # Rows_affected: 1 SET timestamp=1528628365; UPDATE `courses_from_glases` SET btce_ask = null, cex_bid = null, cex_ask = null, bittrex_bid = null, bittrex_ask = null, kraken_bid = null, kraken_ask = null, bitfinex_bid = null, bitfinex_ask = null, quoine_bid = null, quoine_ask = null, btcc_bid = null, btcc_ask = null, bitstamp_bid = null, bitstamp_ask = null, exmo_bid = null, exmo_ask = null, okcoin_bid = null, okcoin_ask = null, gdax_bid = null, gdax_ask = null, hitbtc_bid = null, hitbtc_ask = null, poloniex_bid = null, poloniex_ask = null, livecoin_bid = null, livecoin_ask = null, therocktrading_bid = null, therocktrading_ask = null, lakebtc_bid = null, lakebtc_ask = null, itbit_bid = null, itbit_ask = null, gemini_bid = null, gemini_ask = null, huobi_bid = null, huobi_ask = null, quadrigacx_bid = null, quadrigacx_ask = null, bleutrade_bid = null, bleutrade_ask = null, liqui_bid = null, liqui_ask = null, c_cex_bid = null, c_cex_ask = null, ecoin_bid = null, ecoin_ask = null, yobit_bid = null, yobit_ask = null, bter_bid = null, bter_ask = null WHERE pair = 'btc_usd'; в таблице неизменно 35 строк, можно добавить UNIQUE INDEX на колонку pair, но при таком количестве строк, по моему производительность не повысит. CREATE TABLE `courses_from_glases` ( `id` int(2) NOT NULL AUTO_INCREMENT, `pair` text, `btce_bid` float(20,8) DEFAULT NULL, `btce_ask` float(20,8) DEFAULT NULL, `cex_bid` float(20,8) DEFAULT NULL, `cex_ask` float(20,8) DEFAULT NULL, `bittrex_bid` float(20,8) DEFAULT NULL, `bittrex_ask` float(20,8) DEFAULT NULL, `kraken_bid` float(20,8) DEFAULT NULL, `kraken_ask` float(20,8) DEFAULT NULL, `bitfinex_bid` float(20,8) DEFAULT NULL, `bitfinex_ask` float(20,8) DEFAULT NULL, `quoine_bid` float(20,8) DEFAULT NULL, `quoine_ask` float(20,8) DEFAULT NULL, `btcc_bid` float(20,8) DEFAULT NULL, `btcc_ask` float(20,8) DEFAULT NULL, `bitstamp_bid` float(20,8) DEFAULT NULL, `bitstamp_ask` float(20,8) DEFAULT NULL, `exmo_bid` float(20,8) DEFAULT NULL, `exmo_ask` float(20,8) DEFAULT NULL, `okcoin_bid` float(20,8) DEFAULT NULL, `okcoin_ask` float(20,8) DEFAULT NULL, `gdax_bid` float(20,8) DEFAULT NULL, `gdax_ask` float(20,8) DEFAULT NULL, `hitbtc_bid` float(20,8) DEFAULT NULL, `hitbtc_ask` float(20,8) DEFAULT NULL, `poloniex_bid` float(20,8) DEFAULT NULL, `poloniex_ask` float(20,8) DEFAULT NULL, `livecoin_bid` float(20,8) DEFAULT NULL, `livecoin_ask` float(20,8) DEFAULT NULL, `therocktrading_bid` float(20,8) DEFAULT NULL, `therocktrading_ask` float(20,8) DEFAULT NULL, `lakebtc_bid` float(20,8) DEFAULT NULL, `lakebtc_ask` float(20,8) DEFAULT NULL, `itbit_bid` float(20,8) DEFAULT NULL, `itbit_ask` float(20,8) DEFAULT NULL, `gemini_bid` float(20,8) DEFAULT NULL, `gemini_ask` float(20,8) DEFAULT NULL, `huobi_bid` float(20,8) DEFAULT NULL, `huobi_ask` float(20,8) DEFAULT NULL, `quadrigacx_bid` float(20,8) DEFAULT NULL, `quadrigacx_ask` float(20,8) DEFAULT NULL, `bleutrade_bid` float(20,8) DEFAULT NULL, `bleutrade_ask` float(20,8) DEFAULT NULL, `liqui_bid` float(20,8) DEFAULT NULL, `liqui_ask` float(20,8) DEFAULT NULL, `c_cex_bid` float(20,8) DEFAULT NULL, `c_cex_ask` float(20,8) DEFAULT NULL, `ecoin_bid` float(20,8) DEFAULT NULL, `ecoin_ask` float(20,8) DEFAULT NULL, `yobit_bid` float(20,8) DEFAULT NULL, `yobit_ask` float(20,8) DEFAULT NULL, `bter_bid` float(20,8) DEFAULT NULL, `bter_ask` float(20,8) DEFAULT NULL, `binance_bid` float(15,8) DEFAULT NULL, `binance_ask` float(15,8) DEFAULT NULL, `date_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=36 DEFAULT CHARSET=utf8 пробовал выполнить похожий запрос в таком цикле for ($a = 0; $a < 100000; $a++) { $stringMysql = "UPDATE result_for_trading_only_selected_birges SET ct = $a, `amount`= $a,`birge_buy`=null , btce_profit_percent = $totaltime, cex_profit_percent = null, bittrex_profit_percent = null, kraken_profit_percent = null, bitfinex_profit_percent = null, quoine_profit_percent = null, btcc_profit_percent = null, bitstamp_profit_percent = null, exmo_profit_percent = null, okcoin_profit_percent = null, gdax_profit_percent = null, hitbtc_profit_percent = null, poloniex_profit_percent = null, livecoin_profit_percent = null, therocktrading_profit_percent = null, lakebtc_profit_percent = null, itbit_profit_percent = null, gemini_profit_percent = null, huobi_profit_percent = null, quadrigacx_profit_percent = null, bleutrade_profit_percent = null, liqui_profit_percent = null, c_cex_profit_percent = null, ecoin_profit_percent = null, yobit_profit_percent = null, bter_profit_percent = null, binance_profit_percent = null WHERE pair = '$pair';"; try { if (! $mysqli->query($stringMysql)) { echo $mysqli->error . "<br>" . $stringMysql . "<br>"; } } catch (Exception $ex) { echo "ошибка, " . $ex->getMessage(); } } время выполнения 0.1 - 0.2 секунды, но это тоже очень много никаких ошибок, кроме того, что база падает, если запустить сбор котировок со всех бирж, опять таки, причину падения не пишет в лог, но с учетом того, что комп отдельная машина, processor Intel(R) Xeon(R) CPU X3440 @ 2.53GHz memory 16GiB System Memory и полностью исчезает память, причина только в mysql. А вот в чем дело, не могу понять, есть мысли? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2018, 14:32 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
petrovitchможно добавить UNIQUE INDEX на колонку pairЛучше бы сменить тип этого поля на более компактный (TINYINT или VARCHAR(M)) и сделать первичным ключом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2018, 16:48 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
Указание спецификаций точности для float(20,8) тоже вряд ли имеет смысл. Все равно они все 4-байтовые. Но добавляет расходы на контроль значения и, возможно, округление со снижением точности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2018, 16:51 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
petrovitchесли запустить сбор котировок со всех биржКак именно происходит этот процесс? petrovitchmemory 16GiB System Memory и полностью исчезает память, причина только в mysql.Указанными табличкой и запросом не съесть столько ресурсов. Что-то не так происходит где-то за пределами показанного нам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2018, 16:53 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
по cron выполняется 200 запросов к апи бирж каждую секунду в ответах возвращаются json строки пишутся в базу перед записью json конвертируется в массив, лишние поля удаляются, остается по 50 полей в массивах, потом снова преобразуется в строки профилировщиком такой код в скрипте, найдены 3 запроса, выполняющихся больше 1 секунды: $allMethods->writeToDB("SET profiling = 1;", $mysqli, "SET profiling = 1;"); код .... $res = ''; $array = $mysqli->query("show profiles;"); $a = 1; while ($array_2 = mysqli_fetch_assoc($array)) { $res .= serialize($array_2) . "\r\n"; $res .= "show profile for query $a;" . "\r\n"; $array_3 = mysqli_fetch_assoc($mysqli->query("show profile for query $a;")); $res .= serialize($array_3) . "\r\n"; $a++; } $allMethods->writeToLogDebagInfo($res, "serialize(array)"); найдены 3 запроса, которые выполняются больше секунды: UPDATE result_for_trading_only_selected_birges SET `amount`= null,`birge_buy`=null , birge_buy = null, btce_profit_percent = null, cex_profit_percent = null, bittrex_profit_percent = null, kraken_profit_percent = null, bitfinex_profit_percent = null, quoine_profit_percent = null, btcc_profit_percent = null, bitstamp_profit_percent = null, exmo_profit_percent = null, okcoin_profit_percent = null, gdax_profit_percent = null, hitbtc_profit_percent = null, poloniex_profit_percent = null, livecoin_profit_percent = null, therocktrading_profit_percent = null, lakebtc_profit_percent = null, itbit_profit_percent = null, gemini_profit_percent = null, huobi_profit_percent = null, quadrigacx_profit_percent = null, bleutrade_profit_percent = null, liqui_profit_percent = null, c_cex_profit_percent = null, ecoin_profit_percent = null, yobit_profit_percent = null, bter_profit_percent = null, binance_profit_percent = null , `timestamp`=UNIX_TIMESTAMP(now()), `datetime`=now(), `time_execute`=0.21234673 WHERE pair = 'usd_btc' UPDATE `courses_for_trading` SET buy_courses= null , buy_courses = null, btce_courses = null, cex_courses = null, bittrex_courses = null, kraken_courses = null, bitfinex_courses = null, quoine_courses = null, btcc_courses = null, bitstamp_courses = null, exmo_courses = null, okcoin_courses = null, gdax_courses = null, hitbtc_courses = null, poloniex_courses = null, livecoin_courses = null, therocktrading_courses = null, lakebtc_courses = null, itbit_courses = null, gemini_courses = null, huobi_courses = null, quadrigacx_courses = null, bleutrade_courses = null, liqui_courses = null, c_cex_courses = null, ecoin_courses = null, yobit_courses = null, bter_courses = null, binance_courses = null , `timestamp`=UNIX_TIMESTAMP(now()), `datetime`=now() WHERE pair = 'usd_btc' UPDATE `courses_from_glases` SET btce_ask = null, cex_bid = null, cex_ask = null, bittrex_bid = null, bittrex_ask = null, kraken_bid = null, kraken_ask = null, bitfinex_bid = null, bitfinex_ask = null, quoine_bid = null, quoine_ask = null, btcc_bid = null, btcc_ask = null, bitstamp_bid = null, bitstamp_ask = null, exmo_bid = null, exmo_ask = null, okcoin_bid = null, okcoin_ask = null, gdax_bid = null, gdax_ask = null, hitbtc_bid = null, hitbtc_ask = null, poloniex_bid = null, poloniex_ask = null, livecoin_bid = null, livecoin_ask = null, therocktrading_bid = null, therocktrading_ask = null, lakebtc_bid = null, lakebtc_ask = null, itbit_bid = null, itbit_ask = null, gemini_bid = null, gemini_ask = null, huobi_bid = null, huobi_ask = null, quadrigacx_bid = null, quadrigacx_ask = null, bleutrade_bid = null, bleutrade_ask = null, liqui_bid = null, liqui_ask = null, c_cex_bid = null, c_cex_ask = null, ecoin_bid = null, ecoin_ask = null, yobit_bid = null, yobit_ask = null, bter_bid = null, bter_ask = null WHERE pair = 'usd_btc' вот только почему так долго, непонятно, по моему для таких запросов время выполнения 0.001 сек. нормально, а 1 сек. абсолютно не нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2018, 18:05 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
Теоретически не съесть. А на практике получается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2018, 18:06 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
miksoft, Тип поля изменил на varchar(15), на первичный ключ изменить не получается, ALTER TABLE `result_for_trading_only_selected_birges` ADD PRIMARY KEY(`pair`); ошибка Некорректное определение таблицы: может существовать только один автоинкрементный столбец, и он должен быть определен как ключ. Изменений во времени исполнения нет. По моему проблема во времени | updating | 0.135657 | | query end | 0.291808 | и query end по моему висят в памяти в большом количестве. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2018, 19:06 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
petrovitchна первичный ключ изменить не получается,Так и не получится. Лучше дропнуть таблицу и создать ее заново. Кстати, раз вы постоянно переписываете таблицу, то имеет смысл сделать ее на движке MEMORY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2018, 13:04 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
Сделал таблицы на движке MEMORY. С тремя проблемными запросами проблема решилась. Большое спасибо! Осталась проблема с таблицами, которые пока не переделать на MEMORY из-за типов полей. Думаю, как решить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2018, 23:26 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
petrovitchОсталась проблема с таблицами, которые пока не переделать на MEMORY из-за типов полей.Поменять типы не предлагать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2018, 00:21 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
petrovitchпо cron выполняется 200 запросов к апи бирж каждую секунду я все правильно понял, каждую секунду делается 200 запросов к стороннему API и все сохраняется в БД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2018, 09:01 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
а может всё-таки нормализацию сделать: id type bid_ask value ? а ещё вариант - в редиске это всё держать, если значения только последние нужны ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2018, 13:48 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
miksoft, рад бы поменять, но никак ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2018, 19:19 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
Дегтярев Евгений, совершенно верно, есть варианты? как в память минуя базу грузить и там делать вычисления? на самом деле нужны мгновенные данные, через секунду они уже неактуальны, в базе будут перезаписаны update ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2018, 19:21 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
tip78, в редиске это всё держать, отлично у нее быстродействие намного выше mysql есть примеры? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2018, 19:22 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
petrovitchесть примеры? в гугле полно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2018, 20:17 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
petrovitchкак в память минуя базу грузить и там делать вычисления? на самом деле нужны мгновенные данные, через секунду они уже неактуальны, в базе будут перезаписаны updateА в таком случае нужна ли вообще база? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2018, 20:28 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
miksoft, нужна, но часть таблиц, поля в которых только обновляются, и нужны в текущую секунду, их то как раз можно держать в оперативке, как с таблицами на движке memory ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.06.2018, 21:28 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
petrovitchсовершенно верно, есть варианты? как в память минуя базу грузить и там делать вычисления? на самом деле нужны мгновенные данные, через секунду они уже неактуальны, в базе будут перезаписаны update по мне так rest интерфейс странное решение для поставщика ликвидности... зато стильномодномолодежно плюс, подозреваю, что содержимое БД перезаписывает без проверки, а поменялись ли реально данные доставка до клиента текущих котировок должна быть без участия БД, типа - сервис, который забирает котировки у поставщика, какая-то предобработка, запись истории (если нужно), плюс интерфейс для других сервисов, собственно основная задача сервиса привести форматы поставщиков к общему знаменателю - сервис(ы) доставки до клиента (tcp, rest, websocket и т.д.), которые в реальном времени получают данные от первого сервиса конвертируют в формат клиента и отправляют клиенту... тот же могут быть другие обработки, например, отправка раз в секунду, или отправка только нужных клиенту котировок... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2018, 07:08 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
Дегтярев Евгений, Здравствуйте, нет ли примера? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2018, 10:59 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
petrovitch, не видел чтобы такое выкладывали ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2018, 11:30 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
Дегтярев Евгенийpetrovitchсовершенно верно, есть варианты? как в память минуя базу грузить и там делать вычисления? на самом деле нужны мгновенные данные, через секунду они уже неактуальны, в базе будут перезаписаны update по мне так rest интерфейс странное решение для поставщика ликвидности... зато стильномодномолодежно плюс, подозреваю, что содержимое БД перезаписывает без проверки, а поменялись ли реально данные доставка до клиента текущих котировок должна быть без участия БД, типа - сервис, который забирает котировки у поставщика, какая-то предобработка, запись истории (если нужно), плюс интерфейс для других сервисов, собственно основная задача сервиса привести форматы поставщиков к общему знаменателю - сервис(ы) доставки до клиента (tcp, rest, websocket и т.д.), которые в реальном времени получают данные от первого сервиса конвертируют в формат клиента и отправляют клиенту... тот же могут быть другие обработки, например, отправка раз в секунду, или отправка только нужных клиенту котировок... зачем всё усложнять проверку вообще-то делает UPDATE, если данные те же, он не происходит. А в случае с редиской он вообще не нужен. доставки до клиента нет, есть веб-страница ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2018, 13:09 |
|
||
|
долгое время выполнения всех запросов, падение базы
|
|||
|---|---|---|---|
|
#18+
tip78зачем всё усложнять для наколенной поделки - да усложнение, в реальном продукте, поверьте, нет авторпроверку вообще-то делает UPDATE, если данные те же, он не происходит. а что происходит до того как update непосредственно начнет делать проверку и сразу после? автордоставки до клиента нет, есть веб-страница 1 это тоже доставка 2 не будем фантазировать за автора ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2018, 14:13 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39659827&tid=1829796]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
46ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
| others: | 15ms |
| total: | 165ms |

| 0 / 0 |
