|
| Дата |
|
USD/RUB | 93.4409 | BTC/USD | 66447.0708 |
|
|
|
Скрипты, программы и технические решения Обсуждаем скрипты, программы и новые технологии. |
29.09.2012, 09:28
|
#1
|
Senior Member
Регистрация: 19.04.2007
Сообщений: 2,393
Бабло: $314345
|
Спецы по MySQL и сила гофака! Нужна помощь!
Привет всем, а реально крутым специалистам по MySQL особенно
Предыстория:
Жил-был на обычном виртуальном хостинге oscommerce шоп, в базе которого примерно 1.5к товаров, жил не тужил более 1.5 лет, нагрузка от него была такая:
Код:
Дата CPU MySQL
2012-09-12 19 158
2012-09-11 20 165
2012-09-10 17 150
2012-09-09 15 134
2012-09-08 16 137
2012-09-07 18 153
2012-09-06 18 186
2012-09-05 18 172
2012-09-04 19 160
2012-09-03 16 119
2012-09-02 15 124
2012-09-01 12 124
Данная нагрузка вписывалась в лимиты хостинга (500 единиц по MySQL в день) и все было круто. Но 13 сентября была внедрена крутая идея, сделать тотальную распродажу, запихнув все 1.5к товаров в таблицу specials (в которой и содержатся товары со спец ценой).
После этого, нагрузка выросла просто в дичайшие разы:
Код:
Дата CPU MySQL
2012-09-28 23 784
2012-09-27 25 906
2012-09-26 27 1055
2012-09-25 19 794
2012-09-24 26 1002
2012-09-23 24 897
2012-09-22 25 971
2012-09-21 27 1189
2012-09-20 23 921
2012-09-19 26 1283
2012-09-18 29 1691
2012-09-17 34 2005
2012-09-16 24 1467
2012-09-15 18 809
2012-09-14 25 1172
2012-09-13 24 382
Проблема в том, что такая нагрузка уже не вписывается в лимит хостинга, даже в самый дорогой, и предлагается переехать на vps или дедик, что бессмысленно, если учесть, что шоп дает больше интереса, чем денег, да и возни, понятное дело, будет в разы больше.
Соответственно, спустя несколько дней (17 числа, кажется), распродажа завершается, полностью удаляются все распродажные товары из таблицы specials, распродажные цены устанавливаются всем товарам на постоянку, все, казалось бы, возвращается к тому же, с чего началось (только с измененными ценами), но вот незадача - нагрузка не вернулась к старым значениям почему-то, и продолжает оставаться стабильно очень высокой! Да, кстати. Дней 5 назад был активирован кеш, который ранее вообще не включался (я даже не знал, что он есть в движке), но это, как видно, не помогло.
Внимание, вопросы к специалистам
1) Из-за чего могло такое случиться, что после удаления изменений, нагрузка все равно осталась запредельной?
2) Могло ли что-то зависеть от того, каким способом добавлялись товары в таблицу specials или менялись массово цены у товаров? Я написал небольшой скрипт для этого, а т.к. я с MySQL знаю буквально SELECT и WHERE, может че не так в запросах было, о чем я не в курсе, что может как-то закосячить базу или типа того? Вот, собственно, скрипт:
PHP код:
<?php
set_time_limit(0);
$dbu = array('host' => '', 'dbname' => '', 'user' => '', 'pass' => '');
$db = mysql_connect($dbu['host'], $dbu['user'], $dbu['pass']) or die('Не могу сконнектиться к БД'); mysql_select_db($dbu['dbname'], $db) or die('БД не найдена');
mysql_query("SET NAMES 'cp1251'");
$sql = 'SELECT `products_id`, `products_base_price`, `products_price` FROM `products` WHERE `products_base_price` != 0 AND `products_status` != 0'; $result = mysql_query($sql);
while($row = mysql_fetch_assoc($result)) { if ($row['products_base_price'] <= 10) { $koeff = 2; } elseif ($row['products_base_price'] <= 20) { $koeff = 1.5; } elseif ($row['products_base_price'] <= 30) { $koeff = 1; } else { $koeff = 0.5; } $new_price = round($row['products_base_price'] + $row['products_base_price'] * $koeff); if ($new_price >= $row['products_price']) { $new_price = round($row['products_price'] - $row['products_price'] * 0.1); } #если надо добавить спец предложение, а не изменить цены у товаров #$sql2 = 'INSERT INTO `specials` (`specials_id`, `products_id`, `specials_new_products_price`, `specials_date_added`, `specials_last_modified`, `expires_date`, `date_status_change`, `status`) VALUES ("", "'.$row['products_id'].'", "'.$new_price.'", "'.date('Y-m-d H:i:s').'", NULL, NULL, NULL, "1");'; #если надо массово изменить цены у товаров $sql2 = 'UPDATE `products` SET `products_price` = '.$new_price.' WHERE `products_id` = '.$row['products_id']; $result2 = mysql_query($sql2); } ?>
З.Ы. Вы даже не представляете, как я надеюсь на гофак))
|
|
|
29.09.2012, 10:04
|
#2
|
Senior Member
Регистрация: 05.01.2008
Сообщений: 1,676
Бабло: $213930
|
ну чтоб не гадать на кофеной гуще надо сделать примерно вот так
http://habrahabr.ru/post/31072/
ну или попросить вменяемого хостера
|
|
|
29.09.2012, 10:12
|
#3
|
Senior Member
Регистрация: 19.04.2007
Сообщений: 2,393
Бабло: $314345
ТС -->
|
ТС
Цитата:
Сообщение от creator123
|
Блин, сорри, я забыл сразу написать, я просил у хостера показать запросы, которые нагружают базу, вот что он прислал:
Код:
1)
select p.products_image, pd.products_name, p.products_id, p.manufacturers_id, p.products_price, p.products_tax_class_id, IF(s.status, s.specials_new_products_price, NULL) as specials_new_products_price, IF(s.status, s.specials_new_products_price, p.products_price) as final_price from products_description pd, products p left join manufacturers m on p.manufacturers_id = m.manufacturers_id left join specials s on p.products_id = s.products_id, products_to_categories p2c where p.products_status = '1' and p.products_id = p2c.products_id and pd.products_id = p2c.products_id and pd.language_id = '1' and p2c.categories_id = '4' order by pd.products_name limit 0, 21;
2)
select count(*) as total from products p, products_to_categories p2c where p.products_id = p2c.products_id and p.products_status = '1 ' and p2c.categories_id = '39';
Это самые обычные запросы oscommerce, которые были со дня основания базы, в них ничего не менялось.
Я делал только то, что описал в первом посте:
1) сделал распродажу, добавив все 1.5к товаров в таблицу specials
2) затем удалил все добавленное и у всех продуктов в обычной таблице products поменял массово цены
Все. Больше ничего не менялось.
|
|
|
29.09.2012, 10:21
|
#4
|
Bitcoin to the moon!
Регистрация: 19.10.2008
Адрес: горный аул
Сообщений: 2,202
Бабло: $519970
|
specials сейчас пустая?
|
|
|
29.09.2012, 10:21
|
#5
|
Senior Member
Регистрация: 05.01.2008
Сообщений: 1,676
Бабло: $213930
|
теперь запихай эти запросы поочереди в phpmyadmin
выполни, а потом тыкни "Explain SQL"
оно покажет о чем думало, и чем занималось так долго.
|
|
|
29.09.2012, 10:27
|
#6
|
Ебланнед
Регистрация: 30.03.2012
Сообщений: 176
Бабло: $177310
|
для начала, чтобы убедиться, что это не скрипт косячит, зайди в сам мускуль и поюзай те селекты, от которых тормоза
команда: mysql -u root -p
до кучи можно ещё BENCHMARK задействовать (выполняет команду неск.раз):
SELECT BENCHMARK(10,(SELECT blablabla))
Последний раз редактировалось Алёша; 29.09.2012 в 10:34.
|
|
|
29.09.2012, 12:50
|
#7
|
private.
Регистрация: 30.04.2008
Сообщений: 3,864
Бабло: $462680
|
в oscommerce есть хотя-бы элементарное кеширование ? может есть смысл включить его.
|
|
|
29.09.2012, 13:42
|
#8
|
white powder
Регистрация: 29.04.2007
Сообщений: 2,692
Бабло: $370670
|
я конкретно с MySQL почти не работал, но не могли при удалении товаров и индексы по таблицам убиться?
|
|
|
29.09.2012, 19:05
|
#9
|
Senior Member
Регистрация: 19.04.2007
Сообщений: 2,393
Бабло: $314345
ТС -->
|
ТС
Цитата:
Сообщение от rusawm
specials сейчас пустая?
|
Практически да, там буквально штуки 3 товара, как обычно и бывало в течении всей жизни магазина.
Цитата:
теперь запихай эти запросы поочереди в phpmyadmin
выполни, а потом тыкни "Explain SQL"
оно покажет о чем думало, и чем занималось так долго.
|
Ок, попробую.
Цитата:
в oscommerce есть хотя-бы элементарное кеширование ? может есть смысл включить его.
|
См. в первом посте: Да, кстати. Дней 5 назад был активирован кеш, который ранее вообще не включался (я даже не знал, что он есть в движке), но это, как видно, не помогло.
Цитата:
но не могли при удалении товаров и индексы по таблицам убиться?
|
Хз, даже не знаю, что за индексы. Как это проверить?
|
|
|
29.09.2012, 19:19
|
#10
|
Ебланнед
Регистрация: 30.03.2012
Сообщений: 176
Бабло: $177310
|
Цитата:
Сообщение от DimaX
Хз, даже не знаю, что за индексы. Как это проверить?
|
use base_name;
describe table_name;
смотришь, есть ли там PRI в колонке 'key'
но при такой маленькой базе индексы не решают
|
|
|
|