|
Задавайте вопросы, мы ответим
Вы не зашли.
Переехали на новые сервера и почему то переодически затыки появились то моментально страницы открываются то 4-7 секунд что то тупит - ничего не понимаю - уже конфиг перелопатил как мог - не помогает.
вот конфиг - если можно - помогите плиз
мускул 5.081 памяти 12гиг. 2 процессора 2 ядерных
[client]
default-character-set = cp1251
[mysqld]
port = 3306
datadir = /var/lib/mysql
user = mysql
log-error = /var/log/mysql.log
skip-name-resol
skip-locking
low-priority-updates
skip-innodb
max_connections=15550
key_buffer_size = 4G
max_allowed_packet = 12M
table_cache = 3056
tmp_table_size=3280M
max_heap_table_size = 128M
sort_buffer_size = 16M
read_buffer_size = 16M
join_buffer_size = 16M
read_rnd_buffer_size = 32M
myisam_sort_buffer_size = 126M
query_cache_limit=32M
query_cache_size=2048M
memlock
thread_stack=512K
thread_cache_size = 70
thread_concurrency = 12
default-character-set=cp1251
skip-character-set-client-handshake
character-set-server = cp1251
collation-server = cp1251_general_ci
init-connect = "SET NAMES cp1251"
concurrent_insert=2
low_priority_updates=1
long_query_time = 5
[mysqldump]
quick
max_allowed_packet = 1600M
[mysql]
default-character-set=cp1251
no-auto-rehash
[isamchk]
key_buffer = 521M
sort_buffer_size = 512M
read_buffer = 80M
write_buffer = 80M
[myisamchk]
key_buffer = 512M
sort_buffer_size = 512M
read_buffer = 80M
write_buffer = 80M
[mysqlhotcopy]
interactive-timeout
Отредактированно mordan (21.09.2009 11:00:49)
Неактивен
skip-name-resol
вот на это не ругается? это опечатка здесь или в конфиге?
Попробуйте включить log-slow-queries/long-query-time=1, если это запросы
выполняются долго — они туда попадут, если это проблемы соединения —
нет. Подозреваю, что это таки DNS.
Неактивен
та в том то и дело что запросо тормознутых нету
а что за проблема в днсе может быть ?
под мускул отдельный сервер предоставлен - сервера по сетевой связана во внутренней сети
Неактивен
Ну, skip-name-resolve не дописан до конца, может, он таки не выключен, и
при соединении происходят обратные резолвы соединений. В моменты протухания
кэша в DNS сервере, MySQL ждет, пока тот ответит — из-за этого ежечасные
таймауты соединений запросов.
Неактивен
поправил skip-name-resolve - была ошибка
включил slow логирование - посыпались запросы какие то - тестирую их - отрабатываются меньше 0.004 секунды
explain всё в пределах нормы
таймауты остались всё равно
Неактивен
Если посыпались запросы, которые в «обычном режиме» выполняются быстро —
смотрите в сторону блокировок таблиц / периодического возрастания нагрузки
на сервер в целом (в частности, дисковую подсистему).
Неактивен
да это есть - таблицы блокируются часто - обоновления идут - нагрузка переодически возрастает
Неактивен
но когда нету нагрузки - откуда затыки могут браться ?
у нас допустим когда идёт обновления контента - insert то тогда да сайт тормозит
но когда нету - чего тормозить ...
Неактивен
Может, какое-то другое обновление контента? Попробуйте перейти на InnoDB,
тогда блокировок при вставках не будет.
Если таймауты возникают регулярно (например, раз в 15 минут), посмотрите, что
приходит в хроне. Возможно, стоит временно включить журнал всех запросов
и поискать там.
Неактивен
а какие насйтройки для innodb лучше тогда в конфиг включить - наверное действительно надо перейти на innodb -он хоть и медлеенее но учитывая блокировку таблиц может быть единственным спасением для нас
Неактивен
Кто сказал, что InnoDB медленнее? InnoDB быстрее! 
innodb_buffer_pool_size = побольше
(т.к. он данные тоже кэширует, на 64 битной системе я бы поставил гигабайт 6,
разумеется, уменьшая key_buffer_size, чтобы в своп не уползти)
innodb_flush_log_at_trx_commit = 0
Остальные параметры менее критичные, т.к. Вы транзакции не используете.
Неактивен
попробуем ... правда не представляю как конвертнуть все таблицы в innodb - счас вот попробывал одну таблицу на 900 тыс записей конвертнуть ... так уже час конвертится
Неактивен
Да, это долгий процесс... особенно если Вы не включили buffer_pool большой.
Ну и для конверта, наверное, можно innodb_log_buffer_size поднять... хотя, не
так повлияет, как первое.
Неактивен
переход некоторых таблиц на Innodb действително помог решить проблему - таймауты были из за лока таблиц
меня интересует а как быть с крешем таблиц иннодб ?
бекапами и т.д. никогда не работали с иннодб ... может порекомендуете главные принципы какие то работы с иннодб ?
Неактивен
InnoDB не крэшатся так, как MyISAM (аналогия как между ext3 и ext2), но если диск физически побился,
то восстановить ее сложнее.
Бэкап с табличек InnoDB можно снимать не останавливая сервис: mysqldump --single-transaction.
Единственное, что надо рассчитывать, что бэкап — все равно очень активный по диску процесс, поэтому
может увеличить время ответов запросов.
Неактивен
тут откуда то проблемка появилась - почему то при большом количестве запросов начала выскакивать ошибка Error #2006 MySQL server has gone away
и скрипты соответственно не выполняются
как это лечить ?
Неактивен
Сервер выживает? Не перегружается? Такая ошибка возникает тогда, когда соединение
внезапно разрывается со стороны сервера... чаще всего это из-за того, что сервер падает.
Если у Вас стабильная версия MySQL, то падает он обычно из-за системных ошибок
(типа выделения большого количества памяти на 32 битной системе или неудачной сборки
под FreeBSD).
Неактивен
похоже из за памяти - убрал гиг памяти с pool - посмотрим что будет ..
Неактивен
32 битная ОС? Тогда держите память так, чтобы суммарный объем был меньше 3G,
иначе будет падать... а лучше 64битную, конечно...
Неактивен
у нас 64 битная система - почему то падает мускул - но как то странно ... он сам потом поднимается
Неактивен
вот my.cnf с правками
[client]
default-character-set = cp1251
[mysqld]
port = 3306
datadir = /var/lib/mysql
user = mysql
log-error = /var/log/mysql.log
skip-name-resolve
skip-locking
low-priority-updates
#skip-innodb
max_connections=15550
key_buffer_size = 2G
innodb_buffer_pool_size = 2G
innodb_log_buffer_size = 512M
innodb_flush_log_at_trx_commit=0
max_allowed_packet = 128M
table_cache = 2048
tmp_table_size=2048M
max_heap_table_size = 128M
sort_buffer_size = 16M
read_buffer_size = 8M
join_buffer_size = 4M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 128M
query_cache_limit=32M
query_cache_size=512M
memlock
thread_stack=512K
thread_cache_size = 70
thread_concurrency = 16
default-character-set=cp1251
skip-character-set-client-handshake
character-set-server = cp1251
collation-server = cp1251_general_ci
init-connect = "SET NAMES cp1251"
concurrent_insert=2
low_priority_updates=1
#log-slow-queries=/var/log/mysql-slow-queries.log
#long_query_time=1
[mysqldump]
quick
max_allowed_packet = 1600M
[mysql]
default-character-set=cp1251
no-auto-rehash
[isamchk]
key_buffer = 521M
sort_buffer_size = 512M
read_buffer = 80M
write_buffer = 80M
[myisamchk]
key_buffer = 521M
sort_buffer_size = 512M
read_buffer = 80M
write_buffer = 80M
Неактивен
Поднимается потому что за ним следит mysqld_safe. Но сами падения плохи.
А что написано в error log? Какая ОС, если не секрет?
Такая штука по опыту бывает во FreeBSD с MySQL, собранным из портов. Если
же взять исходники с сайта и MySQL AB, то проблема исчезает (портогенераторы
вставляют какие-то кривые ключи компиляции).
Неактивен
схема следующая сервер на нём прокси сервер mysql он коннектится к мускульному серверу по внтуреннем ип адрессу 192.168 и т.д.
а третий сервер коннектится уже к mysql-proxy по внешнему ип - в логах ошибок нету - я не могу понять
толи это mysql-proxy делает такую гадость ...
Неактивен
система линукс на всех серверах
Неактивен
А у Вас хорошо работает mysqlproxy? У меня о нем сложилось крайне негативное мнение.
Он очень хорошо (т.е. почти со 100% вероятностью) бьет кодировки всего, что через него
пролезает. В качестве проксика можете попробовать haproxy, «обычная» прокся не издевается
над передаваемым содержимым...
Да, отвлекся: в журнале ошибок должно быть про падение написано. Ну или в dmesg в
крайнем случае, но MySQL умеет и на SIGSEGV писать в лог перед падением.
Неактивен
