LINUX.ORG.RU
ФорумAdmin

MYSQL и большие таблицы

 ,


2

3

Друзья. Прошу помощи. Попытался залить в магазин 66500 товаров через импорт. сервак после заливки грузит по несколько минут страницы, зависает весь сервак, до тех пор пока не откатишь содержимое базы назад.... база становится весить всего-то 85 метров в общей сложности, ну таблица самая тяжелая около 30 метров, многие в интернете расписывают про суперскую работу MYSQL с базами где гигабайты данных

а у меня такая вот беда

не могу понять что не так на сервере но грешу на MYSQL, так как вижу зависшие там запросы и возможно не совсем верные его настройки

MYSQL  	
mysql-server-5.5-5.5.40-0+wheezy1
КОНФИГ
[client]
port		= 3306
socket		= /var/run/mysqld/mysqld.sock


[mysqld_safe]
socket		= /var/run/mysqld/mysqld.sock
nice		= 0

[mysqld]

user		= mysql
pid-file	= /var/run/mysqld/mysqld.pid
socket		= /var/run/mysqld/mysqld.sock
port		= 3306
basedir		= /usr
datadir		= /var/lib/mysql
tmpdir		= /tmp
lc-messages-dir	= /usr/share/mysql
skip-external-locking


key_buffer		= 256M
max_allowed_packet	= 32M
thread_stack		= 192K
thread_cache_size       = 8


myisam-recover         = BACKUP
max_connections = 300
table_open_cache = 1024
join_buffer_size  = 4M
tmp_table_size = 128M
max_heap_table_size = 128M
wait_timeout  = 100
interactive_timeout = 100
connect_timeout  = 100

#InnoDB
innodb_buffer_pool_size = 1024M
innodb_thread_concurrency = 16
innodb_additional_mem_pool_size=50M
innodb_flush_log_at_trx_commit=2
innodb_log_buffer_size=32M

#MyISAM
myisam_max_sort_file_size=50G
myisam_sort_buffer_size=256M
key_buffer_size=256M
read_buffer_size = 256K
read_rnd_buffer_size = 512K
sort_buffer_size=256K 
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit	= 4M
query_cache_size        = 32M

expire_logs_days	= 10
max_binlog_size         = 100M




[mysqldump]
quick
quote-names
max_allowed_packet	= 16M

[mysql]
#no-auto-rehash	# faster start of mysql but no tab completition

[isamchk]
key_buffer		= 16M

!includedir /etc/mysql/conf.d/

