Оптимизация (кеширование) MySQL фал конфигурации под престу с 6 Гигами оперативки

lightman555

Гуру форума
Регистрация
7 Мар 2013
Сообщения
337
Реакции
64
Народ поделитесь опытом оптимального кеширования базы? В магазине уже около 17 тысяч единиц товара и используется встроенный фильтр по цене который грузит базу на раз!
изучал кеширование и в результате собрал вот такой файл конфигурации для одноядерного сервера с 6 Гигами оперативки.
Посмотрите где какие правки если что внести или вполне подходящий?
В итоге как я понимаю отдалось 1024 Мегов под кеш базы вместо базовых 64Мега
+ я еще подтянул Мемкешед и выставил ему вместо базовых 64 Мега - 512 Мегов
Но субъективно по моему не сильно улучшилась скорость - утром летал а сейчас когда на сайте 50-т человек то по моему так же как вчера до увеличения кешей у мемкеш и базы

#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# Для просмотра ссылки Войди или Зарегистрируйся
# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
# Here is entries for some specific programs
# The following values assume you have at least 32M ram
# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[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
lc-messages-dir = /usr/share/mysql
skip-external-locking
bind-address = 127.0.0.1
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#
# * Fine Tuning
#
key_buffer = 1024M
max_join_size = 1000000
max_allowed_packet = 256M
thread_stack = 512K
thread_cache_size = 50
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover = BACKUP
#max_connections = 100
table_cache = 60000
thread_concurrency = 5
#
# * Query Cache Configuration
#
query_cache_limit = 2M
query_cache_size = 256M
myisam_sort_buffer_size = 256M
tmp_table_size = 256M
max_heap_table_size = 128M
read_buffer_size = 2M
read_rnd_buffer_size = 4M

sort_buffer_size = 2M
join_buffer_size = 4M
max_sort_length = 512
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file = /var/log/mysql/mysql.log
#general_log = 1
#
# Error logging goes to syslog due to /etc/mysql/conf.d/mysqld_safe_syslog.cnf.
#
# 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.
# note: if you are setting up a replication slave, see README.Debian about
# other settings you may need to change.
#server-id = 1
#log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
#binlog_do_db = include_database_name
#binlog_ignore_db = include_database_name
#
# * 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!
#
# * 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 = 256M
[mysql]
#no-auto-rehash # faster start of mysql but no tab completition
[isamchk]
key_buffer = 32M
#
# * IMPORTANT: Additional settings that can override those from this file!
# The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/
 
Никто не занимался? Для чего все это я затеял - чтобы ускорить работу магазина - на данный момент страницы могут открываться по 20-30-ть секунд после запроса (открываются мгновенно когда пройдет 20-30-ть секунд).
Не понимаю что можно еще сделать чтобы разрешить ситуация так как совершенно невозможно конечно работать с магазином при таких диких временных характеристиках
 
Для начала попробуйте поставить подсчет времени генерации страницы.
И протестировать систему с и без кеширования запросов в БД.
Я думаю вы удивитесь что кеш БД только тормозит.
 
а как поставить временную генерацию ?

что значит тормозит - это еще почему?
 
Поищите в интернете "как подситать время генерации страницы php".
А тормозит потому что это кеш мускуля.
 
то есть Ваше мнение, что конфигурационный файл должен быть иным не желе чем я привел и кешировать ничего ненужно? Очень странно - в интернете полно статей на эту тему и пишут как раз все наоборот даже на форуме самой престы! Очень странно... У меня в базе просто 17 тысяч товаров и нагрузка на базу колоссальна и не держать ее в кеше наверное как то не правильно.
По поводу генерации страниц - если даже этого не делать - чисто визуально видно что скорость загрузки страниц увеличилась но за счет чего это достигнуто либо за счет кеша мемкешед либо за счет кеширования еще базы данных - этого мне не ведомо
 
У Самой престы написано что кешировать базу нужно:
10. Tune your MySQL configuration, and check your SQL query cache value
Ask your hosting provider to dig into the MySQL configuration and to check the query_cache value. This value should be at the very least “512M” (512 Mega-bytes).
Other MySQL configuration values can also be fine-tuned, have a look to the excellent Для просмотра ссылки Войди или Зарегистрируйся.
 
А вы лично тестировали с и без кеша запросов БД самим MySql? Я лично да, и преимущество было не за кешом.
 
напишите пожалуйста каким образом протестировать и я протестирую чтобы посмотреть на результат
но визуально стало гораздо шустрее
 
Назад
Сверху