-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Быстродействие и разгрузка сервера, базы.
- Автор темы Opik
- Дата начала
Falc
Новичок
Opik
Неплохо бы посмотреть на количество попаданий в кеш индексов, но там крутить только одну ручку key_buffer_size, чем больше тем лучше.
Еще можно посмотреть насколько хорошо используются индексы через Handler_read..., но сопоставить с ними реальные данные и запросы нельзя.
Возможно в каких-то таблицах есть не важные данные и их можно сделать HEAP.
Неплохо бы посмотреть на количество попаданий в кеш индексов, но там крутить только одну ручку key_buffer_size, чем больше тем лучше.
Еще можно посмотреть насколько хорошо используются индексы через Handler_read..., но сопоставить с ними реальные данные и запросы нельзя.
Возможно в каких-то таблицах есть не важные данные и их можно сделать HEAP.
Falc
Новичок
Opik
>>докрутили до 15085568.
15 метров - это мало.
Если MYSQL является единственной БД на сервере и оснавная нагрузка идет именно на нее, я бы рекомендовал отдать под буфер индексов четверть а то и треть всей памяти сервера.
>>Handler_read_rnd_next 974283844
Говорит о том что достаточно много фулсканов возможно они являются следствие тех самых фулджойнов. Вобщем стоит повнимательнее посмотреть на индексы.
Да и еще я плохо понимаю в чем смысл кеширования результатов запрососв в memcache? MYSQL умеет кешировать результаты сам, причем я думаю он это делает гораздо эффективние чем алгоритм написанный на PHP.
3. Исключить из тяжелых селектов частообновляемые таблицы
4. Убрать апдейты
>>докрутили до 15085568.
15 метров - это мало.
Если MYSQL является единственной БД на сервере и оснавная нагрузка идет именно на нее, я бы рекомендовал отдать под буфер индексов четверть а то и треть всей памяти сервера.
>>Handler_read_rnd_next 974283844
Говорит о том что достаточно много фулсканов возможно они являются следствие тех самых фулджойнов. Вобщем стоит повнимательнее посмотреть на индексы.
Да и еще я плохо понимаю в чем смысл кеширования результатов запрососв в memcache? MYSQL умеет кешировать результаты сам, причем я думаю он это делает гораздо эффективние чем алгоритм написанный на PHP.
Да и еще забыл:
3. Исключить из тяжелых селектов частообновляемые таблицы
4. Убрать апдейты
Falc
Новичок
fisher
>>срветую отсмотреть все наиболее частые SQL еxplainом на тему
>>using temporary
>>using filesort
Файл сорта у него нету:
>>Created_tmp_files 7
AnToXa
>>кто там написан на пхп? memcache? олала, не смешите мои тапочки.
Алгоритм кеширования конечно же, там вроде все ясно написано, он кстати приведет на первой странице.
>>кстати, вроде как innodb хорошо работает именно когда куча параллельных select/update/insert.
У innodb свои минусы, хотя для данного варианта плюсов может быть больше.
>>срветую отсмотреть все наиболее частые SQL еxplainом на тему
>>using temporary
>>using filesort
Файл сорта у него нету:
>>Created_tmp_files 7
AnToXa
>>кто там написан на пхп? memcache? олала, не смешите мои тапочки.
Алгоритм кеширования конечно же, там вроде все ясно написано, он кстати приведет на первой странице.
>>кстати, вроде как innodb хорошо работает именно когда куча параллельных select/update/insert.
У innodb свои минусы, хотя для данного варианта плюсов может быть больше.
Opik
Новичок
и что касательно логов для медленных запросов, как лучше поступить: оставить эту работу на саму базу - т.е "включить" данную опцию. или оставить как есть - в методе класса смотрися сколько выпонялся запрос, если более "минимума" - записываем в файл.
-~{}~ 20.09.05 01:00:
Да, и ещё - от чего зависит Created tmp disk tables. Увеличили до 300 метров. всё равно траблы(временные таблицы создаются на диске.). продолжать увеличивать. или могут быть грабли с другой стороны?
-~{}~ 20.09.05 02:07:
-~{}~ 20.09.05 01:00:
Да, и ещё - от чего зависит Created tmp disk tables. Увеличили до 300 метров. всё равно траблы(временные таблицы создаются на диске.). продолжать увеличивать. или могут быть грабли с другой стороны?
-~{}~ 20.09.05 02:07:
в одном месте нашел.
Falc
Новичок
Opik
>>"включить" данную опцию. или оставить как есть - в методе класса смотрися сколько выпонялся запрос, если более "минимума" - записываем в файл.
Одно другому не мещает. (Опцию на базе я бы включил обязательно)
>>Да, и ещё - от чего зависит Created tmp disk tables. Увеличили до 300 метров. всё равно траблы
Что имено ты увеличил?
Насколько я понимаю сюда пишутся все временные таблицы создаваемые на диске и те которые создаются пользователем и те которые создаются базой при выборках (using temporary). Так что возможно пользователем создаются временные таблицы не типа HEAP.
-~{}~ 20.09.05 10:28:
AnToXa
>>вообще-то стоит отличать application level кэширование от того, которое в базе, а то так можно вспомнить и тот кэш, который в HDD внутри.
Да отличать можно, но в данном случае простое дублирование функционала.
>>"включить" данную опцию. или оставить как есть - в методе класса смотрися сколько выпонялся запрос, если более "минимума" - записываем в файл.
Одно другому не мещает. (Опцию на базе я бы включил обязательно)
>>Да, и ещё - от чего зависит Created tmp disk tables. Увеличили до 300 метров. всё равно траблы
Что имено ты увеличил?
Насколько я понимаю сюда пишутся все временные таблицы создаваемые на диске и те которые создаются пользователем и те которые создаются базой при выборках (using temporary). Так что возможно пользователем создаются временные таблицы не типа HEAP.
-~{}~ 20.09.05 10:28:
AnToXa
>>вообще-то стоит отличать application level кэширование от того, которое в базе, а то так можно вспомнить и тот кэш, который в HDD внутри.
Да отличать можно, но в данном случае простое дублирование функционала.
AnToXa
prodigy-одаренный ребенок
показываю.
1. база кеширует результаты запросов, приложение - данные, которые нужны, это может быть набор данных из нескольких запросов, предварительно обработанный.
2. база при изменении данных в таблице - сбрасывает кэши, приложение - само реализует логику управления и время устаревания, приложение вообще может не уходить дальше своего кэша, и не трогать базу, пока это действительно не необходимо.
3. приложение может использовать сколько угодно любых кешей, может разбрасывать данные по разным кэшам, для оптимизации или удобства, может класть в кэш данные не только из базы.
и проч и проч.
1. база кеширует результаты запросов, приложение - данные, которые нужны, это может быть набор данных из нескольких запросов, предварительно обработанный.
2. база при изменении данных в таблице - сбрасывает кэши, приложение - само реализует логику управления и время устаревания, приложение вообще может не уходить дальше своего кэша, и не трогать базу, пока это действительно не необходимо.
3. приложение может использовать сколько угодно любых кешей, может разбрасывать данные по разным кэшам, для оптимизации или удобства, может класть в кэш данные не только из базы.
и проч и проч.
Falc
Новичок
AnToXa
Ты расписал общий случай что может приложение.
В данном случае исходя из представленого примера идет простое кеширование резултатов.
Если же у тебя есть желание показать свои знания в области кеширования, можешь написать еще пару сообщений о том что может приложение и какие выгоды будут от кеширования, я же на них отвечать не буду. Я просто показал автору топику на проблему.
-~{}~ 20.09.05 15:10:
Opik
>>выдержка из мануала. первое соотношение у меня 0.03...
0.03 - Это мало нужно увеличивать буфер ключей, тебе уже говорили.
>>второе же - 9.
Т.е. записей ключей у тебя больше чем запрсосв на запись?
Ты расписал общий случай что может приложение.
В данном случае исходя из представленого примера идет простое кеширование резултатов.
Если же у тебя есть желание показать свои знания в области кеширования, можешь написать еще пару сообщений о том что может приложение и какие выгоды будут от кеширования, я же на них отвечать не буду. Я просто показал автору топику на проблему.
-~{}~ 20.09.05 15:10:
Opik
>>выдержка из мануала. первое соотношение у меня 0.03...
0.03 - Это мало нужно увеличивать буфер ключей, тебе уже говорили.
>>второе же - 9.
Т.е. записей ключей у тебя больше чем запрсосв на запись?
AnToXa
prodigy-одаренный ребенок
Falc
дело в том, что тут перенос кеширования на уровень приложения выгоден на мой вкус.
поскольку обратная запись в базу далеко не всегда нужна, и может идти в кэш, а mysql сбрасывает кэш при изменении таблицы anyway, заявки на бои тоже могут вполне идти не в базу и куча моментов еще, то же распределение кешей.
плюс база не может сливать данные из кешей при джоине, даже если обе таблицы просто валяются в query cache целиком.
дело в том, что тут перенос кеширования на уровень приложения выгоден на мой вкус.
поскольку обратная запись в базу далеко не всегда нужна, и может идти в кэш, а mysql сбрасывает кэш при изменении таблицы anyway, заявки на бои тоже могут вполне идти не в базу и куча моментов еще, то же распределение кешей.
плюс база не может сливать данные из кешей при джоине, даже если обе таблицы просто валяются в query cache целиком.