Разное время выполнения одних и тех же sql-запросов.

Аватар пользователя roman-yrv roman-yrv 23 июля 2013 в 12:29

Добрый день.

Подскажите пожалуйста, решаема ли такая проблема, когда один и тот же SQL запрос в одном случае может выполняться, скажем, менее одной миллисекунды, а в другом случае - 90 миллисекунд (см. скриншот) ?

Если задача решаема, то поделитесь, пожалуйста, информацией по решению.

ВложениеРазмер
Иконка изображения sql-time.png28.17 КБ

Комментарии

Аватар пользователя Chyvakoff Chyvakoff 23 июля 2013 в 15:05

А массив, подставляемый в IN один и тот же?

"ydv" wrote:
Дело в кеше

Да, в кэше самой бд, стало быть.

Аватар пользователя roman-yrv roman-yrv 23 июля 2013 в 15:53

Вот на значения массива, к сожалению, не обратил внимание.

Так а есть ли рекомендации по настройке кэша в подобных случаях ?

У меня параметры кэша mysql установлены таким образом

query_cache_limit = 16M
query_cache_size = 128M
query_cache_type = 1

А общие характеристики системы таковы:
Virtual CPU 500Mhz, 512Mb memory, 15000Mb disk

Это я заказал тарифный план "start" больше для тестирования
http://interserver.ru/vds.html

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 23 июля 2013 в 15:56

"roman-yrv" wrote:

Так а есть ли рекомендации по настройке кэша в подобных случаях ?


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

Аватар пользователя roman-yrv roman-yrv 23 июля 2013 в 18:47

Вот еще такая ситуация

Допустим, SQL-запрос

SELECT cid, data, created, expire, serialized FROM cache_views WHERE cid IN ('views_data:ru')

выполнился за 106 миллисекунд.

EXPLAIN выдал следующее:

ID      SELECT_TYPE     TABLE         TYPE      POSSIBLE_KEYS   KEY       KEY_LEN       REF     ROWS    EXTRA
1       SIMPLE          cache_views   const     PRIMARY         PRIMARY   767           const   1      

cid в таблице проиндексирован как первичный ключ.

Вот в таких случаях возможно ли избавиться от таких вот случаев медленной работы запроса с помощью каких-либо настроек ?
Или не заморачиваться и, если уж прижмет, переходить на более мощный тариф или к другому хостеру ?

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 23 июля 2013 в 20:16

"roman-yrv" wrote:
Вот в таких случаях возможно ли избавиться от таких вот случаев медленной работы запроса с помощью каких-либо настроек ?

Нет.
Это просаженные диски.
Наверняка долгие запросы по cid-у, это кеш меню или что-то крупное.
Спасёт здесь только мемкеш

Аватар пользователя roman-yrv roman-yrv 23 июля 2013 в 20:49

RxB wrote:

Это просаженные диски.

А что это означает ?

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

Аватар пользователя roman-yrv roman-yrv 23 июля 2013 в 22:36

Установил memcached на сервер и настроил, как написано здесь
http://drupalace.ru/lesson/sistema-keshirovaniya-drupal-7-chast-tretya-u...

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

Наверное, все-таки решение в общем случае - смотреть на более качественный VPS.

Скажите, а вот облачные хостинги могут иметь такие проблемы, как

Quote:

Перегруженная дисковая подсистема сервера на котором крутятся ВПС-ки вследствии чего БД работает не ахти

или это также зависит от хостера ?

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 23 июля 2013 в 22:46

Облака не панацея + у многих есть практика так же резать производительность дисковой подсистемы.
Т.е. на дешёвых облаках такой же косяк со скоростью.
+ облака, особенно если это русские, довольно дорогое удовольствие, опять же сравнимое в итоге с VPS

Аватар пользователя roman-yrv roman-yrv 23 июля 2013 в 23:02

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

Блин, если бы не было таких косяков, то общее время SQL-запросов составляло бы несколько миллисекунд.
А так, к сожалению, может достигать и несколько сотен миллисекунд.

Опять же, я провожу тестирование на примере стандартной инсталляции Drupal 7 с добавлением нескольких основных модулей (Views, Rules, Token и др.) и добавлением нескольких тестовых страниц.

А вот не знаете случайно какого-нибудь VPS-хостера, который бы следил за тем, чтобы у него не перегружалась дисковая подсистема ?

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 23 июля 2013 в 23:18

В большинстве случаев это хостеры на Xen, но они и дороже.
Хотя некоторые, конечно, говорят что Xen фигня, OpenVZ или Виртуоззо наше всё, и оверселла там не бывает.

Аватар пользователя roman-yrv roman-yrv 23 июля 2013 в 23:43

Понятно.
Тогда, наверное, остается следующий вариант.
Начинать работать на VPS и по мере возможности стараться оптимизировать, кешировать и т.д.

А как станет видно, что сайт, как говорится, пошел, то брать и арендовать выделенный сервер.
Например, здесь - http://renter.ru/

Ну или брать энную сумму, собирать и настраивать сервер под себя и размещать его в датацентре.

Аватар пользователя Andruxa Andruxa 24 июля 2013 в 2:46

"roman-yrv" wrote:
собирать и настраивать сервер под себя и размещать его в датацентре

это очень дорого

Аватар пользователя roman-yrv roman-yrv 24 июля 2013 в 9:00

Ну я же и говорю: "Брать энную сумму ...".

Но опять же, нужно смотреть, стоит оно того в принципе или нет...