BlackBoxs.Biz  Зеркало Blackboxs.ruBlackBoxs.Biz  Зеркало Blackboxs.ru
BlackBoxs.Biz  Зеркало Blackboxs.ru
Справка Календарь Все разделы прочитаны
Обменник

Конкурс! Конкурс! Конкурс! 2017
Register | Lost Your Password

Вернуться   BlackBoxs.Biz Зеркало Blackboxs.ru > Техничка > Хостинги - Hostings > Администрирование сервера

Важная информация

Ответ
 
Опции темы Опции просмотра
Старый 06.11.2015, 22:08   #1
mantius
BB$
 
Аватар для mantius
 
Регистрация: 24.07.2011
Адрес: Под мостом
Сообщений: 5,482
Благодарил(а): 1,409 раз(а)
Поблагодарили: 2,252 раз(а) в 1,207 сообщениях
Репутация: 2238
По умолчанию Скорость mysql

Есть MYISAM таблица на ~11 000 000 записей объёмом ~3 Gb и ~1 Gb индексов, запрос вида:
SELECT count(*) FROM `table` WHERE `var` = 123
Выполняется 6-7 секунд независимо от количество подходящих результатов. Сервер на Xeon X3210 c 8Gb RAM, почти без нагрузки.

Если у кого-то есть опыт работы с данными подобного объёма, подскажите, требуется ли оптимизация MySQL(или самой таблицы) или это нормальная скорость работы для такой конфигурации и просто нужно брать мощнее серв?
__________________
Рекомендую только то, чем сам пользуюсь давно и успешно: [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
[Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
CPA - это [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации], сотни активных офферов.
mantius вне форума   Ответить с цитированием
Старый 06.11.2015, 22:41   #2
int_main
BB$
 
Регистрация: 31.05.2011
Сообщений: 1,368
Благодарил(а): 398 раз(а)
Поблагодарили: 643 раз(а) в 417 сообщениях
Репутация: 850
По умолчанию

А индекс по var? Покажи EXPLAIN запроса. Возможно нужно больше памяти под индексы.
int_main вне форума   Ответить с цитированием
Благодарность от:
Старый 06.11.2015, 23:30   #3
mantius
BB$
 
Аватар для mantius
 
Регистрация: 24.07.2011
Адрес: Под мостом
Сообщений: 5,482
Благодарил(а): 1,409 раз(а)
Поблагодарили: 2,252 раз(а) в 1,207 сообщениях
Репутация: 2238
По умолчанию

Цитата:
А индекс по var? Покажи EXPLAIN запроса. Возможно нужно больше памяти под индексы.
Завтра попробую - сейчас конвертирую базу в innoDB, всё висит=) Надеюсь получить многопоточность на процессоре, а то MyISAM только 1 ядро на исполнение запроса может использовать, если я правильно понял.
__________________
Рекомендую только то, чем сам пользуюсь давно и успешно: [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
[Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
CPA - это [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации], сотни активных офферов.
mantius вне форума   Ответить с цитированием
Старый 06.11.2015, 23:48   #4
mantius
BB$
 
Аватар для mantius
 
Регистрация: 24.07.2011
Адрес: Под мостом
Сообщений: 5,482
Благодарил(а): 1,409 раз(а)
Поблагодарили: 2,252 раз(а) в 1,207 сообщениях
Репутация: 2238
По умолчанию

Так, с innoDB ожидаемо стало хуже, но чтобы НАСТОЛЬКО... Производительность упала в десятки раз, запросы просто по навигации в таблице висят по несколько минут(вместо нескольких секунд), завтра буду возвращать всё в зад на MyISAM и там уже смотреть что и как.
__________________
Рекомендую только то, чем сам пользуюсь давно и успешно: [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
[Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
CPA - это [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации], сотни активных офферов.
mantius вне форума   Ответить с цитированием
Старый 07.11.2015, 00:12   #5
MaximuS
Модератор
 
Аватар для MaximuS
 
Регистрация: 22.02.2012
Сообщений: 715
Благодарил(а): 293 раз(а)
Поблагодарили: 244 раз(а) в 147 сообщениях
Репутация: 592
По умолчанию

innoDB очень прожорливый, хотя на маленьких объёмах работает лучше MyISAM.
А ты не пробывал пролечить таблицу? Бывают ошибки в базе которые сильно тормозят выполнение запросов, само собой провоцируя скачки нагрузки на серв.
MaximuS вне форума   Ответить с цитированием
Благодарность от:
Старый 07.11.2015, 02:01   #6
Atarvala
BB$
 
Аватар для Atarvala
 
Регистрация: 18.02.2013
Сообщений: 322
Благодарил(а): 106 раз(а)
Поблагодарили: 106 раз(а) в 54 сообщениях
Репутация: 134
По умолчанию

В эту сторону смотрел ? _https://www.mongodb.com/?_ga=1.217793238.1965571313.1446764486
__________________
###=> [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации] <=###

[Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
Atarvala вне форума   Ответить с цитированием
Благодарность от:
Старый 07.11.2015, 08:42   #7
Worm
Модератор
 
Аватар для Worm
 
Регистрация: 19.08.2011
Сообщений: 582
Благодарил(а): 204 раз(а)
Поблагодарили: 562 раз(а) в 222 сообщениях
Репутация: 432
По умолчанию

Цитата:
Сообщение от mantius Посмотреть сообщение
Есть MYISAM таблица на ~11 000 000 записей объёмом ~3 Gb и ~1 Gb индексов, запрос вида:
SELECT count(*) FROM `table` WHERE `var` = 123
Выполняется 6-7 секунд независимо от количество подходящих результатов. Сервер на Xeon X3210 c 8Gb RAM, почти без нагрузки.

Если у кого-то есть опыт работы с данными подобного объёма, подскажите, требуется ли оптимизация MySQL(или самой таблицы) или это нормальная скорость работы для такой конфигурации и просто нужно брать мощнее серв?
тип поля var какой? индекс на var стоит? Можно вместо count(*) использовать count(var). В общем надо смотреть саму таблицу, что там за данные/типы данных, как индексы расставлены, эксплэин глянуть ещё... В указаном у тебя примере должно быстро выдавать результат вне зависимости от типа таблиц.

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

В icq можешь вечером написать, можем глянуть...

Последний раз редактировалось Worm; 07.11.2015 в 08:44.
Worm вне форума   Ответить с цитированием
Благодарность от:
Старый 07.11.2015, 09:43   #8
mantius
BB$
 
Аватар для mantius
 
Регистрация: 24.07.2011
Адрес: Под мостом
Сообщений: 5,482
Благодарил(а): 1,409 раз(а)
Поблагодарили: 2,252 раз(а) в 1,207 сообщениях
Репутация: 2238
По умолчанию

Цитата:
А ты не пробывал пролечить таблицу? Бывают ошибки в базе которые сильно тормозят выполнение запросов, само собой провоцируя скачки нагрузки на серв.
Запустил repair, жду. Пробовал до этого optimize, не помогло.
Цитата:
В эту сторону смотрел ? _https://www.mongodb.com/?_ga=1.217793238.1965571313.1446764486
Мне, честно, сервер проще взять более мощный, чем уходить от мускула - прирост не факт что большой будет при смене движка базы, а вот гемор гарантирован.
Цитата:
тип поля var какой?
int
Цитата:
индекс на var стоит?
Конечно, 3 раза проверял=)
Цитата:
Можно вместо count(*) использовать count(var).
Ничего не меняется, очевидно, там проблема не с обработкой выходных данных, а с их поиском в большой таблице - как я писал, от количества подпадающих под запрос строк результат почти не меняется: и когда результат равен 6000+ строк и когда 2.
Цитата:
В общем надо смотреть саму таблицу, что там за данные/типы данных
1 tinyint, 6 int, 2 bigint, 1 datetime, 1 varchar(250), 1 text
В индексах только целочисленные и datetime.
Цитата:
как индексы расставлены
Индекса 3 у таблицы: UNIQUE из 1 поля, один большой из всех полей этой таблицы подлежащих индексации(включая datetime) и один ещё из двух полей, который я пока ещё не уверен, что буду использовать, но на всякий случай добавил.
Цитата:
эксплэин глянуть ещё
id? select_type? table? partitions? type? possible_keys? key? key_len? ref? rows? Extra?
1 SIMPLE c NULL ALL NULL NULL NULL NULL 11303130 Using where
Это для запроса count(`cid`) где `cid` - это наш UNIQUE;
Для count(*):
id? select_type? table? partitions? type? possible_keys? key? key_len? ref? rows? Extra?
1 SIMPLE c NULL index NULL big_index 32 NULL 11303269 Using where; Using index

big_index - это наш большой индекс.
Цитата:
Ну смотря какая там параллельно этому нагрузка
Как я уже писал, сервер почти без нагрузки.
Цитата:
В icq можешь вечером написать, можем глянуть...
Хорошо, спасибо=)
__________________
Рекомендую только то, чем сам пользуюсь давно и успешно: [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
[Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
CPA - это [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации], сотни активных офферов.
mantius вне форума   Ответить с цитированием
Старый 07.11.2015, 10:08   #9
BlastPy
BB$
 
Аватар для BlastPy
 
Регистрация: 11.01.2015
Адрес: IF
Сообщений: 1,069
Благодарил(а): 672 раз(а)
Поблагодарили: 258 раз(а) в 171 сообщениях
Репутация: 199
По умолчанию

Посмотри в сторону PostgreSQL
BlastPy вне форума   Ответить с цитированием
Благодарность от:
Старый 07.11.2015, 11:39   #10
mantius
BB$
 
Аватар для mantius
 
Регистрация: 24.07.2011
Адрес: Под мостом
Сообщений: 5,482
Благодарил(а): 1,409 раз(а)
Поблагодарили: 2,252 раз(а) в 1,207 сообщениях
Репутация: 2238
По умолчанию

Цитата:
Посмотри в сторону PostgreSQL
Я уже отвечал:
Цитата:
Мне, честно, сервер проще взять более мощный, чем уходить от мускула - прирост не факт что большой будет при смене движка базы, а вот гемор гарантирован.
__________________
Рекомендую только то, чем сам пользуюсь давно и успешно: [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
[Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
CPA - это [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации], сотни активных офферов.
mantius вне форума   Ответить с цитированием
Старый 07.11.2015, 11:45   #11
mantius
BB$
 
Аватар для mantius
 
Регистрация: 24.07.2011
Адрес: Под мостом
Сообщений: 5,482
Благодарил(а): 1,409 раз(а)
Поблагодарили: 2,252 раз(а) в 1,207 сообщениях
Репутация: 2238
По умолчанию

Забыл написать: при запросе узкое место - проц, используется на 100% одно ядро при ожидании ответа. Многопоточность, как я понял, работает только для innoDB, но по факту с ней узким местом становится диск и потому время начинает зашкаливать.
Цитата:
Сервак у тебя и так хороший, должно с огромным запасом хватать.
По мне так серв наоборот старый(2008 год) и хилый - PassMark 2796, в OVH за 70 евро предлагают E3-1231v3 2014 года с результатом 9605. Т.е. у него 1 ядро по производительности почти как 4 ядра моего проца. Минус в том, что у E3 Hyper-threading и потому потоков будет 8, а это значит прирост меньше, чем в 2 раза(1200 против 699), т.е. будет 2-3 секунды на запрос в лучшем случае - это также очень много. Можно взять SSD-диски, но, как я вижу, они не особо повлияют - я могу всю базу хранить в оперативке.
__________________
Рекомендую только то, чем сам пользуюсь давно и успешно: [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
[Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
CPA - это [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации], сотни активных офферов.

Последний раз редактировалось mantius; 07.11.2015 в 11:53.
mantius вне форума   Ответить с цитированием
Старый 07.11.2015, 15:20   #12
Spin
BB$
 
Регистрация: 09.01.2015
Сообщений: 326
Благодарил(а): 19 раз(а)
Поблагодарили: 189 раз(а) в 139 сообщениях
Репутация: 199
Lightbulb

Цитата:
Сообщение от mantius Посмотреть сообщение
Есть MYISAM таблица на ~11 000 000 записей объёмом ~3 Gb и ~1 Gb индексов, запрос вида:
SELECT count(*) FROM `table` WHERE `var` = 123
Выполняется 6-7 секунд независимо от количество подходящих результатов. Сервер на Xeon X3210 c 8Gb RAM, почти без нагрузки.

Если у кого-то есть опыт работы с данными подобного объёма, подскажите, требуется ли оптимизация MySQL(или самой таблицы) или это нормальная скорость работы для такой конфигурации и просто нужно брать мощнее серв?
Во-первых, можно поставить [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации] - это замена MySQL сервера. Замена прозрачная, то есть вообще ничего в запросах и базе менять не потребуется. А вот производительность повысится.

Во-вторых, надо обращать внимание на запросы. Какие основные типы запросов приходят и их количество? Проблемы только с count(*)?
Spin вне форума   Ответить с цитированием
Благодарность от:
Старый 07.11.2015, 15:43   #13
mantius
BB$
 
Аватар для mantius
 
Регистрация: 24.07.2011
Адрес: Под мостом
Сообщений: 5,482
Благодарил(а): 1,409 раз(а)
Поблагодарили: 2,252 раз(а) в 1,207 сообщениях
Репутация: 2238
По умолчанию

Нашёл ещё закономерность: если в запросе использовать другое поле, то он выполняется почти моментально:
id? select_type? table? partitions? type? possible_keys? key? key_len? ref? rows? Extra?
1 SIMPLE c NULL ref big_index big_index 4 const 4101 Using index
В данном случае выбирается count(*) с поиском по полю, которое в другой таблице является PRIMARY. Может быть, это как-то влияет? В любом случае, запросы абсолютно идентичны, индексы и типы полей совпадают, но скорость работы несоизмерима.
Цитата:
Во-первых, можно поставить [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации] - это замена MySQL сервера. Замена прозрачная, то есть вообще ничего в запросах и базе менять не потребуется. А вот производительность повысится.
Можно, но в 60 раз он явно не ускорит работу, так что это не решение явно, я сейчас больше склоняюсь к тому, что у меня просто неправильная архитектура базы/запросов.
Цитата:
Во-вторых, надо обращать внимание на запросы. Какие основные типы запросов приходят и их количество? Проблемы только с count(*)?
Вот выше я пример привёл, так вообще почти никаких запросов там не приходит ещё - сайт в разработке, так что можем спокойно разбирать один конкретный запрос без оглядки на остальные.
Я выбираю count(*), можно выбирать SUM() или ещё что-то подобное с перебором всех подходящих под WHERE результатов - в любом случае требуется 5-7 секунд на запрос. Проблема именно в поиске, причём, если используется WHERE `key1` = 123, то всё летает, если же использовать любое другое поле из того же индекса после WHERE, то требуется 5-6 секунд независимо от того что мы запрашиваем. Как я писал, key1 примечателен тем, что является PRIMARY в соседней таблице.
__________________
Рекомендую только то, чем сам пользуюсь давно и успешно: [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
[Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
CPA - это [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации], сотни активных офферов.
mantius вне форума   Ответить с цитированием
Старый 07.11.2015, 16:15   #14
mantius
BB$
 
Аватар для mantius
 
Регистрация: 24.07.2011
Адрес: Под мостом
Сообщений: 5,482
Благодарил(а): 1,409 раз(а)
Поблагодарили: 2,252 раз(а) в 1,207 сообщениях
Репутация: 2238
По умолчанию

Аналогично туго идёт и сортировка в этой таблице по любому из параметров кроме вышеуказанного key1, который летает. Причём, неважно сортировать ли все данные или только несколько последних - каждый раз время в районе 7 секунд уходит при выводе первых 20 результатов.
__________________
Рекомендую только то, чем сам пользуюсь давно и успешно: [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
[Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации]
CPA - это [Только зарегистрированные пользователи могут видеть ссылки. Нажмите Здесь для Регистрации], сотни активных офферов.
mantius вне форума   Ответить с цитированием
Старый 07.11.2015, 16:18   #15
int_main
BB$
 
Регистрация: 31.05.2011
Сообщений: 1,368
Благодарил(а): 398 раз(а)
Поблагодарили: 643 раз(а) в 417 сообщениях
Репутация: 850
По умолчанию

Цитата:
Индекса 3 у таблицы: UNIQUE из 1 поля, один большой из всех полей этой таблицы подлежащих индексации(включая datetime) и один ещё из двух полей, который я пока ещё не уверен, что буду использовать, но на всякий случай добавил.
Я чет не догоняю, у тебя составные индексы? Сделай отдельный индекс по var если его нету.
int_main вне форума   Ответить с цитированием
Благодарность от:
Ответ

Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 03:39. Часовой пояс GMT.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2017, vBulletin Solutions, Inc. Перевод: zCarot
vB.Sponsors