Быстродействие и разгрузка сервера, базы.

  • Автор темы Автор темы Opik
  • Дата начала Дата начала
Opik
До скольки увеличили буфер ключей?

Снизилась нагрузка на сервер?
 
Где много обновлений больших таблиц сделал блокировку и теперь гораздо меньше запросов пишутся в лог. Да и результат уже куда лучше.
 
Opik
Поидее запросы которые создают такие временые таблицы должны быть очень тормозными, так что ищи их в логе и пробуй оптимизировать.
 
Falc
в логе сложных селектов нет вообще, да и самих селектов очень мало.
 
Opik
>>в логе сложных селектов нет вообще, да и самих селектов очень мало.

Они могут быть и не сложными, просто в них обрабатывается большое кол-во данных
 
Апельсин
а иначе очень много временных таблиц создает на диске.
 
> а иначе очень много временных таблиц создает на диске

вы уверены что хоть какому-то вашему запросу необходимо 300 метров памяти?
Чему было равно это значение раньше?
Вы понимаете, что при такой настройке каждое соединение выполняющее запрос, где есть необходимость создания временной таблицы, теперь может отжирать до 300 метров памяти? Вы уверены что вы этого хотите?
 
увеличить key_buffer_size
обязательно. Вам об этом уже сказали.

посмотрите как много запросов у вас использует сортировку и сканирование по таблице, возможно увеличьте немного sort_buffer_size и read_buffer_size

по поводу созданных временных таблиц, 300 метров вам нафиг не нужно. Я не знаю сколько у вас было раньше, для большинства хватает 8-16 метров. Проверьте также размер max_heap_table_size, т.к. все таблицы в памяти создаются как HEAP то эта переменная тоже учитывается.
Есть ли у вас BLOB или TEXT поля? Если да, то временные таблицы всегда будут создаваться на диске для таких запросов, т.к. HEAP таблицы не поддерживают TEXT и BLOB поля.
 
Автор оригинала: Opik
blob нету, TEXT есть.
Вытаскивай все TEXT-ы, BLOB-ы в отдельные таблицы с привязкой по айдишнику... и делай таблицы фиксированного формата(или если надо, то HEAP)... varchar надо либо сделать char, либо если не используется при выборке вытащить вместе с TEXT и BLOB в отдельные таблицы...
 
MuXa247
Спасибо. помогло.
Увеличил key_buffer_size до 500 метров.

Хотелось бы немного поговорить по логике скрипта.
При каждом обновлении скрипта в любой части игры вызывается функция получения инфы. Вот о ней и хочу поговорить. В ней 2 SQL запроса(простых), но из больших таблиц. пару инклудов и дофига операций, сложения, ифы всякие, swtich и так далее. Т.е это накладно каждый раз её использовать. Какие тут варианты решения данной проблемы?
На голове вертиться всё тот же самый memcache. Но один он помоч не может. т.к им нужно ещё правильно распорядится. В той функции есть инфа которая обновляется часто, и есть которая может необновляться вообще.
1) Есть варианты кешировать всё сразу, но как актуализировать инфу при каком либо изменении? "пересобирать" кеш?
2) кешировать данные по запросам, который чаще - кешировать ненадолго. который почти не меняется кешить надолго :)) и при изменении опять пересобирать кеш..

Какие ещё варианты?
 
Глубокий рефакторинг программной части сиcтемы с поиском оптимальных алгоритмов функционирования.
Достаточно? :)

Более конкретные советы можно давать только после глубокого изучения программной части проекта, а это стоит денег.
 
При каждом обновлении скрипта в любой части игры вызывается функция получения инфы. Вот о ней и хочу поговорить. В ней 2 SQL запроса(простых), но из больших таблиц. пару инклудов и дофига операций, сложения, ифы всякие, swtich и так далее. Т.е это накладно каждый раз её использовать. Какие тут варианты решения данной проблемы?
Надо измерить, насколько быстро выполняется целиком эта функция получения инфы, и сколько занимает вызов SQL-запроса (самого mysql_query, до fetch'ей).
Дальше прикинуть, сколько вызовов в минуту нужно обслуживать при пиковой нагрузке.
И исходя из этого что-то уже решать. Может так получиться, что достаточно будет поработать с индексами в базе, формулировками запросов, и настройками mysqld.
 
Сверху