|
Задавайте вопросы, мы ответим
Вы не зашли.
Здраствуйте,
недавно купили новый мощный сервер Двухпроцессорный Xeon 3.2Ghz/Память 2Гига/HDD2x250. Всё вроде нормально, но загвозочка в настройках (оптимизации) MySQL, сейчас стоят настройки по-умолчанию. Я решил обратиться к Вам за помощью, т.к. в MySQL сервере не профи, и обратился потому что происходит следующая ситуация. Имеется сайт. Когда посещаемость была ниже 2000, всё было в норме. Сейчас посещаемость выросла до 5000 и тут начались проблемы. Странно ведет себя сервер, то при одновременной посещаемости в 200 человек - сервер работает быстро, а бывает при 100 начинаются такие тормоза, просто жуть. Сервер отвечает через секунд 30-60, грузиться долго. Смотрим в процессы сервера, нагрузка очень низкая, даже в самый тормозной момент. В такие моменты пробывали просто отключать сайт, и сервер сразу начинает летать только так, но стоит обратно включить сайт, секунд через 30 опять тормоз начинается. Сервер мощный, а единственный сайт с посещаемостью в 5000 человек и уже не справляется.
Помогите нам пожалуйста настроить MySQL под оптимальные настройки.
Сразу скажу стоит: FreeBSD и MySQL 5
Спасибо!
Неактивен
Посмотрите, пожалуйста, iostat, и в консоли MySQL SHOW PROCESSLIST
Если конфигурация по-умолчанию, то попробуйте в разделе [mysqld] файла /etc/my.cnf добавить
query_cache_size=128M
key_buffer_size=32M
и перезапустить сервер
После некоторого времени работы, поместите, пожалуйста, здесь результат SHOW STATUS, выполненной в консоли MySQL
Неактивен
Спасибо за быстрый ответ. Сейчас я всё сделаю как Вы сказали и напишу.
Сразу вопрос появился, нет файла по этому путю: /etc/my.cnf, найден тут: /var/db/mysql/my.cnf
Отредактированно 0lik.ru (15.12.2007 01:52:23)
Неактивен
Про FreeBSD я уже писал багу. У них дико неправильно собран MySQL в портах,
просто дико неправильно. Обратите внимание на его базовый приоритет. +11.
С таким приоритетом он просто тупо не получает процессорного времени для обработки
запросов. А время это съедает Апач, который постоянно поллит сервер "а не сделал
ли ты запрос?". Собственно, решение или поставить MySQL не из портов, или
опустить приоритет апача тоже.
Неактивен
rgbeast, если это то что надо:
Этот MySQL сервер работает 0 дней, 19 часов, 8 минут и 44 секунд. Он был запущен Дек 15 2007 г., 02:27.
Трафик в час
Принято 230 MB 12 MB
Послано 2 GB 123 MB
Всего 3 GB 135 MB
Соединения o в час %
max. concurrent connections 160 --- ---
Неудачные попытки 690 36.04 0.50%
Отменены 27 k 1,398.65 19.49%
Всего 137 k 7,175.40 100.00%
---------------------
paulus,
можете нам помочь настроить сервер под оптимальные настройки?
Неактивен
Неактивен
Данные, которые Вы привели это статистика соединений. Из этого виден только тот факт, что соединения разрываются. Полезной будет информация, которую Вы можете получить выполнив SQL-запросы в консоли MySQL или в phpmyadmin.
Запросы:
SHOW FULL PROCESSLIST;
SHOW STATUS;
SHOW VARIABLES;
Если Вы хотите, чтобы мы выполнили работы на Вашем сервере, то пишите на sakila@sqlinfo.ru, услуга платная, детали по адресу: http://sqlinfo.ru/services/
Неактивен
paulus написал:
Про FreeBSD я уже писал багу. У них дико неправильно собран MySQL в портах,
просто дико неправильно. Обратите внимание на его базовый приоритет. +11.
С таким приоритетом он просто тупо не получает процессорного времени для обработки
запросов. А время это съедает Апач, который постоянно поллит сервер "а не сделал
ли ты запрос?". Собственно, решение или поставить MySQL не из портов, или
опустить приоритет апача тоже.
У них, это у нас 
- я из мира bsd. Не ошиблись ли Вы? Только-что посмотрел на 8 серверах, где апач и MySQL установлены из портов. На всех восьми они запускаются по умолчанию с одинаковым приоритетом. На осальный сервах смотреть нет смысла. Я что-то неправильно ставил из портов?
paulus написал:
http://dev.mysql.com/downloads/mysql/5.0.html#freebsd
Вы точно знаете с какими опциями оно собрано? А необходимые пачи наложены? Какие именно? С поддержкой какй библиотеки нитей оно собрано? А если на моей конкретной задаче бОльшую производительность дает другая библиотека? Включена поддержка всех кодировок и сравнений? А если в моей задаче используется только одна кодировка и одно сравнение? А если мне не нужен ни OPENSSL, ни NDB? Зачем мне в памяти код, который никогда не будет использован? Чтобы быть увереным в оптимальной работе приложения, в мире bsd принято собирать самому...
Я не берусь судить о Linux, поскольку для меня родная FreeBSD. Но нельзя переносить подходы одной сисемы на другую.
paulus написал:
Про FreeBSD я уже писал багу.
Искал, поиск мне не помог. Дайте, пож., ссылку.
paulus, если я Вас чем-то задел, можете этот пост удалить. А можете написать мне на почту, или постучать в асю, у меня есть для Вас предложение.
Неактивен
Описание подобной проблемы есть в сети:
http://jeremy.zawodny.com/blog/archives … ment-16277
http://jeremy.zawodny.com/blog/archives … ment-26683
О сборке MySQL под BSD написано в Platform Notes, по умолчанию native библиотека тредов. Как по умолчанию собрана в портах, я не знаю. Вопрос в том, что лучше - дефолтная сборка из портов или tar.gz. Кстати в дефолтной сборке FreeBSD присутствуют также все кодировки. Собирать самому - это другое, к теме не имеющее непосредственного отношения. К теме ближе, например, приобрести сборку MySQL Enterprise с поддержкой - она протестирована на большой нагрузке и в случае чего саппорт поможет решить проблемы производительности.
О патчах, смотря о каких Вы говорите - включены те, которые прошли через систему багфиксов MySQL AB.
Вот что на одном из FreeBSD серверов:
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
94211 mysql 29 0 131M 98M RUN 3:07 1.03% 1.03% mysqld
15434 www 18 0 21008K 13888K lockf 0:00 0.78% 0.78% httpd
33635 www 2 0 22388K 15428K poll 5:57 0.29% 0.29% httpd
Я так понимаю nice у всех нулевой, но приоритет расставляется планировщиком.
Неактивен
Нет, ничем не задели. Просто у меня на FreeBSD при дефолтных настройках
mysqld запускается с приоритетом +11, что не позволяет запускать на этой
же машинке вообще что-то кроме mysql, т.к. иначе это что-то сразу съедает
весь проц.
То, что Вы из мира FreeBSD - не значит, что именно Вы делаете файлы,
которые кладутся в порты Собственно, вероятность этого очень мала
Неактивен
rgbeast написал:
Описание подобной проблемы есть в сети:
http://jeremy.zawodny.com/blog/archives … ment-16277
http://jeremy.zawodny.com/blog/archives … ment-26683
В указаных Вами постах я не нашел упоминания о:
paulus написал:
У них дико неправильно собран MySQL в портах, просто дико неправильно.
rgbeast написал:
О сборке MySQL под BSD написано в Platform Notes, по умолчанию native библиотека тредов.
Особенно актуально в этой ссылке упоминание FreeBSD 2.x. Я такй уже не застал... Хотя, по сути правльно, что нормальная работа MySQL под FreeBSD больше должна заботить не MySQL AB а FreeBSD-сообщество.
rgbeast написал:
Как по умолчанию собрана в портах, я не знаю. Вопрос в том, что лучше - дефолтная сборка из портов или tar.gz. Кстати в дефолтной сборке FreeBSD присутствуют также все кодировки. Собирать самому - это другое, к теме не имеющее непосредственного отношения.
В портах MySQL собирается с WITH_LINUXTHREADS=yes.
Я хочу сказать, что, например, такая сборка из портов:
make WITH_CHARSET=cp1251 WITH_XCHARSET=cp1251 WITH_COLLATION=cp1251_general_ci WITHOUT__OPENSSL=yes WITHOUT_NDB=yes WITHOUT_ARCHIVE=yes WITHOUT__CSV=yes WITH_INNODB=yes install clean
для FreeBSD лучще установки отсюда:
http://dev.mysql.com/downloads/mysql/5.0.html#freebsd
rgbeast написал:
К теме ближе, например, приобрести сборку MySQL Enterprise с поддержкой - она протестирована на большой нагрузке и в случае чего саппорт поможет решить проблемы производительности.
Вполне возможно, что для начинающих это правильный путь. С другой стороны материальная поддержка MySQL AB - это правильно. Но стоит ли это делать ради нескольких процентов увеличения производительности? Может, лучше потратить эти деньги на более мощное железо? Для начинающих - да, согласен однозначно.
rgbeast написал:
О патчах, смотря о каких Вы говорите - включены те, которые прошли через систему багфиксов MySQL AB.
Я имел ввиду не патчи, относящиеся к логике MySQL - в этом плане MySQL AB, и никто другой. Я говорил о патчах в директории files порта. Патчи, которые учитывают особенности архитектуры именно FreeBSD. Установленый tar.gz от MySQL AB или собраный из исходников MySQL тоже будет работать, но спать спокойней со сборкой из портов, со своими опциями, конечно. И данных о том, что мы потеряем в производительности в этом случае, у меня тоже нет. Поэтому замечание, что
paulus написал:
У них дико неправильно собран MySQL в портах, просто дико неправильно.
считаю несколько ... надуманым. Но вполне простительным для человека, далекого от FreeBSD.
Неактивен
Получил по email SHOW VARIABLES и SHOW STATUS.
1. Попробуйте увеличить thread_cache
thread_cache_size=64
2. Уменьшите max_connections до 256, все равно при 600 соединений ничего не работает. Задача в том, чтобы каждое соединение отрабатывало быстро и их число не накапливалось.
3. Установите
log_slow_queries
long_query_time=1
это позволит записать в log запросы, которые выполняются медленно
4. Видно, что много блокировок возникает
5. Какой тип таблиц MyISAM или Innodb?
6. Пришлите пожалуйста SHOW GLOBAL STATUS;
Неактивен
По 5-му вопросу, используется тип таблиц: MyISAM
По 6-му вопросу: Отослал!
Неактивен
Очень странно, в переменных ненулевые значения для статуса Innodb, например Innodb_buffer_pool_read_requests. Также статистика говорит, что у Вас используются транзакции: Com_begin, Com_commit ненулевые.
Если innodb используется для части таблиц, то имеет смысл увеличить его буффер:
innodb_buffer_pool_size=128M
Также стоит увеличить максимальный размер временной таблицы в памяти:
max_heap_table_size=32M
Кроме того, стоит увеличить:
join_buffer_size=4M
read_buffer_size=2M
read_rnd_buffer_size=1M
max_tmp_tables=128
Внедрите все изменения в my.cnf (включая log-slow-query) и перезапустите сервер MySQL.
Неактивен
rgbeast, скажите пожалуйста, а почему Значения у некоторые Переменных (это в "Показать состояние" или Server Status),
имеют красный цвет, а некоторые Зеленый?
К примеру те что красные:
Slow_queries 24
Innodb_buffer_pool_reads 337
Handler_read_rnd 19 M
Handler_read_rnd_next 651 M
Created_tmp_disk_tables 96 k
Key_reads 992 k
Select_full_join 106
Opened_tables 28 к
Table_locks_waited 3,353
всё что зеленое имеет значение 0
Отредактированно 0lik.ru (16.12.2007 22:19:34)
Неактивен
Сами переменные не имеют цвета. phpmyadmin подсвечивает красным переменные, которые свидетельствуют о низкой производительности.
Неактивен
rgbeast, а понятно (на счёт красного цвета).
А всё то что Вы мне указали и по рекомендовали настроить, я смогу сделать скорее всего только завтра (в понедельник 17 декабря).
И тогда сразу отпишу тут что да как стало.
Спасибо Вам за Помощь!
Неактивен
rgbeast, всё сделали (немного с запозданием) как Вы сказали и перезагрузили. В phpmyadmin появились некоторые переменные которые также стали подсвеченными красным цветом (т.е. как Вы сказали "свидетельствуют о низкой производительности") которых ранее не было
все переменные подсвеченые красным цветом:
Slow_queries 36
Innodb_buffer_pool_pages_dirty 3
Innodb_buffer_pool_reads 144
Handler_read_rnd 911 k
Handler_read_rnd_next 50 M
Created_tmp_disk_tables 6 k
Key_reads 65 k
Select_full_join 11
Opened_tables 1 k
Table_locks_waited 284
Что Вы еще можете посоветовать что бы оптимизировать окончательно MySQL?
Спасибо!
Неактивен
Получается оптимизация навскидку, Вы мне параметры черного ящика, я Вам тоже некие цифры.
Slow_queries 36
Select_full_join 11
Created_tmp_disk_tables 6 k
это к тому, какие у Вас запросы и ключи используются, с последним можно немного бороться, увеличив максимальный размер временной таблицы в памяти:
max_heap_table_size=32M
Кроме того, посмотрите, что у Вас в slow-query-log. Это файл server-name-slow.log в /var/db/mysql/
Про innodb Вы говорили, что не используется, но так как по факту используется, то сделайте
innodb_buffer_pool_size=64M
Неактивен
Что то теперь совсем стало плохо, уже при 150 одновременно находящихся на сайте, сервер просто не отвечает.
>>Кроме того, посмотрите, что у Вас в slow-query-log
Вот смотрю, честно говоря мне мало что говорит информация в данном файле, ранее не сталкивались с этой проблемой и небыло нужды глядеть. Подскажите пожалуйста, на что обратить внимание в данном файле?
Неактивен
В файле slow-query-log запросы к БД, которые выполняются медленно. Возможно запросы к базе составлены некорректно, или не хватает ключей в таблицах. Надо смотреть отдельно каждый запрос в этом файле.
Посмотрите, хватает ли памяти на сервере при текущих настройках. Это можно сделать командной free в командной строке
Неактивен
или не хватает ключей в таблицах
А как их добавить? или что необходимо для этого сделать?
Возможно запросы к базе составлены некорректно
Используется DLE движок на сайте. На многих сайтах он установлен но у них проблем с этим нет (при посещаемости в 10-20тыс./сутки), скорее всего всёже не в запросах дело.
Посмотрите, хватает ли памяти на сервере при текущих настройках. Это можно сделать командной free в командной строке
Вот информация памяти, что то уж больно много жрет? или так и должно?
Использование памяти Итого Использовано Свободно Общий Буфер Кэшировано Использование
1.99 ГБ 1.98 ГБ 16.34 МБ 71.19 МБ 112.19 МБ 94.63 МБ 94.56%
Использование подкачки
Итого Использовано Свободно Использование
4.00 ГБ 332.00 КБ 4.00 ГБ 0.01%
Неактивен
память использована вплонтую (так как кэшировано+свободно всего 110 Mb. Подкачка не используется, значит памяти все же хватает, хотя и впритык. Наберите top, посмотрите какие процессы жрут память.
Неактивен
rgbeast,
Наберите top, посмотрите какие процессы жрут память
Отпарвил Вам на мыло информацию о процессах
Неактивен
Судя по процессам, mysql съедает только 136 мегов реальной памяти. Возможно память съедает httpd, perl или java. ps auxwf даст больше инфы, но очевидно mysql не является узким местом по памяти. Проблем в том, что httpd висят и ждут чего-то, видимо от mysql. При оптимизации Вам надо будет учитывать и конфигурацию httpd.
Неактивен
