У меня большая проблема с моим сервером mysql. Все работало нормально, но с тех пор на неделе это происходит очень медленно. Каждый запрос выполняется медленно (более 20 секунд). Я ничего не изменил в своей конфигурации.
Кто-нибудь может помочь мне узнать, почему мой сервер сейчас медленный?
Спасибо.
Вот мой my.cnf:
[
mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
#join_buffer_size = 128.0K
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1
# * Fine Tuning
#
key_buffer = 16M
max_allowed_packet = 16M
max_heap_table_size = 64M
tmp_table_size = 64M
thread_stack = 128K
thread_cache_size = 8
#max_connections = 100
table_cache = 400
join_buffer_size = 2000K
#thread_concurrency = 10
#
# * Query Cache Configuration
#
query_cache_limit = 1M
query_cache_size = 16M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
#log = /var/log/mysql/mysql.log
#
# Error logging goes to syslog. This is a Debian improvement :)
#
# Here you can see queries with especially long duration
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
#server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
# WARNING: Using expire_logs_days without bin_log crashes the server! See README.Debian!
expire_logs_days = 10
max_binlog_size = 100M
#binlog_do_db = include_database_name
#binlog_ignore_db = include_database_name
#
# * BerkeleyDB
#
# Using BerkeleyDB is now discouraged as its support will cease in 5.1.12.
skip-bdb
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
# You might want to disable InnoDB to shrink the mysqld process by circa 100MB.
#skip-innodb
innodb_buffer_pool_size = 42M
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
#no-auto-rehash # faster start of mysql but no tab completition
[isamchk]
key_buffer = 16M
Спасибо за ваши ответы.
Я пытаюсь перезапустить мой сервер mysql, но ничего не меняется. Что касается процессора и бара, ничего плохого, мой процессор составляет около 2%, и у меня есть 100Mo бесплатно для 1 Go установлен.
Я запускаю OPTIMIZE TABLE для всех таблиц, но проблема все еще здесь.
Но я анализирую жесткий диск ввода-вывода и мой жесткий диск каждый раз пишу много. У меня в среднем 75.33 запросов/секунд, которые записываются на мой диск.
Проблема может быть здесь. Как узнать, какую программу пишите каждый раз?
Предполагая, что ничто не изменило мудрый ресурс (процессор, память, активность диска) - одна область для просмотра может быть индексом в запросах. Исходя из предположения, что данные вводятся/обновляются постоянно, запросы могут замедляться с течением времени по мере ввода все большего количества данных, особенно если индексы не были установлены. Без дополнительной информации о том, как вы все настроили этот вопрос, очень сложно ответить.
Какое приложение используется для этой БД?
Это может быть длинный снимок, но я однажды наблюдал за сервером с приложением, которое импортировало электронные письма для приложения поддержки. Через некоторое время я заметил, что приложение начало замедляться. Оказывается, что БД вырос до огромного размера из-за спам-писем, растущих на одной из таблиц. Убрал их, и он заметно оживился.
Удостоверьтесь, что что-то не пошло не так и затопило БД ненужными данными. Не вероятная причина, но никогда не больно проверять.
В любом случае, убедитесь, что вы не сильно меняете swap (как было предложено в другом месте).
Не совсем ответ, но как долго работает время ожидания mysql? Может быть, перезапуск может помочь?
Если перезапуск не помогает - запустите проверку всех активных баз данных/таблиц, некоторые из них могут быть повреждены и вызывают проблемы.
Кроме того, что такое загрузка вашей серверной системы mysql? Что-то могло съесть всю ОЗУ и вызвало серьезную замену. Вы можете использовать htop
и free
и некоторые другие инструменты для мониторинга использования ЦП/ОЗУ.
uptime
после продолжительного времени безотказной работы (где-то в диапазоне 256d-3y): он возобновил подсчет с 0 дней безотказной работы. Во всяком случае, обновление Kiva ясно показывает, что я был неправ в этом случае :)
Попробуйте добавить опцию skip-name-resolve
сразу после skip-external-locking
, то же самое, если вы добавите IP-адрес и домен сервера в /etc/hosts.
У меня была такая же ситуация, и это решило проблему!
Вы можете попытаться сузить проблемы, контролируя производительность с помощью некоторых инструментов, для Unix-систем существует также инструмент mytop, обычно доступный через системы управления пакетами...
Кроме того, попробуйте создать некоторые индексы в таблицах, чтобы уменьшить латентность доступа.