Тюнинг mysql

Ага. Если особо не задумываться и не утруждать свою головушку деталями.

"Смотрю в книгу - вижу фигу". Вы действительно думаете, что 48M - это 48 мегабайт в оперативной памяти? "Человеческих мегобайт"? :D "Администрирование Linux", ололо...

Вы нам, конечно, легко объясните тогда как может быть

[OK] Query cache efficiency: 63.5% (952M cached / 1B selects)

query_cache_size=128M

Zaqwr выскочил из-за угла, неожиданно как ... :) марш читать тему от а до я. + link force

так это уже к слову.

по всему остальному ваша позиция ясна и спорить не о чем. вы не считаете допустимым никакое обобщение практики. я в данном случае считаю допустимым.

Завязывайте фантазировать и "обобщать". Все было сказано предельно конкретно и ясно, повторяться мне уже лень.

Ну смотрите что получается :

"Сетап с душой" предполагает некоторую оптимальность параметров.

Эти параметры должны быть не результатом сиюминутного замера, а подходить на все время работы сайта.

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

Другие параметры для чистоты замеров изменять нельзя.

Допустим, для удовлетворительного результата нужно сделать 3 итерации подбора размера методом половинного деления.

Итого, по вашей методике заказчик будет ждать 3 недели только для настройки одного параметра? По крайней мере, в случаях подобных как у ТС, я за "магию".

Ну, это просто маркетинг.

У проекта либо есть системный администратор - либо нет. В последнем случае можно пытаться подобрать параметры методом научного тыка по хавту. Как правило, в итоге не сильно лучший результат в сравнении со стратегией "работает - не трогай".

Вы о тестировании слышали? Есть примеры нагрузки за определенный период. Берется access.log и эта нагрузка моделируется. Да и интересно поведение обычно именно в моменты пиковой нагрузки. Вот тогда имеет смысл и показать все понимающему человеку.

слышали что оно не в состоянии достаточно точно моделировать нагрузку.

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

Я ж и не запрещал наблюдать за живым сайтом. Ровно наоборот. Это вы уцепились опять за одну мысль в тексте - и давай "опровергать"...

Нет никаких проблем предложить сразу какие-то "оптимальные" значения параметров. Но нельзя этого сделать по шаблону, как хотите вы. Просто сесть и посмотреть на вывод extended-status - после этого уже что-то крутить. Можно более кропотливо достичь и лучшего, но делать наобум - совсем никуда не годится.

У ТС кеш используется достаточно активно (58.2% попаданий) - вы же его запросто захотели урезать в 4 раза. Или вы тоже 28M cached с мегабайтами перепутали? ;)

но ведь наблюдение за сайтом выливается в огромные трудозатраты.

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

куда не плюнь - все трудно. Средний сайтовладелец на такое не пойдет.

и не придираюсь я к словам. я конкретные варианты обсуждаю.

Если некоторые части плана не работают, то не работает весь план.

почему бы и нет ? Меньший кеш быстрее чистится и обеспечивает большую масштабируемость по ядрам процессора. Сервер то у ТС выделенный под mysql.

Спасибо за бурное обсуждение.

По моим проектам, оказалось, что mysql не всегда верно выбирает индекс. Например, есть таблица с индексами field, dt.

Запрос "SELECT id FROM table WHERE field='1' ORDER BY dt DESC LIMIT 10" выполнлся достаточно долго (1.5-2.5сек), т.к. оказывается mysql не всегда использует НУЖНЫЙ индекс из возможных. Например в этом запросе он использовал индекс dt. Но стоит в этом типе запросов указать USE INDEX(field), как запрос начинает выполнятся меньше секкунды: SELECT id FROM table USE INDEX(field) WHERE field='1' ORDER BY dt DESC LIMIT 10;

Но, это о птичках... Возвращаясь к конфигу, в итоге после советов и google он приобрел следующий вид:

[mysqld]

datadir=/var/lib/mysql

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

user=mysql

tmpdir=/tmp



key_buffer=512M

table_cache=1024



thread_cache_size = 32

thread_concurrency = 16

max_connections  = 100 



query_cache_type=1

query_cache_limit=128M

query_cache_size=1024M



max_allowed_packet = 128M

sort_buffer_size = 4M

read_buffer_size = 4M

join_buffer_size = 4M

read_rnd_buffer_size = 4M

myisam_sort_buffer_size = 128M



max_heap_table_size=128M

tmp_table_size=128M



concurrent_insert=2

low_priority_updates=1



slow-query-log

long_query_time=2

slow_query_log_file=/tmp/slow-queries-log



general_log_file = /tmp/general-mysql-log



ignore_builtin_innodb

default_storage_engine=MyISAM



[mysqld_safe]

log-error=/var/log/mysqld.log

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

Спустя 5 часов ситуация следующая:

Надо подождать еще сутки-двое, если картина в целом будет аналогичной, то считаю проблемы на данном этапе решены.

Или нет?