Просмотр полной версии : проблемы с зависаниями процессов Mysql
У меня cache_pages становится сильно большой - больше 1Гб
Тип таблицы MyIsam
Иногда в Mysql начинают появляться бесконечные процессы
Связано это обычно с операциями вставки в cache_pages
Иногда с обновлением таблиц indexed_search.
В общем я решил перейти на InnoDB для cache* и index* таблиц
Посмотрел в COMPARE в Install Tool - не предлагает почему то
Посоветуйте - стоит ли вообще переходить на InnoDB для этих таблиц?
-=UncleByte=-
01.08.2008, 09:32
http://typo3bloke.net/post-details/eight_performance_tips_for_your_typo3_web_site/
http://typo3bloke.net/post-details/eight_performance_tips_for_your_typo3_web_site/
спасибо за ссылку
решил повременить с переходом на innoDB - посмотрю исчезнут ли бесконечные процессы mysql в связи с тем что убрал pconnect
интересно где просматривается то что mysql перешел на connect? а вдруг Typo3 и так до этого использовала pconnect?
-=UncleByte=-
01.08.2008, 12:05
В Install Tool в разделе All Configuration есть параметр [no_pconnect], который пишется в localconf.php
Действительно - после установки [no_pconnect] в логе slow_queries перестали появляться сообщения о медленных процессах. Объем файла cache_pages.MYD вырос до 900Мб.
Перешел на InnoDB
как то не заметил что frm файл cache_pages стал совсем маленьким - 8кб
стал рыть - оказывается все данные стали класться в файл ibdata1
интересно как теперь архивацию делать - почитаю
все таки система тормозить стала теперь на чтение и DELETE from cache_pages
почитал кое что здесь
http://web-scalability.com/2008/05/30/mysql-%D1%82%D1%8E%D0%BD%D0%B8%D0%BD%D0%B3-%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%B0%D0%B8%D0%B2%D 0%B0%D0%B5%D0%BC-%D0%BF%D0%BE-%D0%B2%D0%B7%D1%80%D0%BE%D1%81%D0%BB%D0%BE%D0%BC%D 1%83/
Прошу поделиться вариантами my.cnf для систем примерно такого типа:
память 2,6 Гб (не могу настроить FreeBSD на имеющиеся 4Гб)
процессор CPU: Intel(R) Xeon(R) CPU 5160 @ 3.00GHz с 4-мя ядрами
мой my.cnf
[mysqld]
character-set-server=utf8
collation-server=utf8_unicode_ci
key_buffer_size=300M
max_allowed_packet=16M
max_connections=4000
max_connect_errors=2000000
wait_timeout=15
max_tmp_tables=200
query_cache_size=64M
query_cache_limit=10000000
query_cache_type=1
table_cache=10000
tmp_table_size=64M
thread_cache_size=200
#это взято здесь http://www.ibm.com/developerworks/linux/library/l-tune-lamp-3.html
log-slow-queries
long_query_time = 30
skip-locking
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_concurrency = 4
innodb_buffer_pool_size=250M
innodb_additional_mem_pool_size=50M
innodb_file_io_threads=8
innodb_lock_wait_timeout=50
innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=0
и еще - после рестарта сервер бд начинает работать быстрее - вроде бы ясно что должно быть так - но все же какие идеи
Valery Romanchev
30.09.2008, 11:24
на этом сервере есть несколько инсталяций (среди них по крайней мере в одной cache_pages MyISAM 1,9 Гб)
# The following options will be passed to all MySQL clients
[client]
#password = your_password
port = 3306
socket = /tmp/mysql.sock
# Here follows entries for some specific programs
# The MySQL server
[mysqld]
datadir=/home/mysql
port = 3306
socket = /tmp/mysql.sock
skip-locking
key_buffer = 1M
max_allowed_packet = 8M
table_cache = 8
sort_buffer_size = 1M
read_buffer_size = 2M
read_rnd_buffer_size = 2M
net_buffer_length = 8K
thread_stack = 256K
query_cache_size = 32M
# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (using the "enable-named-pipe" option) will render mysqld useless!
#
#skip-networking
server-id = 1
# Uncomment the following if you want to log updates
#log-bin=mysql-bin
# Uncomment the following if you are NOT using BDB tables
#skip-bdb
# Uncomment the following if you are using InnoDB tables
#innodb_data_home_dir = /var/db/mysql/
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/db/mysql/
#innodb_log_arch_dir = /var/db/mysql/
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
#innodb_buffer_pool_size = 16M
#innodb_additional_mem_pool_size = 2M
# Set .._log_file_size to 25 % of buffer pool size
#innodb_log_file_size = 5M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates
[isamchk]
key_buffer = 8M
sort_buffer_size = 8M
[myisamchk]
key_buffer = 8M
sort_buffer_size = 8M
[mysqlhotcopy]
interactive-timeout
насчет max_connections=4000 я конечно загнул
подойдет 100
размер файла ibdata1 до 8Гб
из-за опасений что этот файл вырастет еще больше использую директиву innodb_file_per_table
теперь в каталоге mysql/имя_базы данных появился файл cache_pages.ibd
за 3 суток он вырос до 1 Гб
в переходный период я делал обновление кэша, но это длилось ужасно долго при этом сайт работал, но например отображение list блоков новостей по категориям выдавало что-то типа "нет новостей"
пришлось делать truncate - о чем пишут авторы Typo3 собираются заменять в коде delete на truncate (хотя это специфичная для mysql команда)
несмотря на то что cache_pages был обнулен и оставался единственной таблицей с innodb файл ibdata1 не сократился
получается что сделать каким то образом shrink или contract для этого файла никак нельзя
возникли проблемы с архивацией - теперь нужно писать особый скрипт, который не архивирует весь каталог, а только избранное
все-таки 2 файла - по 8 Гб и 1 Гб
прочитал советы как сократить ibdata1:
1 совет - разбить директивой innodb_data_file_path=ibdata1:50M;ibdata2:50M:auto extend
там же можно установить максимум
InnoDB is not aware of the filesystem maximum file size, so be cautious on filesystems where the maximum file size is a small value such as 2GB. To specify a maximum size for an auto-extending data file, use the max attribute. The following configuration allows ibdata1 to grow up to a limit of 500MB:
innodb_data_file_path=ibdata1:10M:autoextend:max:5 00M
не пробовал - не уверен что 8Гб станут 500М
2 совет
сделать dump всех БД, убить ibdata1, восстановить БД
займет много времени - требует остановки сервера
буду пробовать первй вариант
Valery Romanchev
07.11.2008, 11:46
а кеширование в статические файлы у вас стоит?
nc_staticfilecache
еще есть вариант страницы typo3 кешировать не в cache_pages а в статику (есть такая настройка)
Спасибо - буду также пробовать nc_staticfilecache
или настройку в статику
Директива innodb_data_file_path=ibdata1:10M:autoextend:max:5 00M к сожалению не сработала - сразу же mysql предложил вернуть все назад в логе и там же в логе стали появляться ежеминутные ссобщения о неправильном формате данных других в том числе не innodb файлов. За 3 дня лог вырос на 1Гб. В общем нужно пробовать помимо варинатов Валерия вариант с dump и восстановлением
очистить кэш команда delete from cache_pages длится около 10 минут
файл cache_pages.ibd вырос до 4 Гб, а файл ibdata1 перестал расти - 8 Гб
необходимо прочитать мануал по работе с innodb - все некогда, для сжатия ibd
Работает на vBulletin® версия 3.8.1. Copyright ©2000-2025, Jelsoft Enterprises Ltd. Перевод: zCarot