если имеется ввиду от одного сайта из кучи
http://dev.mysql.com/doc/refman/5.0/en/grant.html
Several WITH clause options specify limits on use of server resources by an account:
The MAX_QUERIES_PER_HOUR count, MAX_UPDATES_PER_HOUR count, and MAX_CONNECTIONS_PER_HOUR
по вашим данным этого не видно. вы ведь эпизодически поглядываете в top, а не считаете строго.
вообще-то mysqltuner этого вам не советовал.
показатели Handler_* вообще никак от размеров буферов не зависят. Это логические операции и отражают логические этапы выполнения запросов.
Остальное все я бы оставил как есть.
sort_buffer_size - лучше бы увеличить хотя бы до 8M
Opened_tables у вас дошел до максимума, потому что mysqltuner при подсчете объема данных открыл последовательно все таблицы, так что тоже мало веры этому значению. в нормальном режиме многие таблицы наверняка не открываются никогда.
Но разве этот процесс настройки что-то в корне изменил у вас?
у вас она никогда не станет зеленой. и я уже писал почему.
Inet-Ark, если считать, как это делает программа top, за 100% время работы ядра, то прекрасно получится.
Inet-Ark, так top иногда может показать.
Romka_Kharkov, хотя я имел ввиду не вас, но вы тоже не правы. вы используете mysql-кластер принципиально другого типа, не NDB.
MultiMaster - вообще вредный неоднозначный термин. Хотя я понимаю, что вы имели ввиду репликацию master-master, исходя из текущих возможностей mysql, но когда в будущем в mysql действительно появится MultiMaster-репликация, будет уже не понятно.
Никто не скажет точно.
Но раз уж памяти у вас в избытке, попробуйте для начала 16M туда вписать.
логично, но в случае с query_cache это вредно.
Прочистка большого кеша может занять занять секунды и вы не сможете понять от чего запрос вдруг тормозит. Так что оптимально остановиться уже на 256Mb.
( На самом деле отдельные личности высказываются еще более категорично http://mituzas.lt/2009/07/08/query-cache-tuning/. Внимание, юмор! )
да, если написано >64M значит он предлагает выставить больше.
Начать следует с определения куда же именно упирается mysql. Ставьте мониторинг и смотрите как изменяется iowait. Если iowait низкий, а процессор CPU все равно нагружен, вероятно вам вообще никакие подкрутки в mysql не помогут. Тут только приложение писать оптимальнее.
Вообще, не видя сервер мало шансов угадать правильные настройки, иначе бы в поставке mysql уже был бы правильный конфиг :)
When making adjustments, make tmp_table_size/max_heap_table_size equall - и правда забыли.
thread_cache_size (start at 4) - а это точно сделайте. хуже не будет
[!!] Temporary tables created on disk: 64% - некоторые приложения всегда используют сортировку на диске. tmp_table_size =32M уже достаточно много и это признак именно такого приложения.
