Оптимизация работы с MySQL

мало вводных данных чтобы дать полноценный ответ

Переедьте на хостинг где побольше оперативки и где пошустрее диски. Если у Вас не мегапроект (а судя по вопросу это так), то это будет на порядок дешевле чем колхозить оптимизации в текущей ситуации (что со скриптом, что с настройками мускула).

В общем случае это не так.

Есть скрипт (не мой, изменить не могу, закодирован). Работает с базой mysql. Сейчас база занимает размер около 50гигабайт. Скрипт, на сколько я знаю, активно использует одну таблицу, размером около 30gb, для хранения каких-то промежуточных данных. Когда эта таблица имеет маленький размер, сотни кб, все работает хорошо. При разрастании до указанного размера сильно увеличивается нагрузка на сервер и все тормозит.

---------- Добавлено 30.12.2016 в 23:45 ----------

Сервер сейчас такой

https://gyazo.com/dfa4815c9062a063e9fe18579244b72e

Даже если скрипт категорически не изменить, у Вас есть вариант включить slow query лог и посмотреть на тормозящие запросы. Возможно их получится ускорить проставив индексы.

А тормозить это сколько секунд на запрос?

Сервер так-то неплохой. Памяти может оказаться достаточно для индексов, тогда ситуация изменится если их правильно натыкать. Если деньги карман не жмут, мы бы ssd поставили какой-нибудь хороший.

Вообще покажите my.ini , без этого будет обсуждение сферического коня в вакууме.

Понимаете, это всё теории. Это как делать операцию на человеке через форум.

Надо смотреть пациента, смотреть таблицу, индексы, какие запросы делаются и что вообще делает скрипт. Возможно настройки или памяти не хватает для нормальной работы. 30 Гб это достаточно много для промежуточных данных, тут нужны детали. Возможно разработчик не рассчитывал просто на такой объём, когда проектировал скрипт.

Переделка скрипта займет неопределенное время, к сожалению. Я надеялся, что можно с помощью какой-нибудь простой хитрости увеличить отзывчивость системы.

---------- Добавлено 31.12.2016 в 00:16 ----------

А разве индексы можно произвольно тыкать?

На счет переезда на сервер с ссд здесь, конечно, вопрос и финансовый и сомнения терзают. Не сомневаюсь, что если даже и переехать на ссд, то увеличив объем обрабатываемых данных в два раза, он так же ляжет.

Мне кажется, что все же как-то можно более эффективно использовать текущее железо.

Вот my.cnf

[mysqld]

datadir=/var/lib/mysql

socket=/var/lib/mysql/mysql.sock

symbolic-links=0



skip-external-locking

key_buffer_size = 2048M

max_allowed_packet = 32M

#table_open_cache = 2048

#table_cache = 2048

sort_buffer_size = 2M

join_buffer_size = 2M

read_buffer_size = 512K

read_rnd_buffer_size = 512K

myisam_sort_buffer_size = 64M

thread_cache_size = 8

query_cache_type = 1

query_cache_size = 4096M

query_cache_limit = 64M

#query_cache_type = 0

#query_cache_size = 0M

thread_concurrency = 8



#innodb_use_native_aio = 0

innodb_file_per_table

innodb_buffer_pool_size = 8G

innodb_buffer_pool_instances = 8



#max_connections=300

#max_user_connections=400

max_connections=8

#wait_timeout=300

#interactive_timeout=300

long_query_time=1



#slow_query_log=1

#slow_query_log_file=/var/log/mysql-slow-queries.log



## Fine

default-storage-engine=MyISAM

tmp_table_size=8G

max_heap_table_size=8G

open_files_limit=4000

back_log = 150

#max_user_connections=100







[mysqld_safe]

log-error=/var/log/mariadb/mariadb.log

pid-file=/var/run/mariadb/mariadb.pid



#

# include all files from the config directory

#

!includedir /etc/my.cnf.d

Воу Воу!!! Полегче с этими параметрами. 256М под первый и 3М под второй, выше крыши.

Иначе когда он заполниться такие затупы будут.

Если все таблицы в innoDB, то на скорость влияет:

innodb_buffer_pool_size

так всё же таблицы в innodb, я надеюсь?

в innodb только здоровая таблица с "кэшем". Остальные myisam

а параметры попробую поменять.

Лучше всё на innodb переведите.

Я так понимаю, что это можно сделать из phpmyadmin ?