1. innodb_file_per_table, сбэкапить, грохнуть /var/lib/mysql/* и залить заново.

2. innodb_buffer_pool_size = 1024M - сколько памяти на серваке?

3.

SELECT ( @@key_buffer_size
+ @@query_cache_size
+ @@innodb_buffer_pool_size
+ @@innodb_additional_mem_pool_size
+ @@innodb_log_buffer_size
+ @@max_connections * ( @@read_buffer_size
+ @@read_rnd_buffer_size
+ @@sort_buffer_size
+ @@join_buffer_size
+ @@binlog_cache_size
+ @@thread_stack
+ @@tmp_table_size )
) / (1024 * 1024 * 1024) AS MAX_MEMORY_GB;

Вот у меня как раз хватает (16G). А у тебя с key_buffer_size в четверть гига и tmp_table 128M- сам подумай, что получиться.

svr4 ()
Последнее исправление: svr4 (всего исправлений: 1)
Ответ на: комментарий от Radjah

база там обычного магазина

наименование и категория с подкатегориями

просто товаров 65 тысяч

сайтов крутится много все летают и нагрузки никакой почти

а тут строчек много вышло в базе и виснет когда откатываю назад все ок

eclipseg ()
Ответ на: комментарий от eclipseg

3. Ну так снижай, чтоб было 16.

2. Если база именно с innodb - поднимай innodb_buffer_pool_size. После выполнения пункта 3, разумеется.

0. Чем накатываешь новые товары-то?

svr4 ()
Последнее исправление: svr4 (всего исправлений: 1)
Ответ на: комментарий от svr4

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

конкретно эти таблицы в MyISAM

eclipseg ()
Ответ на: комментарий от svr4

да там популярные Virtuemart 2 + joomla 2.5 у человека пробовал через импорт экспорт залить товары, заливаются потом делал на локалке удалял базу на серваке заливал по новой...пользы не дало

eclipseg ()
Ответ на: комментарий от pi11

да нет вроде, все там по дефолту, не самопис, запросы не ковырял

может версию движка поднять попробовать глядишь пользу даст

eclipseg ()

Конфига почти вся дефолтная. Не было смысла ее выкатывать. Кэш для MyISAM-индексов, кстати, у MySQL довольно шустро работает, но я вангую что дело только в вашем запросе.

В треде:

сервак после заливки грузит по несколько минут страницы,

ну дак и покажите sql-запросы для этих самых «страниц», тогда и причина будет ясна сразу, причем здесь кол-во пашнутых вами записей в базу?

конкретно эти таблицы в MyISAM

тем более. может у вас там запрос на SELECT * FROM {your_table}, а в таблицах кучи BLOB данных, тогда, естественно, что будет все тормозить. Тут же не телепаты, все-таки :)

Вообщем, запрос(ы) + схему таблиц(ы) в студию.

znenyegvkby ()
Ответ на: комментарий от znenyegvkby

ок, запросы и структуру все приложу это растянется чуточку, ночью займусь а то много сайтов встанет :)

завтра продолжим или ночью тогда

спасибо за ответы всем

eclipseg ()
Ответ на: комментарий от pi11

Сори, раньше коммент писал, только увидел. Все верно сказал - давай схемы таблица + запросы.

znenyegvkby ()
Ответ на: комментарий от eclipseg

Сори, этот коммент тоже добавился после. Не видел.

да там популярные Virtuemart 2 + joomla 2.5

Тогда не имеет смысла выкатывать что-либо. Уже яснопонятно=( Скачал сейчас Virtuemart 2.0.14, поглядел схемы в install/install.sql и код в components. Стало интересно, скачал саму Joomla. На скорую руку прошурстил код. Жирные контроллеры доставили конечно=) Общая оценка - 0 баллов из 10.

Единственный совет от меня - удалить к епеням это, и, если нравится PHP - заюзать Yii/Symphony/любой не режущий глаза MVC-фреймворк.

znenyegvkby ()

А индексы в таблицах точно есть?

MrClon ★★★★★ ()
Ответ на: комментарий от eclipseg

Дело не в версии. Сам факт Joomla/Virtuemart - вот в чем проблема. Не стыкуется он с изначальным условием

Попытался залить в магазин 66500

Я прошурстил код, судя по нему, чтобы эта паста держала 66к (при учете связанных сущностей в базе) ей нужна машина с не менее чем 8CPU по 2.7, допустим, и, соответственно, восьмерки рамы.

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

Из вышесказанного и вердикт

Единственный совет от меня - удалить к епеням это, и, если нравится PHP - заюзать Yii/Symphony/любой не режущий глаза MVC-фреймворк.

znenyegvkby ()
Ответ на: комментарий от znenyegvkby

выходит дело совсем не в серваке :( и выходит, что mysql не тянет 66500 тыс строчек

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

eclipseg ()
Ответ на: комментарий от eclipseg

выходит дело совсем не в серваке :( и выходит, что mysql не тянет 66500 тыс строчек

тебе же выше написали, что проблема в Joomla/Virtuemart
Мускул отлично работает с гагабайтными таблами, при учете правильного конфига, запросов и использования индексов

kiotoze ★★★★ ()
Ответ на: комментарий от eclipseg

выходит, что mysql не тянет 66500 тыс строчек

5-10 млн. строк тянет без особых ухищрений на среднем железе с временем отклика в сотые доли секунды. С прямыми руками и на не жутких запросах — и 100 млн. потянет.

KRoN73 ★★★★★ ()
Ответ на: комментарий от eclipseg

на 100 000 тыс таблиц например и запрос к ним)
таблиц

надеюсь вы словом ошиблись

anc ★★★★★ ()
Ответ на: комментарий от znenyegvkby

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

Из вышесказанного и вердикт

Странный вердикт какой-то. Разве что-то мешает создать нужные индексы?

Tigger ★★★★★ ()
Ответ на: комментарий от eclipseg

чем можно тест провести? на 100 000 тыс таблиц например и запрос к ним) убедится что с базой все ок

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

MariaDB [REVIVE]> select zone_id, count(*) from ox_data_summary_ad_zone_assoc group by zone_id;
+---------+----------+
| zone_id | count(*) |
+---------+----------+
|       0 |    37290 |
|       8 |    67525 |
|       9 |   228829 |
|      13 |     1555 |
|      14 |   104012 |
|      17 |    42329 |
|      21 |    15147 |
|      22 |    87543 |
|      24 |      801 |
|      25 |    18360 |
|      27 |      801 |
|      30 |    15147 |
|      32 |      801 |
|      33 |    15147 |
|      35 |        9 |
|      39 |      809 |
|      41 |    15148 |
|      43 |      801 |
|      56 |      801 |
|      57 |      801 |
|      58 |     5971 |
|      66 |      801 |
|      67 |      494 |
|      70 |    15147 |
|      78 |   120749 |
|      83 |    27862 |
|      87 |    83600 |
|      93 |    82171 |
|      96 |    68718 |
|     102 |    65748 |
|     109 |    26539 |
|     110 |       19 |
|     111 |        4 |
|     112 |    13008 |
|     113 |  1258899 |
|     114 |   706274 |
|     119 |  1147171 |
|     123 |        9 |
|     124 |   904109 |
+---------+----------+
39 rows in set (14.87 sec)

MariaDB [REVIVE]> select count(*) from ox_data_summary_ad_zone_assoc;                                                                       +----------+
| count(*) |
+----------+
|  5180949 |
+----------+

KRoN73 ★★★★★ ()
Ответ на: комментарий от Tigger

Разве что-то мешает создать нужные индексы?

Чтобы индексы эффективно работали, часто запросы нужно строить продуманно. Это две стороны одной оптимизации.

KRoN73 ★★★★★ ()
Ответ на: комментарий от Tigger

Нормальный вердикт. Структура БД и запросы могут быть такими, что добавление индексов не изменит ситуацию, а может и привести к худшим результатам.

anc ★★★★★ ()
Ответ на: комментарий от KRoN73

Противоречите себе:

5-10 млн. строк тянет без особых ухищрений на среднем железе с временем отклика в сотые доли секунды

и

5180949 - 14.87 sec

Конечно 14.87 sec это некоторое кол-во сотен долей секунды, но все-таки :)

anc ★★★★★ ()
Ответ на: комментарий от KRoN73

Чтобы индексы эффективно работали, часто запросы нужно строить продуманно. Это две стороны одной оптимизации.

Согласен. Но было заявление об индексах, а их как раз вполне можно довести до ума. И при обновлениях вряд ли поломаются. А потерять свои оптимизированные запросы при обновлениях очень легко.

Tigger ★★★★★ ()
Ответ на: комментарий от anc

Структура БД и запросы могут быть такими, что добавление индексов не изменит ситуацию, а может и привести к худшим результатам.

Всё может быть, но а этом случае создателей стоит обвинять не в неумении пользоваться индексами, а в незнании основ.

Tigger ★★★★★ ()
Ответ на: комментарий от Tigger

Не было никаких конкретных заявлений в отрыве от контекста. Я проскролил схемы (кстати, там в комменте есть ссыль, можете посмотреть их сами в install/install.sql), не увидел адекватного применения индексов (окромя PK, но этого уже только мертвый не знает), на что написал

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

После этого проскролил сам код, увидел такие же неадекватные запросы, и сделал вывод

Единственный совет от меня - удалить к епеням это, и, если нравится PHP - заюзать Yii/Symphony/любой не режущий глаза MVC-фреймворк.

Все. Ни больше ни меньше.

znenyegvkby ()
Ответ на: комментарий от Tigger

Всё может быть, но а этом случае создателей стоит обвинять не в неумении пользоваться индексами, а в незнании основ.

Ну дак я именно это и сделал, на что вы возразили

Странный вердикт какой-то. Разве что-то мешает создать нужные индексы?

znenyegvkby ()
Ответ на: комментарий от Tigger

znenyegvkby и написал

А из схемы таблиц понятно...

что можно читать как «незнание основ», может он решил соблюсти «политкорректность» и не называть дураков - дураками :)

anc ★★★★★ ()
Ответ на: комментарий от anc

Off-topic

и не называть дураков - дураками

Заинтересовался этой темой, и глянул рейтинг рунета. Для себя еще раз убедился в правильности высказывания

Хочешь жить - умей вертеться.

У большинства мелких ИПэшников просто напросто нет возможностей для найма программистов. Что уж об этом говорить, если те же недопрограммисты1С-ники по любым сайтам вакансий дерут нехилые для страны деньги. А потом люди удивляются - почему у нас в стране в данной области такая каша, и орут с Ъ-подобных запросов, типа, «Jajaja, ломанул {недосайт}, бизопасности 0, я кулцхэкер, jajaja» и т.д. и т.п.

Я недавно зарегался, но ЛОР читаю давно, не смогу сейчас найти, но где-то Царь высказал довольно внятную мысль об этом. Не дословно, конечно, но примерно звучит так

культура программирования в рашке не развита от слова совсем

Вот я и подумал, что основная задача, развивать эту самую «культуру». ЛОР, кстати, этим помогает, но жаль что это не расходится дальше узкого круга, основная масса не верит в компьютеризацию все-таки=)

P.S. Модеры, сразу сори за пасту в admin. Бомбануло, вестимо :) Если что, можно сносить=)

znenyegvkby ()
Ответ на: комментарий от pawnhearts

Вброшу: галактика. Это не более чем вброс.

anc ★★★★★ ()
Ответ на: комментарий от pawnhearts

И снова off-topic

А что ты предлагаешь в качестве альтернативы 1С?

Предлагаю развить «культуру» о которой я написал выше, после этого устранить «Ж» в стране, и создать условия для реального «импортозамещения». Мы находимся на ЛОР'е, ЕМНИП. У нас в руках кучи свободного ПО, ЯП, концепций, алгоритмов и т.д. по контексту.

Конкретно в данном контексте, в качестве альтернативы 1С я вижу только возможность каждой конкретной N-фирмы нанимать квалифицированных программистов, и решать траблы отталкиваясь от конкретных задач, а не пытаться (как в случае с 1С) подогнать все предприятия под одну гребенку, и, как следствие, нанимать тучи неквалифицированных 1С-ников, точащих какие-то там конфиги под конкретную организацию.

Вы не увидите такую практику в странах, где технологии действительно развиты (ИМХО). Я вот, лично, точно не видел. У меня пару знакомых прогеров за бубежом сидят, один из них бегает по фирмам, в поисках выгоды. Он говорит что там, для фирмы, нет особой проблемы, чтобы нанять более-менее грамотного программиста (пусть даже того же PHP-ника), который на любом известном фреймворке, за пару недель напишет адекватное решение для фирмы (я говорю в контексте web'а сейчас). Причем, учитываю «грамотность», любое дополнение/масштабируемость проекта/etc не вызывает никаких проблем.

Конечно, это только моё ИМХО, и лично моя утопия. Но вы задали вопрос - я ответил. Я вижу решение, что представил выше, единственно правильным для себя. А все 1С-подобные фирмы, как раз на безграмотности страны и наживаются. Всегда думал, что такие проекты, как ЛОР, как раз и нужны для того, чтобы хоть немного бить по рукам «злу». Если вам интересна эта тема, предлагаю без оффтопа кануть в переписку :) (znenyegvkby@gmail.com)

znenyegvkby ()
Ответ на: комментарий от znenyegvkby

Похоже Вы не в курсе в чем одна из «прелестей» 1С. Это апдэйты, которые следуют нашим частым изменениям в законодательстве. Забугорных аналогов хватает, но что от них толку если для поддержания всей этой кучи: «отчетность», «классификаторы» и т.д. нужно поддерживать все в актуальном состоянии. А для этого пришлось бы нанимать не только программистов но и тех кто будет за этим следить (изменения) и далеко не каждая контора (даже не маленькая) может себе такое позволить.
Я сам (как и многие программисты) в 90-х велосипедил, но вот с такой частотой менять все как-то со всеменем задолбало всех. Так что такие как галактика и 1с вполне себе «импортозамещение» тем более 1с (имхо) все больше делает для возможности запуска на нативных платформах.

Он говорит что там, для фирмы, нет особой проблемы, чтобы нанять более-менее грамотного программиста (пусть даже того же PHP-ника), который на любом известном фреймворке, за пару недель напишет адекватное решение для фирмы (я говорю в контексте web'а сейчас).

Примеры стран в студию. А то у меня немного другая инфа, не так давно знакомая из Сингапа наоборот искала вэбера желательно из России - причина «наши ответственней».

anc ★★★★★ ()
Ответ на: комментарий от znenyegvkby

Я 1С никогда не видел, но предполагаю что она решает какие-то типовые задачи организаций типа ведения бухгалтерии, составление каких-то отчетов для всяких инстанций, учет. Зачем это переизобретать всё заново в каждой организации, да ещё непрерывно обновлять и саппортить т.к. формы всяких этих отчетов могут меняться?

неквалифицированных 1С-ников, точащих какие-то там конфиги под конкретную организацию.

А если бизнес задачи огранизации при этом решаются и сравнительно недорого?

квалифицированных программистов

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

pawnhearts ★★★★★ ()
Ответ на: комментарий от anc

Блин, опять... (off-topic)

Похоже Вы не в курсе в чем одна из «прелестей» 1С.

Как в том анекдоте? :) Пробиваем отчеты old-date, и т.п. :) 1С - типичный генератор говна с единственной целью - сбор бабла. Да, это ИМХО, но я отталкиваюсь не от своих банальных рассуждений, а от практики фирм, в которых работал, иначе промолчал бы.

Забугорных аналогов хватает

Они для таких как мы и созданы

Так что такие как галактика и 1с вполне себе «импортозамещение»

Это нажива ради бабла, но никак не «импортозамещение» (ИМХО, конечно).

Примеры стран в студию.

USA :) Я ж не могу вам выкатить чужой код, не комильфо же :) Но там эти проблемы не имеют такого «ахтунг»-статуса. Вы правильно подметили

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

Я об этом и сказал выше. Такие фирмы как 1С - просто на этом наживаются. Это проблема государственного строя, но мы ведь на ЛОР'е сидим, для нас то это не проблема :)

znenyegvkby ()
Ответ на: комментарий от pawnhearts

Зачем это переизобретать всё заново в каждой организации, да ещё непрерывно обновлять и саппортить т.к. формы всяких этих отчетов могут меняться?

Квалифицированный программист, как раз, это и не изобретает. Перед ним стоит задача - создать квартальный отчет за {любой N-период}, с определенными условиями, и, для конкретной организации. Он, отталкиваясь от нормальной практики, просто наследуется от своего абстрактного {Report} и пишет конкретный код для решения задачи, а не пыхтит над унифицированной 1С конфигурацией.

А если бизнес задачи огранизации при этом решаются и сравнительно недорого?

Опять же, ориентируюсь на выше сказанные мною слова. Ну нет там никаких «дорого». Для нормального прогера эти задачи не могут быть «дорогими», ибо, как показывает практика, основная проблема - это архитектура проекта, но никак не конкретный код.

Их мало, сложно найти, они хотят хорошие деньги, к ним надо приставлять специфичного айти-менеджера, тестеров и т.п.

Я об этом и сказал выше

Предлагаю развить «культуру» о которой я написал выше, после этого устранить «Ж» в стране, и создать условия для реального «импортозамещения».

znenyegvkby ()
Ответ на: комментарий от znenyegvkby

Я об этом и сказал выше. Такие фирмы как 1С - просто на этом наживаются. Это проблема государственного строя, но мы ведь на ЛОР'е сидим, для нас то это не проблема :)

Это как раз и проблема. Когда-то, я сам отказался поддерживать свои самописки из-за этого. Когда-то, работая в крупной компании с большим облегчением вздохнул после того как самописку нашего отдела, заменили на другую НО она была у компании на аутсорсе и нас это перестало касаться.
С точки зрения пользователей, мата на 1с я давно не слышал. Хотя меня это не особо и касается но имхо услышал бы в любом случае.
ЗЫ Ну а если «вам мама подарила на новый год компьютер» (с) Попробуйте реализовать проект такого же масштаба, никто вам не запрещает - озолотитесь.

anc ★★★★★ ()
Ответ на: комментарий от znenyegvkby

Квалифицированный программист, как раз, это и не изобретает. Перед ним стоит задача - создать квартальный отчет за {любой N-период}, с определенными условиями, и, для конкретной организации. Он, отталкиваясь от нормальной практики, просто наследуется от своего абстрактного {Report} и пишет конкретный код для решения задачи, а не пыхтит над унифицированной 1С конфигурацией.

Угу, в то время как «Квалифицированный программист» «просто наследуется от своего абстрактного {Report}» - «бухгалтер» уже давно нажал одну кнопку в 1с и занялся другими делами.

Для нормального прогера эти задачи не могут быть «дорогими», ибо, как показывает практика, основная проблема - это архитектура проекта, но никак не конкретный код.

Ага, ага, а задачи конечных пользователей, это так.. побоку... главное же это «архитектура проекта» - Вы сейчас как раз 1с напомнили сильно, хотя и пытаетесь говорить что они плохие.
Какой бы тривиальной не была система и сколько бы Вы не продумывали архитектуру всегда найдется задача от пользователя которую надо решить «вчера» но которая займет «много много времени» на реализацию и не важно что в самой задаче это одна кнопка по нажатию на которую должна появиться одна цифра.

anc ★★★★★ ()
Ответ на: комментарий от znenyegvkby

USA :) Я ж не могу вам выкатить чужой код, не комильфо же :) Но там эти проблемы не имеют такого «ахтунг»-статуса. Вы правильно подметили

Да у них просто «ахтунг» нэма, сидят на... и пока не пнеш не полетят... Совсем не пример вобщем.

anc ★★★★★ ()
Ответ на: комментарий от anc

Off-topic

Это как раз и проблема.

Ну дак мы это и мулосим уже битый час, так ведь? :) Это не проблема программиста, в прямом смысле.

С точки зрения пользователей, мата на 1с я давно не слышал.

А мне по работе иногда достается. Расскажу, мб, не особо в тему. Перед текущим проектом, еще задолго, года 4 назад, ходил в яндекс по вакансии. В Екб на Белинке, там у них верхний этаж вот этого здания. Все как надо - теннис, души, куча всякой левой фигни для работников и т.д. Но, суть: я пришел к ним по вакансии python-dev, тогда еще они не делились как сейчас на юнов/сеньоров/etc, у них в то время все было куда проще. Я указал 60к, а мне сказали - типа ты издеваешься? У нас глав. отдела py-прогеров на 50-ти сидит. Ну я и сказал им - «давай до свидания».

Это я к чему всю эту лапшу кидаю. К тому, что проблема, все-таки не в прогерах как таковых, а в самом подходе в стране, и

ЗЫ Ну а если «вам мама подарила на новый год компьютер» (с) Попробуйте реализовать проект такого же масштаба, никто вам не запрещает - озолотитесь.

Конечно, никто не запрещает реализовать что-бы не было. Дело не в этом. Я могу, допустим, реализовать это, но как программист, я ведь понимаю что основная проблема не в просто «напиши, пускай захавают». Основная проблема в сопровождении, то есть в адекватной поддержке 24/7, рекламе, апдейтах и т.д. и т.п. То есть любому прогеру в одинокого это никогда не потянуть. А то что 1С имеют на это бабло, и занимаются этим, большой чести им это не делает. Я видел их кишки. Это реально ужасно.

znenyegvkby ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.