-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Быстродействие и разгрузка сервера, базы.
- Автор темы Opik
- Дата начала
Апельсин
Оранжевое создание
> а иначе очень много временных таблиц создает на диске
вы уверены что хоть какому-то вашему запросу необходимо 300 метров памяти?
Чему было равно это значение раньше?
Вы понимаете, что при такой настройке каждое соединение выполняющее запрос, где есть необходимость создания временной таблицы, теперь может отжирать до 300 метров памяти? Вы уверены что вы этого хотите?
вы уверены что хоть какому-то вашему запросу необходимо 300 метров памяти?
Чему было равно это значение раньше?
Вы понимаете, что при такой настройке каждое соединение выполняющее запрос, где есть необходимость создания временной таблицы, теперь может отжирать до 300 метров памяти? Вы уверены что вы этого хотите?
Апельсин
Оранжевое создание
увеличить key_buffer_size
обязательно. Вам об этом уже сказали.
посмотрите как много запросов у вас использует сортировку и сканирование по таблице, возможно увеличьте немного sort_buffer_size и read_buffer_size
по поводу созданных временных таблиц, 300 метров вам нафиг не нужно. Я не знаю сколько у вас было раньше, для большинства хватает 8-16 метров. Проверьте также размер max_heap_table_size, т.к. все таблицы в памяти создаются как HEAP то эта переменная тоже учитывается.
Есть ли у вас BLOB или TEXT поля? Если да, то временные таблицы всегда будут создаваться на диске для таких запросов, т.к. HEAP таблицы не поддерживают TEXT и BLOB поля.
обязательно. Вам об этом уже сказали.
посмотрите как много запросов у вас использует сортировку и сканирование по таблице, возможно увеличьте немного sort_buffer_size и read_buffer_size
по поводу созданных временных таблиц, 300 метров вам нафиг не нужно. Я не знаю сколько у вас было раньше, для большинства хватает 8-16 метров. Проверьте также размер max_heap_table_size, т.к. все таблицы в памяти создаются как HEAP то эта переменная тоже учитывается.
Есть ли у вас BLOB или TEXT поля? Если да, то временные таблицы всегда будут создаваться на диске для таких запросов, т.к. HEAP таблицы не поддерживают TEXT и BLOB поля.
Opik
Новичок
MuXa247
Спасибо. помогло.
Увеличил key_buffer_size до 500 метров.
Хотелось бы немного поговорить по логике скрипта.
При каждом обновлении скрипта в любой части игры вызывается функция получения инфы. Вот о ней и хочу поговорить. В ней 2 SQL запроса(простых), но из больших таблиц. пару инклудов и дофига операций, сложения, ифы всякие, swtich и так далее. Т.е это накладно каждый раз её использовать. Какие тут варианты решения данной проблемы?
На голове вертиться всё тот же самый memcache. Но один он помоч не может. т.к им нужно ещё правильно распорядится. В той функции есть инфа которая обновляется часто, и есть которая может необновляться вообще.
1) Есть варианты кешировать всё сразу, но как актуализировать инфу при каком либо изменении? "пересобирать" кеш?
2) кешировать данные по запросам, который чаще - кешировать ненадолго. который почти не меняется кешить надолго
) и при изменении опять пересобирать кеш..
Какие ещё варианты?
Спасибо. помогло.
Увеличил key_buffer_size до 500 метров.
Хотелось бы немного поговорить по логике скрипта.
При каждом обновлении скрипта в любой части игры вызывается функция получения инфы. Вот о ней и хочу поговорить. В ней 2 SQL запроса(простых), но из больших таблиц. пару инклудов и дофига операций, сложения, ифы всякие, swtich и так далее. Т.е это накладно каждый раз её использовать. Какие тут варианты решения данной проблемы?
На голове вертиться всё тот же самый memcache. Но один он помоч не может. т.к им нужно ещё правильно распорядится. В той функции есть инфа которая обновляется часто, и есть которая может необновляться вообще.
1) Есть варианты кешировать всё сразу, но как актуализировать инфу при каком либо изменении? "пересобирать" кеш?
2) кешировать данные по запросам, который чаще - кешировать ненадолго. который почти не меняется кешить надолго
) и при изменении опять пересобирать кеш..Какие ещё варианты?
Steamroller
Новичок
Надо измерить, насколько быстро выполняется целиком эта функция получения инфы, и сколько занимает вызов SQL-запроса (самого mysql_query, до fetch'ей).
Дальше прикинуть, сколько вызовов в минуту нужно обслуживать при пиковой нагрузке.
И исходя из этого что-то уже решать. Может так получиться, что достаточно будет поработать с индексами в базе, формулировками запросов, и настройками mysqld.
Оливер Перри
Новичок
А что за игра то ?